Re: 8.4 release planning

Robert Treat wrote:
> The problem is that the pain point is extremely high for missing a given
> release cycle. If you don't make a specific release, you have a 12-14 month
> wait for feature arrival. Given that choice, someone who deperately need (aka
> wants) HS/SEPostgres/Win32/HOT/IPU/etc... will likely be willing to push a
> release 3-6 months for that one feature.

There will always be some features that people are willing to push a
release for, if it's a feature they want. At least I hope so - because
that means we keep adding new features that people want. But as long as
there is some overlap in development timelines - which there will
*always* be - there will always be some patch that is not quite ready on
time.

If the release is pushed back, maybe some other patch could also have
been finished by the new deadline - should that also be included? What
about a completely new feature that isn't even started yet, but that
could easily be finished before the new deadline? What makes those less
worthy?

The question is, how long do we make people wait for *other* features.
It delays this version *and* the next.

> Incidentally, this is probably why people didnt worry about making a given
> commitfest. The pain point was low, so there was no percieved need to rework
> a patch for a specific commit, since there was another one just a couple
> months away. However, we still see a rush of patches at the final freeze
> because people know that "there is no tommorrow" at that point.

A problem at this point is that we are basically serializing the project
over one or a couple of patches. All those people who aren't qualified
to review/work on HS or SEPG are left in a position where they can't get
anything done. Sure, they can work on patches offline, and add them to a
hypothetical future commitfest that they have no clue when it's going to
happen, so they don't know when they need to be available to deal with
feedback. And we're back to ending up with a lot of conflicting patches
simply because they sit in the queue for too long. That's a lot of
developer talent wasted.

The commitfests were designed in part to get around this - to get
developers quick feedback so they can get on with more features. The
final commitfest being much longer than the others by design already
makes this hard. Dragging it out even longer makes it an even bigger
failure in this way.

We can't just say that everybody should help with these patches. Not
everybody is qualified to do so, or has an interest to, while they're
still both qualified and interested in working on other things for 8.5.

>> In the third
>> place, unless we get an upgrade-in-place process that works all the
>> time, we would be looking at maintaining twice as many back branches
>> in order to provide the same kind of release lifespan we have today.
>> We are at the limit of what we can realistically do in back-branch
>> maintenance already :-(
>>
>
> Yeah, I can't argue with that. I'm not sure it's an unsolvable problem though;
> if odd/even release maintenance doesn't sound good, we could do something
> like ubuntus LTS, where we pick 1 release every 3 years to make a long-term
> support commitment (I think 5 years is our current max), and keep other
> releases on a shorter lifespan (1 or 2 years). Certainly having IPU (or is
> that UIP?) would make that an easier decision.

We're still going to have to pay the full cost of doing a release every
time. With beta/rc management, release notes, announcements, postings,
packaging and all those things.

The PostgreSQL tree tends to be a lot more stable than others. In many
cases, you can just snapshot CVS HEAD and get more or less the same
things. Perhaps if someone were to simply maintain a bunch of tags or
branches against "known feature-points in the system" in a separate SCM
somewhere that'd be enough for people who desperately need the features
- or who just want to test them out earlier. That would be close to zero
cost for the core project to maintain.

//Magnus