Skip to Content.
Sympa Menu

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

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] new grimoire lead todo
  • Date: Thu, 29 Mar 2007 12:57:26 -0700

On Thursday 29 March 2007 10:07:58 Jeremy Blosser wrote:
> 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.

I'd hope that feedback is always assumed to be meant as helpful. ;)

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

In 1.5.x all the steps above are the same, but after you push you want to do
a
`git pull` so your clone knows about the new origin/stable-rc-0.9. :)

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

I'm used to Ibiblio, where adding/removing takes time, so I tend to leave
people there hoping they come back. :) If they are no longer around or no
longer participate in it, then they should be removed.

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

We could setup a cron job with bug_cli to check for Codex bugs not assigned
to
sm-grimoire-bugs and reassign them back if no activity has occurred in a
week.

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

Every bug that affects how a package works (so not description changes ;)),
yes. The gatekeepers may always deny the request.

See the discussion on what to consider critical, since that will actually
define what will really be requested, not what I think should be. ;)

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

I would say a week is definately long enough.

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

The commit id is the more important bit of information, since we can always
look in git to see which VERSION that id was submitted in. Either way works,
I just assumed having both posted at the same time might help avoid it being
forgotten later.

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

My issue with this is finding volunteers to do it daily, and they might get
burned out. If we have enough volunteers (heh), it'd be one day a week at
most that you need to check and do integrations, but most likely it'll be
every other day for the two volunteers.

I'm willing to do integration requests every day except the weekends (usually
gone for wedding planning or out with friends all weekend). The integrations
I'd be willing to do Wednesday and Thursday (the other days I'm not home
until after 7PM at the earliest). Volunteers for the other days are welcome
to add themselves to http://wiki.sourcemage.org/Stable/Integration_Schedule.

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

That's fair enough, but what should we consider critical? I consider missing
dependencies critical (and SECURITY_PATCH, obviously ;)), but then I also
consider installed file locations very important. I like a clean, working
system and expect our users to want the same. The locations, however, most
likely can wait for the next stable run in two weeks.

Considered critical:
* Dependency changes
* SECURITY_PATCH
* Fixing broken configs (e.g. apache)

Any others?

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

Right, so we'd increment the field in VERSION to have a new tarball
generated. ;)

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

I missed that party, and I've never seen quickfix used before. If it's
useful,
then we'll leave it.

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

Then we'll create an integrated flag so it'll be easier to filter and search
(hopefully).

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

I see these as lower priority, so I'll wait until we have volunteers for the
stable(-rc) approvals and integrations before finding more for this.

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




Archive powered by MHonArc 2.6.24.

Top of Page