-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/03/13 11:19 AM, Peter Stuge wrote:
> Markos Chandras wrote:
>>> A per-ebuild bug metric would be cool. A kind of health
>>> indicator for individual ebuilds, alerting users when some of
>>> our installed ebuilds go yellow, so that we have perhaps on the
>>> order of six months before the package goes red, at which point
>>> it would be fine to mask at will. Does that make sense?
>>> (Obviously how many months yellow is depends on what else
>>> happens in the tree. It's a ballpark figure.)
>> 
>> No we don't have the human resources to do that.
> 
> Ah, no, it must be automated. Of course the metric would be 
> accordingly "stupid" but it would still be way more informative 
> than no metric at all.
> 
> I think a GSOC project is a good fit, unless of course a developer 
> likes to run with the idea. In any case, yes, people are needed to 
> do development, but working out an idea is a good start.
> 
> 
> //Peter
> 

The idea may have some merit in general, but I think it will be rather
difficult to implement anything for this in practice, simply because
there is no metrics that I can think of that would be of use for this
that isn't going to require a lot of per-bug flagging of some sort by
humans.

The number of open bugs doesn't really matter, it's what those bugs
are that matters -- security bugs, sure, are of a higher priority and
can be fairly easily detected in bugzilla.  Possibly, bugs that block
a STABLEREQ bug would work, but I think we don't mark stablereq on
these bugs until the blockers are resolved and so that isn't going to
be easy to find either outside of matching 'stabilize' in bug
summaries.  We generally discourage the use/filing of 'version-bump'
bugs, so that doesn't work so much -- euscan helps here, of course,
since it already works well to determine out-of-date packages, but for
packages with a mostly-dead but still existing upstream, not a whole
lot can be reported.

Of course, I look forward to being proven wrong, but at this point I
just can't picture what one would go by to trigger the report of a
yellow-package status before it goes red (where red = p.mask).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlFPUv4ACgkQ2ugaI38ACPC+6gEAqbe9woyvgLMUsd4SbqDszmJI
xorLFSMAJFtxK4pyXAQA/RIE1ckYa+46/Fq8huo64oTZz7K2xUf0aKEsCG+5HpHR
=Dw8R
-----END PGP SIGNATURE-----

Reply via email to