sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: Jaka Kranjc <lynx AT mages.ath.cx>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] new grimoire lead todo
- Date: Wed, 28 Mar 2007 22:04:31 +0200
On Tuesday 27 of March 2007 23:40:13 Jeremy Blosser wrote:
> On Mar 27, Jaka Kranjc [lynx AT mages.ath.cx] wrote:
> > 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?
I was trying to say that when you search for bugs, the preselected default
searches only in the open ones. So the bunch of FIXED bugs would be hard to
notice for other, not grimoire-related people.
> > > - 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.
Stable is low on traffic, so it would be easy to check its git log if the
need
arose. You made tracking what the user has easy by adding the VERSION file.
Updates to it make searching through the log even easier.
> > 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.
I'm not suggesting we should rebuild it asap after each commit. A daily
search
(for integrated+) like with the rest should do.
--
We cannot command nature except by obeying her. --Sir Francis Bacon
Have a sourcerous day! www.sourcemage.org
Attachment:
pgpAHvl6QHgBj.pgp
Description: PGP signature
-
[SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/26/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jaka Kranjc, 03/27/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/27/2007
- Re: [SM-Discuss] new grimoire lead todo, Jaka Kranjc, 03/28/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/27/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Eric Sandall, 03/29/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/29/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Eric Sandall, 03/29/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/29/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Eric Sandall, 03/30/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/30/2007
- Re: [SM-Discuss] new grimoire lead todo, Eric Sandall, 03/30/2007
- Re: [SM-Discuss] new grimoire lead todo, Jeremy Blosser, 03/31/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/30/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Eric Sandall, 03/30/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/29/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Eric Sandall, 03/29/2007
- Re: [SM-Discuss] new grimoire lead todo, Eric Sandall, 03/29/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jeremy Blosser, 03/29/2007
-
Re: [SM-Discuss] new grimoire lead todo,
Jaka Kranjc, 03/27/2007
Archive powered by MHonArc 2.6.24.