Dave Page wrote:
>
>> But I don't like the idea of making a release out of it. Who would
>> use such a release? No one in production. Making a release comes with
>> a cost, even if it's just a dev release.
>
> Agreed. That would have the opposite effect of what should happen.
>
> I like the idea of having a sync point mid cycle, however, what I'd
> like to see even more is an improved system in which we put less
> pressure on the few committers we have, and give them more freedom to
> commit patches they may not understand fully themselves by having an
> improved community review and feedback process to give the patches the
> approval they need. Doing so might allow us to keep the queue of a
> more or less fixed, short length throughout the cycle. There would be
> a few advantages to this:
>
>
I don't think we need a sync point. I think we need to get better at
setting expectations and at managing the patch queue so that it gets
drained better all the time. Nothing can be more frustrating for patch
authors than to have patches in the queue for a very long time. They
bitrot, and we sometime end up throwing curly questions at authors long
after the issues are hot in their minds. I'd like to see us set
ourselves some targets for handling patches. Something like: patches
held over from feature freeze from the previous release will be reviewed
within two months of the tree re-opening, and all other patches will be
reviewed within one month of being submitted. That implies that one
month after feature freeze the tree will only be open for bug fixes. Any
patches unapplied at that time would be held over. Maybe that would give
pgAdmin and friends enough head room to catch up.
cheers
andrew
