"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> I like the idea of draining the patch queue mid-way through the release cycle.
> That'll hopefully encourage people to submit patches earlier in the release
> cycle, knowing they will be reviewed. It'll also give people working on
> external projects, drivers and tools, a checkpoint to sync with.
>
> 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.
On other projects people use these snapshots or dev releases because checking
stuff out from CVS is likely to get you a source tree that won't even build
let alone run cleanly. It's also nice to have everyone using the same
checkouts when report bugs or submitting patches.
But it's not because we're afraid some user will run a CVS checkout that
Postgres CVS is kept clean. Postgres CVS is kept clean because that's just the
way the Postgres developers think it should work. Doing regular snapshot
releases isn't going to cause that to get worse.
> One could also argue that we don't need the mid-cycle checkpoint, if we just
> keep the patch queue empty all the time. In the end, it comes down to how many
> people we have actively reviewing patches and giving feedback
I would argue that. In fact I would argue it would be *easier* to keep the
patch queue empty all the time than to spend months reviewing and merging
six-month-old patches once a year. But I still have hope this is a problem
that will fix itself naturally with time.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com