| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 24/03/13 11:19 AM, Peter Stuge wrote: |
| 5 |
> Markos Chandras wrote: |
| 6 |
>>> A per-ebuild bug metric would be cool. A kind of health |
| 7 |
>>> indicator for individual ebuilds, alerting users when some of |
| 8 |
>>> our installed ebuilds go yellow, so that we have perhaps on the |
| 9 |
>>> order of six months before the package goes red, at which point |
| 10 |
>>> it would be fine to mask at will. Does that make sense? |
| 11 |
>>> (Obviously how many months yellow is depends on what else |
| 12 |
>>> happens in the tree. It's a ballpark figure.) |
| 13 |
>> |
| 14 |
>> No we don't have the human resources to do that. |
| 15 |
> |
| 16 |
> Ah, no, it must be automated. Of course the metric would be |
| 17 |
> accordingly "stupid" but it would still be way more informative |
| 18 |
> than no metric at all. |
| 19 |
> |
| 20 |
> I think a GSOC project is a good fit, unless of course a developer |
| 21 |
> likes to run with the idea. In any case, yes, people are needed to |
| 22 |
> do development, but working out an idea is a good start. |
| 23 |
> |
| 24 |
> |
| 25 |
> //Peter |
| 26 |
> |
| 27 |
|
| 28 |
The idea may have some merit in general, but I think it will be rather |
| 29 |
difficult to implement anything for this in practice, simply because |
| 30 |
there is no metrics that I can think of that would be of use for this |
| 31 |
that isn't going to require a lot of per-bug flagging of some sort by |
| 32 |
humans. |
| 33 |
|
| 34 |
The number of open bugs doesn't really matter, it's what those bugs |
| 35 |
are that matters -- security bugs, sure, are of a higher priority and |
| 36 |
can be fairly easily detected in bugzilla. Possibly, bugs that block |
| 37 |
a STABLEREQ bug would work, but I think we don't mark stablereq on |
| 38 |
these bugs until the blockers are resolved and so that isn't going to |
| 39 |
be easy to find either outside of matching 'stabilize' in bug |
| 40 |
summaries. We generally discourage the use/filing of 'version-bump' |
| 41 |
bugs, so that doesn't work so much -- euscan helps here, of course, |
| 42 |
since it already works well to determine out-of-date packages, but for |
| 43 |
packages with a mostly-dead but still existing upstream, not a whole |
| 44 |
lot can be reported. |
| 45 |
|
| 46 |
Of course, I look forward to being proven wrong, but at this point I |
| 47 |
just can't picture what one would go by to trigger the report of a |
| 48 |
yellow-package status before it goes red (where red = p.mask). |
| 49 |
|
| 50 |
|
| 51 |
-----BEGIN PGP SIGNATURE----- |
| 52 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 53 |
|
| 54 |
iF4EAREIAAYFAlFPUv4ACgkQ2ugaI38ACPC+6gEAqbe9woyvgLMUsd4SbqDszmJI |
| 55 |
xorLFSMAJFtxK4pyXAQA/RIE1ckYa+46/Fq8huo64oTZz7K2xUf0aKEsCG+5HpHR |
| 56 |
=Dw8R |
| 57 |
-----END PGP SIGNATURE----- |
Archives