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.



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to