On Wed, Jan 23, 2013 at 10:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think there's been something of a professionalization of PostgreSQL
> development over the last few years. More and more people are able
> to get paid to work on PostgreSQL as part or in a few cases all of
> their job. This trend includes me, but also a lot of other people.
> There are certainly good things about this, but I think it increases
> the pressure to get patches committed.
Also many of the new developers who were previously working from
proprietary companies (includes me) may not have seen so long cycles
for feature development, from design to acceptance/rejection. The
problem aggravates because the same developer was previously doing
development at much much faster pace and will find our style very
conservative. Of course, the quality of work might be a notch lower
when you are coding features at that pace and you may introduce
regression and bugs on the way, but that probably gets compensated by
more structured QA and testing that proprietary companies do. And many
of these developers might be working on equally important and mission
critical products even before. I know we are very conscious of our
code quality and product stability, and for the right reasons, but I
wonder the overall productivity will go up if we do the same i.e. have
quick feature acceptance cycles compensated by more QA. The problem is
being a community driven project we attract more developers but very
less QA people.
Would it help to significantly enhance our regression coverage so that
bugs are caught early (assuming that's a problem) ? If so, may be we
should have a month-long QAfest once where every developer is only
writing test cases.
Would it help to have a formal product manager (or a team) that gets
to decide whether we want a particular feature or not ? This might be
similar to our current model of discussion on hackers but more time
bound and with the authority to the team to accept/reject ideas at the
end of the time period and not keeping it vague for later decision
after people have put in a lot of efforts already.
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
