management system is an important free software project, providing a solid
and capable database system. As of this writing, the project's development
states that the code has been in a feature freeze since the
beginning of April, with all candidate patches up for review and merging
into the source repository. That these patches will be fixed up, if
necessary, and everything will come together for a planned 8.3.0 release in
PostgreSQL hacker Bruce Momjian recently sounded an alarm about this release:
Based on our progress during this feature freeze, we will not
complete the feature freeze until August/September. I think we
need adjust expectations about an 8.3 release date, and decide if
we want to radically change our work process.
It seems that the pile
of candidate patches is not being reviewed in any sort of timely
manner. So they remain candidates and the 8.3.0 release fails to take
form. There are, it seems, a few directions the project could take in
response to this problem:
- Continue with business as usual and ship a very late release.
Certainly PostgreSQL would not be the first free software project to
take that approach.
- Reopen development so that simpler patches which are not currently in
the queue could be considered.
- Defer all patches which have not been reviewed and ship 8.3.0 with the
code which is in the repository now. Some developers are in favor of
this course, but others see it as unfair to the developers who have
had patches in waiting since well before the 8.3 cycle began.
- Simply shove all the pending code into the repository and hope for the
best. This one seems unlikely: the PostgreSQL hackers have a hard-won
reputation for exceedingly solid code that they will not want to put
at risk just to get a release out more quickly.
As of this writing, the project has not announced any decisions, but the
developers have decided not to change the project July release date - yet.
Stay tuned and we will eventually see what comes out.
This episode points out, once again, an important aspect of our process:
often the limiting factor in a free software project is not the number of
developers, but, instead, the number of reviewers who can look over the
code those developers create. This shortage is especially acute in
projects (like PostgreSQL) which insist on relatively rigorous review
processes. But, in any project, the "many eyeballs" factor is important;
if the eyeballs are not there, the free software process is not working as
well as it should.
Reviewing patches can be unrewarding work. It requires great attention to
detail and the energy to look for bugs in code without the corresponding
gratification of having actually written that code. Poking holes in other
peoples' work is not fun, especially when those people do not react well.
Often it can seem like the same mistakes come around again and again,
leading reviewers to wonder if anybody is actually listening to them.
So reviewers can get a little grumpy at times. The people who can do the
best reviews are usually also some of the project's best developers, and,
often, they would rather be developing. So code piles up and the review
does not happen.
In the long term, the community will need to find ways to encourage more
code review if we are serious about the quality of the work we are doing.
Better public acknowledgment of reviewers might be a good start; credit is,
after all, one of the chief currencies in which we trade. Perhaps we need
some better tools to support the review process; along these lines, the
recently announced review
board project is worthy of some attention. Some projects have
considered requiring potential contributors to review some patches before
their own contributions can be merged. The right way to encourage more
code review will probably differ from one project to the next, but, one way
or another, we can certainly find solutions to this problem.
to post comments)