Re: damage control mode

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Basically, here's my feeling. Either we have a rule that we can
> bounce large, previously-unseen patches from the final CommitFest of
> the release cycle, or we don't. If we do, then we should go ahead and
> do it, and we should do it early when it will have more effect rather
> than putting a lot of time into those patches and doing it only once
> the release is already late. On the other hand, if we don't, then we
> should have to core team publish a clear statement that all
> CommitFests are equal and we're just going to slip the schedule if
> there are too many patches for the last one.

Yeah, problem being we're trying to solve at least two different
problems here: make contributor happier to contribute to PostgreSQL by
giving them early feedback and releasing their code sooner rather than
later, and having a time-based release.

The two points contradicts exactly at the end of the cycle, when we have
to decide we give the priority to the schedule or the feature
set. Knowing that being late now means being even more late on next
cycle, so contributions missing the boat are even more impacted.

All of this is stating the obvious one more time, but I think that's the
reason why the rule is not written on any wall, and why nobody tried to
enforce it in any way yet.

>> What I think have been
>> said before is that doing so would not help stabilizing the tree before
>> release.
>
> Sorry, I'm not following this sentence.

Trying to state some more obvious, so as to be sure we're talking about
the same things.

> I am definitely pushing for the schedule. It's a maxim of software
> development that you can have time-based releases or feature-based
> releases, but not both. In this community, we have time-based
> releases early in the cycle and then they change to feature-based
> releases late in the cycle. As we found out with 8.4, trying to be
> both on time and feature-complete can result in failing at both. I
> feel that we've been eminently fair to contributors in the 8.5 cycle -
> it's something that I have personally worked very hard on - and I
> actually also feel that what I am proposing now is also fair. It may
> not be very popular, though.

This has already said before, but let's try it again.

One way to solve the problem could be to have a dedicated release
management team, taking responsibilities after last alpha of the cycle
until release: open items, getting to beta, then fixing any bug testers
find, some advocacy people for having more testers, etc, then release
candidates management and then .0 release.

While this team would work on this, we could maybe have the next cycle
open for development, with its first CommitFest happening while 8.5.0 is
not yet out the door.

Of course it has been said more than once that some resources will have
to be there on both the teams, and that we want people to dedicate to
beta testing rather than new features (which is always more fun).

My guess is that current state of affairs is not working that well,
forcing people to concentrate on stabilizing current beta will push them
to procrastinate if that's not what they want to do. If instead they are
working some more on their next patch, what do we lose?

Now running the release management parallel to the first one or two
commit fest of the next cycle would mean less resources to review and
commit that ones, but maybe a better overall average.

The advantages of doing so, if not clear, are that developments never
stops and it's even easier to return a patch in the last commitfest,
we know when next one begins.

Frankly, forcing people into release management and quality assurance
when they do not want to do it does not sound the best way to offer the
best stable code possible at .0 time. And opening a commitfest were it's
possible nothing will get committed (but only reviewed) because resources
are not available sounds only fair. If you really want your stuff
committed, go help stabilizing the beta.

Regards,
--
dim