Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] stable grimoire 0.4 released on thursday -- postrelease notes.

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jaka Kranjc <lynx AT mages.ath.cx>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] stable grimoire 0.4 released on thursday -- postrelease notes.
  • Date: Mon, 10 Jul 2006 19:25:15 +0200

On Sunday 09 July 2006 02:46, seth AT swoolley.homeip.net wrote:
> I hope to
> fix that by running prometheus on the new test grimoire now, then
> stable-rc after that. We could potentially have another stable release
> in as little as a month to six weeks. I'm trying to speed up release
> cycles to have less bitrot between releases.
Also, it would be good to fix some prometheus bugs first, before the new
tests. Things like conflict handling (#11116) and missing grimoires (#11107);
anything that would decrease the amount of false positives (true negatives?).

I also got an idea about handling duplicates. I don't remember much of the
earlier discussions, only suggestions about an irc channel for people taking
care of it and something with bugzilla. I don't see any bugs for it open, so
here is my suggestion how to fix it on the prometheus side of things.

Each bug report has a snippet of the build log. Duplicate bug reports contain
all sorts of info, but that build log snippet is likely to be the same or at
least very similar (version and arch checks during configure, *FLAGS are
things that come to mind regarding diversity).
So I suggest that prometheus computes a md5 from the last 5 lines of that
snippet and submits it with the bugreport (PR_ID:$mdsum or something). Then
it can search bugzilla for it easily before submitting next reports,
reporting hits in the original bugs not new ones (if at all). To make the
chances of finding a dupe higher, it could strip out known *FLAGS and arch
info (like x86_64-unknown-linux-gnu) from those 5 lines before computing the
sum (only for this computation of course). I think this is pretty safe, it is
unlikely that 5 stripped lines would match multiple times. If that was found
to be the case, we could always increase the number of lines it uses, 5 seems
like a rational start.

This wouldn't catch all dupes, but many, which is better than none. Something
with such functionality is greatly missed, especially if we'll have multiple
promethei running over the same spells again.

--
We cannot command nature except by obeying her. --Sir Francis Bacon

Attachment: pgpYjwX92VXQo.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page