Re: 8.4 release planning

On Wednesday 28 January 2009 23:42:11 Robert Haas wrote:
> > Our usual process *is* to try and circumvent our usual process. And I
> > believe it will continue to be that way until we lower the incentive to
> > lobby for circumvention.
>
> I think Tom and Bruce have both pretty much stated that they're not
> keen on a shorter release cycle, and they're the ones who would have
> to do the work, so I think this argument is going nowhere. Moreover,
> I agree with them. Having short release cycles would probably be a
> good idea if we had a larger community with more patch authors, more
> reviewers, and more committers.

more reviewers and more committers would actually be an argument against
shorter release cycles, since we'd have a better shot at actually getting all
patches in in a timely fasion. we dont, and we cant change that. again,
thats the whole point of this... look at the variables and see which ones we
can and cant change, and if those changes would address the causes.

> As it is, I think it would simply
> mean that the committers would spend more time doing releases and
> back-branch maintenance, and correspondingly less time to do what we
> really want them to do: review and commit patches. That problem is
> already pretty severe, and it would be a bad thing if it got worse.
>

read up-thread, i've already shown that this would not be the case. remember,
we reduce the pressure from the large, complex patches that bottleneck the
process, which allows more parralell review/commit.

> If anyone really can't wait a year for a new feature, they can
> backport it to the previous release, or pay the patch author to do it.
> If they were paying the patch author to develop the feature in the
> first place, it shouldn't be a horribly expensive proposition.
>

i dont think we as a community should encourage people to pay for private
releases. that is a *really* bad idea.

> At the moment, what we really should be doing is conducting final
> reviews of as many patches as possible and trying to make sure that
> they are in good shape to be committed so that the people who have put
> in hard work for THIS release have a chance to see that work go out
> the door in a somewhat timely fashion.
>

not that i disagree, but if we can improve things for the people working on
the next release, well, I think that's a good idea too, and I dont see how
doing nothing is going to help.

--
Robert Treat
Conjecture: http://www.xzilla.net
Consulting: http://www.omniti.com