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
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
