Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] new grimoire lead todo

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] new grimoire lead todo
  • Date: Mon, 26 Mar 2007 17:16:43 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page