public inbox for [email protected]  

help / color / mirror / Atom feed

From: Gregory Stark <[email protected]>
To: Heikki Linnakangas <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Feature freeze progress report
Date: Sun, 29 Apr 2007 16:47:58 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>


"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

view thread (98+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Feature freeze progress report
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox