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