"Heikki Linnakangas" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
