Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

Eric, these are the main things I need from you ASAP, in order:

1) Schedule and plan for the 0.9 grimoire release.

   I know you don't take the chair until the 1st but I want this decided
   and announced ahead of then to avoid too long of a break between
   releases.  *If this isn't decided by the 1st, I'll cut the -rc branch
   then and solicit a volunteer to drive the release as we have done for
   the last 3 releases.*  I would rather you find the volunteer / do it
   yourself / set the timeline / change the plan entirely / etc.  I'm fine
   continuing to do the git branching and stuff for these releases, in any
   case.  You can pick that up later if you want or I can just keep doing
   it as the git admin guy person.

2) Give me your backup plan when you aren't around and things need to
   happen.
   
   As I said to the other leads before, this can be whatever works for you,
   and I'll honor it as long as it's reasonable.  Assistants, vote
   requests, defer to PL, whatever.  If you don't tell me otherwise before
   next time something needs to be decided in your absence, it defaults to
   PL decision.

3) Review the current ACLs and let me know what to do with them as of the
   1st.  This includes who has stable(-rc) grimoire commit access and who
   can approve integrations to stable(-rc) in bugziilla.

4) Review the current bugzilla usage process and implement something that
   better matches what we really do.  This is big, but it's a "need" vs a
   "nice to have" simply because I'm having to do too much of that myself
   right now and it's preventing me from doing other things.  I would like
   this resolved very soon after the 1st, if not when you take the chair.
   I want to hand almost all this grimoire stuff back to you so I can move
   on to getting the installer all the help it needs.

   Right now the documented bug process is something like:
   - file bug against highest branch it applies to, against the section
     it's in
   - fix bug in test and mark it fixed
   - reporter verifies
   - once it hits the branch it was filed against it gets closed

   The actual process is more like:
   - file bug against highest branch it applies to, against the section
     it's in
   - hoefully the section was sm-grimoire-bugs or a section someone active
     watches, else the bug gets lost there til someone goes and reassigns
     it
   - fix bug in test
     - if it was filed against test, mark it fixed
     - if it was filed against stable, mark it "fixed in lesser branch" and
       possibly request integration
       - randomly some people who aren't Jeremy check these requests some
         days (and some days don't) and decide to approve them based on
         their own idea of the criteria
       - every day he remembers, Jeremy looks at the list around 11pm and
         approves or denies whatever is left based on his own idea of the
         criteria
     - most mornings Jaka integrates the ones that have been approved
       - or every few days Jeremy does the major ones he has time for
       - whichever case, the bug is still not "fixed", instead the subject
         gets "[integrated]" prepended
     - when someone mentions to Jeremy that there are integrations waiting
       to go to stable or he integrates one he knows was a security fix or
       otherwise really major, he regenerates the tarball
       - sometimes Arwed does this
     - Jaka or Jeremy goes and marks them all fixed after they hit the
       tarball

   I'm not really coming down on the process we're using because it is
   mostly working for us.  However it is too randomized and needs policy
   behind it so things aren't missed.  Also we need to be using bugzilla's
   states more intelligently so we're not hacking the bug subjects to store
   state.

   I would like to see something like:

   - file bug against highest branch it applies to
   - all bugs are always assigned to sm-grimoire-bugs; reassignments don't
     happen (any arguments against this given our current size are going to
     have to be damned compelling)
   - fix bug in test, mark it fixed
   - if it was filed against test, mark it closed unless it really needs
     verification, in which case ask for verification and still close it
     ASAP
   - if it was filed against stable(-rc), possibly request integration
     - once a day some group looks at integration requests on an assigned
       schedule and approves requests based on documented policy (a wiki
       page)
     - once a day some group performs integrations on an assigned schedule,
       marking a new "integrated" flag
     - when integrations are done, a new bug is created for 'stable-0.9-5
       tarball request' or something, with dependees of each bug that will
       be fixed by this
     - when these bugs are filed you or me or a designee makes the tarball
       (I will get the script into git somewhere)
     - tarball bug is closed
   - all bugs against a high branch are closed once they hit their filed
     branch, via integration or otherwise, unless verification is really
     required

   That's a suggestion, feedback from people like Jaka is definitely
   requested.  The schedule is to make it so we except some given person is
   in there each day looking at what needs doing.  I'm doing it near-daily
   now, I just need help (and to really be the backup, not the primary).
   We create as many gatekeepers as we need to fill out such a schedule.
   The "fixed in lesser branch" flag goes away in favor of the "fixed"
   state and an "integrated" flag.  We'd need to update the bugzilla stored
   queries.  We'd start using "closed" again, which would mean we'd first
   force-close a whole lot of fixed but not closed bugs that are out there.
   The stable tarball request meta-bug is iffy to me but maybe it would
   help.  It might be enough to have the integrated flag so we can do a
   good query of if any non-closed integrations are out there requiring a
   tarball.  We could generate an email off this daily as well maybe.

Attachment: pgpj6hwg3rpsc.pgp
Description: PGP signature