Skip site navigation (1) Skip section navigation (2)

Re: 8.5 development schedule

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>,pgsql-hackers(at)postgresql(dot)org,Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Subject: Re: 8.5 development schedule
Date: 2009-07-01 02:57:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I'm in agreement that we should try to provide feedback (in general, to
> > be honest) on patches/suggestions/ideas/designs/etc as quickly as
> > possible.  The commitfest approach is good for this when it's "in
> > motion", but it's been stale for months.  +1 from me for starting early.
> > To flip it around a bit, I don't know that there's actually a moratorium
> > on providing feedback?
> Well, I wouldn't put it as strongly as "moratorium", but ... the point
> of having a release cycle is that at certain times people are supposed
> to focus on stabilizing and testing a release, not on working on new
> development.  

I certainly agree with this.  I tried to qualify my comment above in the
sentence which followed it, but apparently I didn't do a good job.

- This only applies before feature freeze (eg: right after 8.4 is out)
- No work being done on a current patch (eg: waiting for feedback)
- Have cycles to spare

Our current arrangment is based on a premise that a given person will
have X cycles in a month to work on PG, and that they have >=X amount
of work to do on developing their patch(s) that month.  I feel like
there are a number of patch submitters who have X cycles to work on PG,
and <X work they'll be able to do on their patch in a given month (in
part because at some point they'll submit it and then wait for
feedback).  I see minimial drawback to encouraging those people to
review other patches with any extra cycles they have, even if we're not
actually in a CF-mode at that point.

> If, at any time in the past six months, I were to have
> gone off and reviewed a patch that's clearly 8.5 material, that's
> man-hours taken directly away from getting a solid 8.4 release out the
> door.  Which means that much longer until 8.4 does get out, which hurts
> everybody including the submitter of the premature patch.  So in general
> I agree with the viewpoint Peter outlined that working on new
> development during beta period is not really playing by the rules, and
> that people who expect feedback for new development during beta period
> simply don't understand how the project is supposed to work.

It wasn't my intent to imply this would be done during feature-freeze,
or beta, but rather something to be done during development.  Perhaps I
should have phrased it as "the moratorium on looking at patches can end
when 8.4 is released, and not be fully reinstated until 8.5 beta".

> Anyway, as of now that's all moot until next spring.  But it's still
> true that people want time to work on their own patches, which is why
> we came up with the commitfests.  It's so you can get some time to work
> without feeling guilty about not reviewing other people's work instead.

I definitely think that's good, and to be honest I don't think my
suggestion would apply to core much at all (they've always got >=X work
to do on patches :), but as we saw during the commitfests in 8.4,
there's a number of non-core folks out there volunteering to review.  If
they're willing and able to spend cycles reviewing other patches rather
than twiddling their thumbs waiting for feedback, let's encourage that.



In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-07-01 03:18:06
Subject: Re: 8.5 development schedule
Previous:From: Andrew DunstanDate: 2009-07-01 02:18:05
Subject: Re: 8.5 development schedule

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group