On 30 Jan 2006 08:28:00 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> I see what you're saying. But "short-change" may be too strong a
> word. Everyone chooses what they'll work on. If Victoria decides to
> work on release N, instead of doing trunk work, she's not being
> "shortchanged" -- she could just let someone else carry the load for
> release N while she concentrates on trunk. Then she could help out
> with N+1 a few months later, if she wants.
Nice theory, but it doesn't work that way in practice. We maybe have
two or three people who are actually comfortable pushing out a
release. For 1.3, we brought a new RM up-to-speed. A lot of us spent
time going through the RM process with our new RM (hi Dave!) to try to
help him get acquainted with how to do a release in Subversion land.
He's now more-or-less up-to-speed now, but there's no guarantee he'll
be available when you want him for 1.4.0 RCs. If not, someone else
who does RMs will have to be drafted, or we'll start the entire
RM-training process again - with the load on the folks who know how to
do a release increased again. Not every developer is willing to be an
RM, so it's not that large of a pool to select from.
> In practice, yes, many developers want to be at least somewhat
> involved with release work, and that's a good thing. We should be
> careful not to release *too* often, as we want to encourage that
> involvement.
The current proposal of doing a release every three-four months means
that 50% of the time we're going to be in 'release mode' (counting two
months at a minimum to shepherd a release through our necessary
approval and soak periods).
If we keep at six month release cycles, it means that we're still 33%
(2 out of 6 months) of the time doing releases. But, that gives those
RM-centric developers four months to work on other stuff - and perhaps
rethink how we do releases to make it better.
> However, the release load is pretty light until the last couple of
> weeks of the process, when testing and signing candidate tarballs
> happens. Yes, there's review & voting, but it's really okay to stay
> out of that if one needs to concentrate on something for a while --
> I've done that with certain releases before, and never felt it was a
> big problem.
For x.x.0 releases with all of the RCs, it's actually a *lot* of work.
Ask Dave. Patch releases are much easier to cut as the initial
testing has been done on the minor. But, declaring a trunk version as
stable, IMHO, places a lot of work on the RM to try to understand what
changed and where to look for new problems.
Most people didn't actually test anything until we started the tarball
release candidate process for 1.3.0. At that point, we found a
*large* number of bugs that had to be squashed before we could do the
first release candidate for 1.3.0. We did a lot of work to make sure
that our first RC for 1.3.0 was high-quality. I think Dave was
thinking about shooting me for finding all sorts of problems that
would stop a release candidate from being cut. =)
> Let's just take it on a case-by-case basis. Do you feel that
> branching 1.4 in February, and thus going through crunch sometime in
> March, is too much? We wouldn't have had a crunch since December, and
> it's not like the "crunches" are all that dominating, imho...
I think releasing 1.4.0 in March after releasing 1.3.0 in January is a
really bad idea. It also means that the RM team needs to start
preparing now. We decided to punt the whole dependency split
distribution thing for 1.3 because we were breaking-in a new RM. We
should probably revisit that for 1.4. This will require someone to do
work with dist.sh to get it to build the new package schemes and test
it everywhere. It's not an insignificant task. And, it probably all
needs to be done before the first release candidate is cut. Having
very little down time for RMs also means that we can't tweak how we
distribute or cut releases. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 30 19:28:32 2006