Public SourceMage Discussion List

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

First, I'm not trying to be overly confrontational here, so don't read any
of this that way.  I'm just trying to make sure we continue to make
progress and don't repeat past mistakes.  We have some decent progress on
the Grimoire front and I want to help you keep that going and I've also
committed to not let it slip back.


On Mar 29, Eric Sandall [eric AT sandall.us] wrote:
> 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. ;)

Ok, but you can expect me to be brutal about branching/etc. getting done on
the dates set ahead of time.  Fair warning.

In git 1.4.x, making 0.9 will be:
- git checkout -b stable-rc-0.9 master
- $EDITOR VERSION; s/0.9-test/0.9-rc
- git commit VERSION
- git checkout master
- $EDITOR VERSION; s/0.9-test/0.10-test
- git commit VERSION
- git push origin master
- git push ssh://scm.sourcemage.org/smgl/grimoire stable-rc-0.9:stable-rc-0.9

I'm not sure how the branch commands change for git 1.5, I haven't dug into
that yet.

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

There are people on the current lists who don't participate right now (they
don't approve integration requests and they don't do integrations).  This
is bad security and makes auditing hard.  There's at least one person in
the stable commit ACL who has formally said he doesn't have much time for
SMGL right now.  So as the admin guy I'll ask you to take another look at
that if you don't mind.

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

Are we going to implement any kind of scheduled job to make sure if things
don't get done in that week they get reassigned back?  The problem we have
is that people have good intentions that fall through and things get lost.
Often.

>   * Once a bug is fixed in test, mark it as FIXED and request integration 
> via 
> flags to affected grimoires.

Please define "affected grimoires"... you aren't suggesting requesting
integration to stable for every bug that exists in stable, are you?

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

Please establish a time period we wait for verification before we just mark
it CLOSED so it doesn't sit open forever.  Also a process to make sure that
timeline is enforced.

>     - Once integrated, post which commit id the integration is and which 
> VERSION of the tarball it will be in.

The version data would have to be an assumption of "current version++";
what I've been doing so far is posting the version after the tarball is
actually done.  It probably works either way.

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

Sorry, but I want a schedule here with names and assigned days.  Not just
"everyone expects at least one person will look daily".  This doesn't mean
people can't miss one of their days, but it does mean each person knows
which days they are supposed to cover and if someone misses it's less
likely the next is missed as well (or the next, or the next).  If people
want to volunteer to have access or authority they should also volunteer to
be on the schedule.  Your PL is tired of doing this every day himself
because it goes weeks between otherwise.

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

I wouldn't expect anything to go to stable that wasn't critical, so I don't
think a "normal" weekly tarball for stable exists...

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

By definition the VERSION is the version of the tarball.  It's only updated
when the tarball is being regenerated, that's the point of it.

> The following flags would be removed: "Fixed in lesser branch" and 
> "Quickfix".

Why quickfix?  The bug party last week couldn't have done the work it did
without that flag.

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

That's what I was suggesting... we're using the subject now, we shouldn't
be, it should be a real flag or possibly even a RESOLVED state (between
VERIFIED and CLOSED).

> 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

"Like to see" is good but we won't do it if there's not a defined policy
around it and probably a volunteer schedule.

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

Attachment: pgplmRjIIfULt.pgp
Description: PGP signature