There is no release manager! There is no release manager!

[Jordan K. Hubbard]

On Oct 7, 2008, at 7:36 PM, paul beard wrote:

> FAIL.
>
> There has been a release manager and portmgr@ team for quite some  
> time and this bug lingers, festers even.

I don't know which reality you have been living in, but I think the  
weight of evidence points to exactly the opposite conclusion:  There  
has not been a release manager or portmgr team for quite some time,  
which is why this and other bugs have been stuck in release limbo.   
Ryan has done an excellent job of summing that up and pointing to both  
the portmgr announcement and jmpp's rather excellent "what it takes to  
make a release" checklist (and I say "rather excellent" because,  
frankly, most release engineers do not bother to document their  
process anywhere near as well), so I will not belabor the point.

Back when I was release engineer for FreeBSD, a job I held for some 9  
years (which is one of the many reasons you don't see me exactly  
leaping at this opportunity myself - I've done my time in the box and  
then some), I also went out of my way to automate the process as much  
as possible, laziness being the mother of invention and all that.  The  
end result was that just about anyone could (and still can) type "make  
release" at the top of the FreeBSD source tree and, assuming  
everything compiled and the internal consistency checks passed, see a  
full and complete set of bootable ISO images pop out the other end.   
This is still used on a daily basis to create the "snapshot releases"  
of FreeBSD-current, as well as by the current FreeBSD release  
engineering team, and I would therefore encourage whomever steps into  
these shoes to follow the same path since it's clearly paid off.  It's  
a little more work up-front to make things turn-key like this, but it  
more than pays for itself in labor savings over the long term, in  
addition to also making it much easier to appoint "interim release  
engineers" during periods where the primary release engineer is burnt  
out or on vacation.

So, consider that my two cents added to jmpp's already fine release  
engineer checklist.  Well, OK, maybe three cents since I'd also like  
to take the opportunity to beat the drum (again) for the notion of  
simply tagging trunk and releasing from the tag rather than going to  
all the overhead of branching and trying to keep track of what should  
be merged and what should not.  Were macports a much larger project,  
or perhaps one simply better staffed with "infrastructure folk", I  
would actually argue in favor of branches since it's certainly the  
more controlled way to go, but I don't think the project can really  
afford the overhead right now and the model of declaring an impending  
release, converging things in trunk, tagging, and then declaring the  
trunk "open" again is one that can certainly work with a little  
overall project discipline.  Given that Subversion also allows one to  
easily "promote" a tag to a branch (since they're really the same  
thing), you also always have the option of creating a temporary branch  
for any late-breaking issues that require "just a couple more fixes"  
without requiring that trunk be re-frozen.  I think it's the best of  
both worlds, and certainly a lot less work than requiring the release  
engineer(s) to branch and do n weeks worth of merges until the release  
is ready, which is one of the reasons I think our releases became so  
laborious and infrequent.

> If this is part of a strategy of annoying users to the point where  
> they sign up to be release manager just so it gets done, I'm not  
> sure it will work. Civilians like me have no idea what the actual  
> steps are to get a release cut, even one so trivial as the bug fix  
> for 1.6. If the guys who were doing it had a hard time with it, what  
> would make someone who isn't an active port maintainer think they  
> could do it?

Because release engineering is not rocket science, it's simply time  
and communications intensive.  "Anyone" can do it, to some degree,  
assuming a basic engineering background and the ability to build and  
test bits.  The part that suck up all the time is herding all the cats  
and managing the usual debate around what absolutely must, or must  
not, go into the next release (ultimately a judgement call, which is  
why good release engineers are also possessed of almost infinite  
amounts of patience and Solomon-like skills).

> Absent a release manager or team, what would it take to get a  
> release schedule (quarterly? monthly?) and/or a roadmap? Not sure it  
> makes a lot of sense to fret about a release manager if we don't  
> really know what a release is or why we need one. A roadmap/set of  
> benchmarks/goals would help and from there a release calendar could  
> be derived.

Roadmaps are great.  I am a big believer in Roadmaps.  The only  
problem with them in all-volunteer projects like this one is getting  
everyone to (a) agree on the roadmap and (b) actually execute it with  
any accuracy.   Sometimes it's a lot easier to simply let things  
progress organically, as various volunteer resources have the time and  
inclination to contribute, filling in the "missing pieces" by begging,  
wheedling and cajoling (or, occasionally, even simply doing it  
yourself) and, where that fails, being also willing to accept that not  
every release is going to have everything you want in it.  As long as  
they keep coming out with any regularity, you (the hypothetical  
volunteer RE) will gradually accumulate both the credibility and good  
will necessary to motivate other volunteers to take the release  
engineering schedule and goals more seriously.  It's not an overnight  
process.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20081008/98f13a95/attachment.html