Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

On Monday 26 March 2007 15:16:43 Jeremy Blosser wrote:
> 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.

Not that I'm complaining, but I should probably do the git branch so I know 
how to do it and can put it in our documentation. ;) April 1st sounds like a 
fine day for me to do a new release. ;) I'll find a work horse to lead this 
next stable release and notify everyone.

David Brown (dmlb2000) has agreed to do our stable-0.9 release and will be 
posting a Stable-0.9 wiki soon. :)

> 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.

I've asked a few to be my assistants and will let you know which agree. ;) I 
would like the order to be: Me -> Assistants -> PL for deciding what to do 
with the grimoire.

George Sherwood (p3pilot) has agreed to be an Assistant. :)

> 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.

Once I've filled out my Assistants list, I'd like them to be on the 
stable(-rc) commit access as well as approve integrations. I don't see anyone 
on the stable(-rc) commit list or integration approval list I want removed.

> 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.

What I'd like to see here is similar to your example:
  * File bug against highest branch affected.
  * All bugs are assigned to sm-grimoire-bugs by default.
    - People may reassign only to them (adding sm-grimoire-bugs to CC) if 
they 
plan on fixing the bug within the week and want to let people know they are 
taking care of it so we do not duplicate work. (this could be taken care of 
in a comment, but then you need to read all the comments to figure out who's 
working on it at any given time. The Assigned field is useful for this).
  * Once a bug is fixed in test, mark it as FIXED and request integration via 
flags to affected grimoires.
    - Request verification if the bug is more complicated than "update to 
version X.Y.Z" or "missing dependency on foo" and mark CLOSED once it's 
VERIFIED, otherwise mark CLOSED now.
    - Once integrated, post which commit id the integration is and which 
VERSION of the tarball it will be in.
    - Mark all bugs CLOSED once they have reached the tarball. If the bug 
still exists it may be REOPENED.
  * Gatekeepers check for integration requests at least once a day.
  * Integrators check for approved integrations at least once a day.
  * Tarballs are only regenerated outside the normal 6 hour period (test) or 
once a week (stable-rc/stable, if any integrations have been made) for 
security updates or BLOCKER/CRITICAL bugs.
    - If we can get the tarball generation to be quick, then I'd say the 
stable/stable-rc tarballs should be regenerated whenever the VERSION file is 
updated.

The following flags would be removed: "Fixed in lesser branch" and "Quickfix".
The following fields would be removed: OS (we only support Linux at this 
time). Version would be renamed to "Grimoire" and only grimoire names will be 
listed for the Codex product (e.g. remove "1.15.x").

I do like the idea of a master bug for integration requests, but that might 
be 
too much overhead and "paperwork". I would like to do a trial run of this, at 
least, for one of our releases and continue it if we make it work.

I'm not sure I like the idea of addings flags to the summary 
(e.g. "[integrated]") as it'd be cleaner, IMO, to use a real flag. That feels 
to me as though we're flagging the bug, but are too lazy (or Bugzilla's flag 
interface is too annoying) to use a real flag.

I would also like to see weekly cleanups of bugzilla, mainly for the 
following:
  * Unapplied security updates (it might be worthwhile to have a flag for 
this)
  * Duplicate bugs
  * Bugs that have been fixed but not marked FIXED
  * FIXED but not CLOSED bugs
  * VERIFIED but not CLOSED bugs

All of this, of course, will be added to the Grimoire Guru Handbook once I 
finalize the policy (with feedback welcome, of course ;)).

-sandalle

-- 
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  http://counter.li.org/  #196285