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: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] new grimoire lead todo
  • Date: Tue, 27 Mar 2007 16:40:13 -0500

On Mar 27, Jaka Kranjc [lynx AT mages.ath.cx] wrote:
> On Tuesday 27 of March 2007 00:16:43 Jeremy Blosser wrote:
> > 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
> We also need to be able to find bugs that didn't have any or were denied
> the
> integration requests (but were fixed of course). These now get closed when
> the fixes naturally propagate to the target grimoire. With a clean start,
> searching for FIXED would do. The thing I don't like about this is that
> FIXED
> is by default (rightfully so in the current schema) not included in
> bugzilla
> search queries. But I doubt we can change that without affecting the other
> products. Is it important at all? We got only a few new duplicates in the
> last few months, I don't know how such a change would affect that.

I'm not sure I follow you 100%. But I'm fine trying to force bugzilla to a
clean state WRT old bugs. That is, marking CLOSED anything that is
currently marked FIXED so we can start using those states more
intelligently, etc. As for affecting other components, we should in
general try to have the states mean the same thing, but regardless we can
limit searches on component, yes?

> > - 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.
> Sounds good and I agree that the metabug isn't needed.

One major benefit of the metabug is that it makes it easy to track which
integrations hit which tarball. Without that we may come to some bug
that's marked fixed and integrated and not know if it's in the tarball
without going out and looking.

> People will be checking bugs daily anyway. If anything gets integrated
> they should notify the people that can redo the tarballs. Additional
> annoyances via email can help too. :)

There's a practical limit to how often we can update these; right now it
takes 30-60 minutes just to run the script because of ibiblio's CPU load.
I'm working on ways to improve that, but I don't like to do it more than
once in the morning and once at night. Obviously we don't like to be doing
it that often regardless but sometimes security bugs come in a rush and
that's what we're looking at. So when it's done twice a day this means we
need a way to track which things hit which tarballs, or things maybe get
lost.

Attachment: pgplwbm_IhPWk.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page