Fwd: GNOME 2.22 module inclusion discussions heat up.

["Elijah Newren" <newren gmail com>]

Hi,

I realized that this email may be of use to others in the future with
the same question, so I'll forward it to r-t and then link to it for
additional information from
http://live.gnome.org/ReleasePlanning/NewReleaseTeamMembers (under the
'how long does it take' section).  If anyone wants to clean it up or
add more details and stick it directly in the wiki, feel free.


---------- Forwarded message ----------
From: Elijah Newren <newren gmail com>
Date: Jan 5, 2008 10:51 PM
Subject: Re: GNOME 2.22 module inclusion discussions heat up.
To: Lucas Rocha <lucasr gnome org>


Hi Lucas,

On Jan 5, 2008 9:43 PM, Lucas Rocha <lucasr gnome org> wrote:
> It would be an honor to replace you in the Release Team. :-)
>
> > There's some general reading at
> > http://live.gnome.org/ReleasePlanning/NewReleaseTeamMembers about the
> > work involved.  The page probably looks a bit daunting, but that's
> > just because it describes all the jobs of the entire release team
> > rather than the job each person is expected to do.
>
> The only thing that is not clear to me is how much time (per week) it
> takes to be part of the RT.
>
> Thanks a lot for the trust!

Great, I'm glad you're willing.  I'll send an email to the
release-team in a couple minutes.  They probably won't have time to
respond before the new module decision meeting tomorrow, but I think
you should attend it in #release-team at 19:00 UTC if you can.  I
doubt anyone would object, though you can ask at the beginning if
anyone does.  Sadly, I have a timing conflict so I'll be showing up
late.

As for the time per week it takes, it varies very wildly.  It can be 0
minutes several weeks, and then huge amounts of time other weeks.  One
thing that helps considerably is that we've tried to build the team to
be reliable, meaning that if someone gets overloaded in some other
aspect (module maintainence, conferences, work, life, etc.) then even
if they "disappear" for a few weeks or even months from release team
duties things can still go on smoothly.  I believe everyone on the
team has taken advantage of this for at least a few weeks at a time,
and most have taken advantage of it for even for a few months when
special duties arise and they know they can get back to contributing
after a certain period of lower activity.  Just try to keep the other
team members informed.

In general, I'd say the big recurring time commitments are:
 - Keeping up with d-d-l and other communication (mailing
   lists/planet/irc, etc; obviously, you can't and don't have to keep
   up with everything, but it's important to keep in tune with the
   community as much as you reasonably can; from everything I can
   tell, you already do this quite well.)
 - Twice-per release meetings.  We have always aimed to keep these
   meetings to one hour, but they last almost exactly two hours each.
   It's important to spend at least a couple hours preparing for some
   of these, so it averages to an hour or two per month, but it comes
   all at once in spurts.
 - Fulfilling any tasks you volunteer for (or don't successfully
   un-volunteer for when others nominate you, since we like to prod
   others into doing more work) at the twice annual meetings.  This is
   under your control, though, since you agree or disagree with what
   work you add to your load at the meetings.  Most of these tasks
   tend to be small other than the handling of point releases (see
   below).
 - Approving freeze breaks can vary quite a bit.  It only becomes
   relevant towards the end of the cycle, though near the very end it
   can consume a half dozen hours a week (when it gets bad).
 - Doing releases.  We try to break these up, so that of the 12 or so
   point releases per cycle (4 stable, 8 unstable) people don't end up
   with more than 2 or 3.  However, we occasionally find one person
   doing more than their share if we can't get enough team members to
   volunteer.  (In the distant past, Jeff used to do every single
   point release, so we're definitely improving; we just have some
   more work to do in this area.)  See below for more details on
   timing (*).
Other things tend to be once per cycle, only take a few minutes here
or there, or are things where you notice a need in the community for a
new initiative to be spearheaded and decide to take it on (e.g. if
Murray burns out on doing release notes, we're in *serious* trouble
and someone will need to figure out something.)

* Time needed for releases: As far as releases go, after I had done a
couple, I once had a groove where I'd get everything done from start
to finish in 6 hours, with most of the time being waiting for
downloads and builds.  Granted, at that time I also was very active in
jumping on build issues between releases with maintainers, I had a
fast connection, and our module list was shorter back then.  So you
will likely have more waiting time and will likely also occasionally
have to find maintainers and request fixes for build issues (or
manually revert some modules to slightly older releases or find other
workarounds).  So it might be a factor of 2 or 3 more than 6 hours
(though I think it's closer to 6 in general), but still the vast
majority of it is waiting time.  The big issue is just being around to
start the next step (edit autogenerated modules after downloads, or
start build, or run build, or nag maintainers, or include new
maintainer tarball needed to fix build).

Does this help explain the time commitment better?

Elijah