small but useful patches for text search
Hi there,
I and Teodor have several small, but useful patches for text search:
1. Support of filtering dictionaries and unaccent dictionary/function.
This is often requested feature, which solves, for example,
problem with correct headlines for text with accents.
See example and docs http://www.sai.msu.su/~megera/wiki/unaccent
2. Add prefix search support to the synonym dictionary.
Star sign '*' at the end of definition word indicates,
that definition word is a prefix and to_tsquery() function will transform
that definition to the prefix search format.
Notice, it is ignored in to_tsvector().
Some examples http://www.sai.msu.su/~megera/wiki/2009-03-13
There are limitations - no support for thesaurus dictionary,
ts_debug doesn't support all these features (it needs to be rewritten
to C).
There is no problem with back compatibility.
We would like to have your opinion what to do with these patches - leave them
for 8.5 or provide them to hackers to review for 8.4.
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
Oleg Bartunov <oleg@sai.msu.su> writes:
We would like to have your opinion what to do with these patches - leave them
for 8.5 or provide them to hackers to review for 8.4.
In theory 8.5, though you wouldn't be the first to start sneaking in late
commits and given how long before the release I can't really think people
would complain too much.
Things have reached a perverse state. We've now been in a holding pattern for
4 1/2 months while development has basically ceased. Aside from committers, no
contributors have been able to make any progress on any work for already that
time and months remain before any reviewers will pay any attention to
submissions.
I have a bunch of ideas I wanted to follow up posix_fadvise with including
posix_fallocate and more uses of posix_fadvise. I also wanted to return to the
ordered merge-append which I still think is critical for partitioned table
plans.
I think it's clear that stretching feature freezes is a failed policy. Aside
from delaying everyone else's work, it hasn't helped the projects we held the
release for either. Those projects would have hit 8.5 in due course just fine
but now surely we'll delay 8.5 based on the 8.4 release date. So they'll be
delayed just like everyone else's work.
I think in the future we should adopt a policy that only minor patches can be
received after the first commitfest. Major patches are expected to submitted
in the *first* commitfest and reworked based on feedback on subsequent
commitfests. The last commitfest should be a real feature-freeze where only
bug-fixes and minor changes are accepted, not major features.
There seems to be a lot of resistance on the basis that there would be a long
wait until features are seen in a release. Personally I'm only interested in
when features get committed, not when they hit a release. But in any case I
think experience shows that this would result in hitting the same release
anyways and that release would be sooner as well.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
Gregory Stark <stark@enterprisedb.com> writes:
I think it's clear that stretching feature freezes is a failed policy.
Yeah, it's the same old same old --- once again, we've bent over
backwards to try to accommodate large patches at the end of a
development cycle. I'm not sure that that's ever going to stop,
because every time there are people cheerleading for said patches
and insisting that the release will be so much better if we wait
for them. Somehow we keep expecting that they'll get fixed and
landed in a short period of time.
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.
regards, tom lane
On Mon, Mar 16, 2009 at 8:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm not sure that that's ever going to stop,
because every time there are people cheerleading for said patches
and insisting that the release will be so much better if we wait
for them.
Well 8.3 was better for having HOT. But I still feel we got lucky with
that. I was pretty nervous we would find some major data corruption
bug after 8.3 was out. Pavan did great work and others in EDB put a
lot of work into testing it, but systematic testing -- as great as it
is --just isn't the same as having many other people using it day in
and day out and doing *unexpected* things with it.
The problem I see isn't (just) that things take longer to land than we
expect. The problem is that working on them during feature freeze a)
means they have to be perfect since there won't be any more chance to
refine them and b) means nobody else can work on new development while
they're being worked on.
--
greg
On Mar 16, 2009, at 1:41 PM, Tom Lane wrote:
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.
I think that if you can strictly time-limit the final CommitFest in
the same way that you time-limit the others, then whatever doesn't get
in that last one will be deferred to the first fest for the next major
version.
For those patches that *do* get in for the last CommitFest, they have
to be ready within a month of the last day of the CommitFest month. So
if the last fest for 8.4 was December, then any patches not ready by
Feb 1 would be put off.
This doesn't guarantee that people will get those big patches in
earlier, but it will surely encourage them to do so.
Just an idea.
Best,
David
On Mon, Mar 16, 2009 at 04:41:29PM -0400, Tom Lane wrote:
Gregory Stark <stark@enterprisedb.com> writes:
I think it's clear that stretching feature freezes is a failed
policy.Yeah, it's the same old same old --- once again, we've bent over
backwards to try to accommodate large patches at the end of a
development cycle. I'm not sure that that's ever going to stop,
because every time there are people cheerleading for said patches
and insisting that the release will be so much better if we wait for
them. Somehow we keep expecting that they'll get fixed and landed
in a short period of time.A saner policy would mandate that large patches land near the start
of a development cycle, but I don't know how we get people to do
that.
It's not easy, in the sense of timing and will, but it's not complex,
technically. Basically, we start from a largest size we'll allow at
the last commit fest, and increase it to linearly to, say, twice the
size of the largest patch proposed at the first commit fest.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
David E. Wheeler wrote:
On Mar 16, 2009, at 1:41 PM, Tom Lane wrote:
A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.I think that if you can strictly time-limit the final CommitFest in the
same way that you time-limit the others, then whatever doesn't get in
that last one will be deferred to the first fest for the next major
version.
The earlier commitfests were not time-limited either. They lasted until
all the patches were dealt with; either committed or bumped to next
commit fest. It's just that when you know there still at least one more
commitfest a couple of months ahead, everyone feels more happy to bump a
patch and to have one's patch bumped to the next one. In the last one,
it's a lot harder to do that because that means bumping to the next
release, and you don't even know when the next commitfest is.
The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release,
and beta would start right after the first commit fest, a week or two
after the submission deadline. We failed to enforce that. In the next
release cycle, I think we need to be more explicit about that policy
throughout the release cycle and really enforce it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Hi,
Le 16 mars 09 à 21:41, Tom Lane a écrit :
Gregory Stark <stark@enterprisedb.com> writes:
I think it's clear that stretching feature freezes is a failed
policy.A saner policy would mandate that large patches land near the start of
a development cycle, but I don't know how we get people to do that.
I think Open Source showed that you can't have both time based
releases and feature based releases. Anytime any project try to
accomodate those two objectives, they fail at both.
It seems that PostgreSQL is leaning towards time based releases, which
I think made up the majority in our community. What I'd propose is to
refuse new patches posted in last two commit fests. Those are reserved
to bake what we release.
I'm not sure that's the best compromise you can do, even if it's
definitely one, but it has the merit to be quite clear and easy to
understand for contributors: you want your code to appear in X.Y, get
it reviewed at least once (with feedbacks) before we enter the last
but one commitfest. If you fail at this, you get to (try to) have your
code in X.Y+1, which won't be released that far away (about 1 year
away from a known date).
Regards,
--
dim
On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
The earlier commitfests were not time-limited either. They lasted until all
the patches were dealt with; either committed or bumped to next commit fest.
It's just that when you know there still at least one more commitfest a
couple of months ahead, everyone feels more happy to bump a patch and to
have one's patch bumped to the next one. In the last one, it's a lot harder
to do that because that means bumping to the next release, and you don't
even know when the next commitfest is.The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release, and
beta would start right after the first commit fest, a week or two after the
submission deadline. We failed to enforce that. In the next release cycle, I
think we need to be more explicit about that policy throughout the release
cycle and really enforce it.
I mostly agree with this, but there is one fly in the ointment: if a
patch really hasn't been seriously looked at by a committer, bumping
it recreates one of the problems CommitFests were designed to avoid -
patch limbo. I feel pretty good about the decisions to postpone Hot
Standby and SE-PostgreSQL (not that my personal opinion necessarily
counts for much, but that's how I feel); I would have felt less good
about it if the same decision had been made a month ago. But on the
other hand that means 8.4 will be a month later. If we could have
gone through the same process two months earlier, or if we could have
released 8.4beta and done those reviews on the side during the beta
period, that would have been best of all.
I basically agree with the idea of time-based releases, but if the
committers cherry-pick the patches that are easily dealt with and
never touch the more complex ones, it leads to a different set of
problems... I'm not sure what can be done about that, though.
...Robert
Robert Haas wrote:
On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:The earlier commitfests were not time-limited either. They lasted until all
the patches were dealt with; either committed or bumped to next commit fest.
It's just that when you know there still at least one more commitfest a
couple of months ahead, everyone feels more happy to bump a patch and to
have one's patch bumped to the next one. In the last one, it's a lot harder
to do that because that means bumping to the next release, and you don't
even know when the next commitfest is.The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release, and
beta would start right after the first commit fest, a week or two after the
submission deadline. We failed to enforce that. In the next release cycle, I
think we need to be more explicit about that policy throughout the release
cycle and really enforce it.I mostly agree with this, but there is one fly in the ointment: if a
patch really hasn't been seriously looked at by a committer, bumping
it recreates one of the problems CommitFests were designed to avoid -
patch limbo. I feel pretty good about the decisions to postpone Hot
Standby and SE-PostgreSQL (not that my personal opinion necessarily
counts for much, but that's how I feel); I would have felt less good
about it if the same decision had been made a month ago. But on the
other hand that means 8.4 will be a month later. If we could have
gone through the same process two months earlier, or if we could have
released 8.4beta and done those reviews on the side during the beta
period, that would have been best of all.
Well, we have been working on stuff for the past month so it was not
like we were waiting on SE-PG to move forward.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release,
and beta would start right after the first commit fest, a week or two
after the submission deadline. We failed to enforce that.
Uh, no, that's historical revisionism, cf
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Development_Plan
We expected and scheduled for a longer-than-normal final commitfest.
There's two months in the original schedule, whereas expectation was
that earlier ones would be less than a month (which mostly they were).
What we did say, and didn't enforce, was that patches too large to be
reviewed in a reasonably short time would be bounced. We thought we'd
be able to make that stick if large patches got reviewed and applied
in an incremental fashion over the series of commitfests. For one
reason or another that never happened for SEPostgres. We should try
to analyze exactly why not, although I think the bottom-line answer
there has to do with nobody being particularly eager to work on it.
Hot Standby had a different timeline, and quite frankly should have
never been seriously considered for 8.4 at all. But I think that
as long as SEPostgres was looming on the horizon, we didn't see the
point of being strict about deadlines ...
regards, tom lane
Tom Lane wrote:
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release,
and beta would start right after the first commit fest, a week or two
after the submission deadline. We failed to enforce that.Uh, no, that's historical revisionism, cf
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Development_Plan
We expected and scheduled for a longer-than-normal final commitfest.
There's two months in the original schedule, whereas expectation was
that earlier ones would be less than a month (which mostly they were).What we did say, and didn't enforce, was that patches too large to be
reviewed in a reasonably short time would be bounced. We thought we'd
be able to make that stick if large patches got reviewed and applied
in an incremental fashion over the series of commitfests. For one
reason or another that never happened for SEPostgres. We should try
to analyze exactly why not, although I think the bottom-line answer
there has to do with nobody being particularly eager to work on it.
I think SE-Postgres development timeline of going from feature-complete
to "give us the features we want" really hampred things, and the fact
that we didn't give SE-Postgres much feedback earlier, for the same
reason (feature complete to "give us the features we want").
Hot Standby had a different timeline, and quite frankly should have
never been seriously considered for 8.4 at all. But I think that
as long as SEPostgres was looming on the horizon, we didn't see the
point of being strict about deadlines ...
Hot Standby wasn't in the original plan for 8.4, but someone suggested
"Hey, let's try.", and we did.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
Hot Standby had a different timeline, and quite frankly should have
never been seriously considered for 8.4 at all. But I think that
as long as SEPostgres was looming on the horizon, we didn't see the
point of being strict about deadlines ...
Hot Standby wasn't in the original plan for 8.4, but someone suggested
"Hey, let's try.", and we did.
Simon certainly made a heroic try at it, and I give him full marks for
that. But HS was obviously not ready on 1 November. The point I was
trying to make was that if SEPostgres had not been there, we'd have
probably said on 1 November "sorry, this has to wait for 8.5". As it
was, we let him carry on trying to get the patch to a committable state.
And of course all these things feed on each other --- when it's obvious
that there is no immediate deadline, it's easy to let things slide a
bit further.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Tom Lane wrote:
Hot Standby had a different timeline, and quite frankly should have
never been seriously considered for 8.4 at all. But I think that
as long as SEPostgres was looming on the horizon, we didn't see the
point of being strict about deadlines ...Hot Standby wasn't in the original plan for 8.4, but someone suggested
"Hey, let's try.", and we did.Simon certainly made a heroic try at it, and I give him full marks for
that. But HS was obviously not ready on 1 November. The point I was
trying to make was that if SEPostgres had not been there, we'd have
probably said on 1 November "sorry, this has to wait for 8.5". As it
was, we let him carry on trying to get the patch to a committable state.
Well, we had many other patches in November so it isn't clear that SE-PG
was somehow what kept hot standby in-play.
And of course all these things feed on each other --- when it's obvious
that there is no immediate deadline, it's easy to let things slide a
bit further.
True, but we haven't been sitting around doing nothing, and we had to do
most of what we have done since November whether we had SE-PG or host
standby in play.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Mon, Mar 16, 2009 at 6:20 PM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:The earlier commitfests were not time-limited either. They lasted until all
the patches were dealt with; either committed or bumped to next commit fest.
It's just that when you know there still at least one more commitfest a
couple of months ahead, everyone feels more happy to bump a patch and to
have one's patch bumped to the next one. In the last one, it's a lot harder
to do that because that means bumping to the next release, and you don't
even know when the next commitfest is.The original plan was that anything not 100% ready to commit at the
beginning of the last commit fest will be bumped to the next release, and
beta would start right after the first commit fest, a week or two after the
submission deadline. We failed to enforce that. In the next release cycle, I
think we need to be more explicit about that policy throughout the release
cycle and really enforce it.I mostly agree with this, but there is one fly in the ointment: if a
patch really hasn't been seriously looked at by a committer, bumping
it recreates one of the problems CommitFests were designed to avoid -
patch limbo. I feel pretty good about the decisions to postpone Hot
Standby and SE-PostgreSQL (not that my personal opinion necessarily
counts for much, but that's how I feel); I would have felt less good
about it if the same decision had been made a month ago. But on the
other hand that means 8.4 will be a month later. If we could have
gone through the same process two months earlier, or if we could have
released 8.4beta and done those reviews on the side during the beta
period, that would have been best of all.Well, we have been working on stuff for the past month so it was not
like we were waiting on SE-PG to move forward.
Stuff related to the CommitFest?
AFAICS, the only committer who has done any significant review or
committing of patches in the last month is Heikki, who extensively
reworked and then committed infrastructure changes for recovery on
February 18th (2 days shy of a month ago) and then extensively
reviewed Hot Standby and SE-PostgreSQL. It's really, really good that
those patches have finally received some extensive review, both
because now some version of each of them will likely make it into 8.5,
and because now we have only a handful of patches left that Tom has
said are pretty close to being committable. But I don't see how you
can say it didn't delay the release.
Frankly, if we'd rejected on January 1st all of the patches that (1)
were submitted on time, (2) had been reviewed in a timely fashion, and
(3) had not been resubmitted in largely committable form, we would
have bounced infrastructure changes for recovery, hot standby,
column-level privileges, autovacuum and reloptions, and probably
parallel restore. If the committers who subsequently worked to get
those changes into the tree had devoted an equal amount of effort to
what would have been left in the commitfest after so doing, we would
long since be done with this commitfest and into beta. But committers
are free to spend their time on the projects they think are most
interesting or which their employer is willing to pay them to work on,
so that didn't happen.
This is kind of understandable from the point of view of the
committers, and it's even sorta good for the project as a whole to the
extent that it prioritizes more interesting features over less
interesting ones, but it's pretty frustrating for non-committer
contributors. Any non-committer who pushes for a hard limit on the
length of the commitfest is taking the risk that next time the patch
that none of the committers are interested in will be theirs. So
nobody really wants to argue for that. But the alternative is to
argue that the commitfest should continue until all the patches have
gotten some reasonable minimum amount of review, and that means the
commitfest can continue for a very, very long time during which
non-committers can't expect to get any new patches looked at. That's
not very appealing either. The commitfest process really only works
if the committers review all of the patches submitted within some
reasonable period of time - if that isn't possible, there really isn't
going to be a satisfactory solution.
...Robert
Robert Haas wrote:
Well, we have been working on stuff for the past month so it was not
like we were waiting on SE-PG to move forward.Stuff related to the CommitFest?
AFAICS, the only committer who has done any significant review or
committing of patches in the last month is Heikki, who extensively
reworked and then committed infrastructure changes for recovery on
February 18th (2 days shy of a month ago) and then extensively
reviewed Hot Standby and SE-PostgreSQL. It's really, really good that
those patches have finally received some extensive review, both
because now some version of each of them will likely make it into 8.5,
and because now we have only a handful of patches left that Tom has
said are pretty close to being committable. But I don't see how you
can say it didn't delay the release.
You are assuming that only commit-fest work is required to get us to
beta. You might remember the long list of open items I faced in January
that I have whittled down, but I still have about twenty left.
Tom has done work fixing optimizer bugs introduced in 8.4. I have had
EnterpriseDB work to do and am working on the release notes now. The
bottom line is that there is lots of cleanup required to get to beta
independent of the last commit fest work.
Frankly, if we'd rejected on January 1st all of the patches that (1)
were submitted on time, (2) had been reviewed in a timely fashion, and
(3) had not been resubmitted in largely committable form, we would
have bounced infrastructure changes for recovery, hot standby,
column-level privileges, autovacuum and reloptions, and probably
parallel restore. If the committers who subsequently worked to get
those changes into the tree had devoted an equal amount of effort to
what would have been left in the commitfest after so doing, we would
long since be done with this commitfest and into beta. But committers
are free to spend their time on the projects they think are most
interesting or which their employer is willing to pay them to work on,
so that didn't happen.
I agree if we had said "no" to those patches we could be farther now,
but I am not sure how much farther.
This is kind of understandable from the point of view of the
committers, and it's even sorta good for the project as a whole to the
extent that it prioritizes more interesting features over less
interesting ones, but it's pretty frustrating for non-committer
contributors. Any non-committer who pushes for a hard limit on the
length of the commitfest is taking the risk that next time the patch
that none of the committers are interested in will be theirs. So
nobody really wants to argue for that. But the alternative is to
argue that the commitfest should continue until all the patches have
gotten some reasonable minimum amount of review, and that means the
commitfest can continue for a very, very long time during which
non-committers can't expect to get any new patches looked at. That's
not very appealing either. The commitfest process really only works
if the committers review all of the patches submitted within some
reasonable period of time - if that isn't possible, there really isn't
going to be a satisfactory solution.
Again, this assumes the commit-fest is the only old on beta starting.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
You are assuming that only commit-fest work is required to get us to
beta. You might remember the long list of open items I faced in January
that I have whittled down, but I still have about twenty left.Tom has done work fixing optimizer bugs introduced in 8.4. I have had
EnterpriseDB work to do and am working on the release notes now. The
bottom line is that there is lots of cleanup required to get to beta
independent of the last commit fest work.
Sure. I don't have a problem with that. But I don't see what it has
to do with the point of my original post, which is that it we can
either make the release happen on time, or we can get all of the
patches reviewed, but we can only do both if the committers have the
time and energy to make that happen. Do you disagree?
...Robert
Robert Haas wrote:
You are assuming that only commit-fest work is required to get us to
beta. ?You might remember the long list of open items I faced in January
that I have whittled down, but I still have about twenty left.Tom has done work fixing optimizer bugs introduced in 8.4. ?I have had
EnterpriseDB work to do and am working on the release notes now. ?The
bottom line is that there is lots of cleanup required to get to beta
independent of the last commit fest work.Sure. I don't have a problem with that. But I don't see what it has
to do with the point of my original post, which is that it we can
either make the release happen on time, or we can get all of the
patches reviewed, but we can only do both if the committers have the
time and energy to make that happen. Do you disagree?
I agree. My point was that we let hot standby and se-pg stay around
longer than necessary because we were involved in other things. We
could have said they had sufficient review in January if those were the
only things holding us up.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
It's not like my opinion has any weight but still,
On Tuesday 17 March 2009 16:15:21 Robert Haas wrote:
either make the release happen on time, or we can get all of the
patches reviewed, but we can only do both if the committers have the
time and energy to make that happen. Do you disagree?
Sure I do.
You can either have time based release or feature based one. Full stop.
That do not depend on time and energy of people involved, nor to their role in
the community (contributor, reviewer, commiter, beta tester, etc)
Regards,
--
dim
On Tue, Mar 17, 2009 at 11:18 AM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
You are assuming that only commit-fest work is required to get us to
beta. ?You might remember the long list of open items I faced in January
that I have whittled down, but I still have about twenty left.Tom has done work fixing optimizer bugs introduced in 8.4. ?I have had
EnterpriseDB work to do and am working on the release notes now. ?The
bottom line is that there is lots of cleanup required to get to beta
independent of the last commit fest work.Sure. I don't have a problem with that. But I don't see what it has
to do with the point of my original post, which is that it we can
either make the release happen on time, or we can get all of the
patches reviewed, but we can only do both if the committers have the
time and energy to make that happen. Do you disagree?I agree. My point was that we let hot standby and se-pg stay around
longer than necessary because we were involved in other things. We
could have said they had sufficient review in January if those were the
only things holding us up.
Right, that's what I think too. Or at least we could have said that
we weren't going to review them any more right now, leaving aside the
question of sufficiency.
Basically, for the project to grow, it needs more committers, and the
precondition for being added as a committer should be a promise to
spend a certain amount of time reviewing and committing patches other
than your own. According to the wiki, we have 15 committers, which is
more than enough, but most of those are inactive or are just there as
maintainers for very specific portions of the code.
Failing that, we will continue to argue about whether to slip releases
or ignore patches. I don't like either of those options very much.
...Robert
