| 1 |
On Sat, 28 Dec 2013 18:26:47 +0100 |
| 2 |
Patrick Lauer <patrick@g.o> wrote: |
| 3 |
|
| 4 |
> > The discussion is based on some questions that are hard to agree on: |
| 5 |
> > |
| 6 |
> > 1. How much of a problem is an unused USE flag in metadata.xml? |
| 7 |
> |
| 8 |
> Cosmetic issue. No functional impact. |
| 9 |
|
| 10 |
This is a description of an unused USE flag instead of an answer; |
| 11 |
asked differently, how much does its presence impact quality? |
| 12 |
|
| 13 |
> > 2. Should such repoman warnings be fixed? By whom? When? How? |
| 14 |
> |
| 15 |
> Yes. You see it, you fix it. |
| 16 |
|
| 17 |
Once I get around to them, but there are more important things to do. |
| 18 |
|
| 19 |
> Not fixing cosmetic issues (cf. compiler warnings) leads to more and |
| 20 |
> more noise until real issues are just drowned in the noise; the only |
| 21 |
> way to achieve excellence (in terms of quality) is discipline in |
| 22 |
> adhering to rules and standards obsessively. |
| 23 |
|
| 24 |
Does that noise distract us from fixing what really needs fixing? |
| 25 |
|
| 26 |
It seems to me that for example migrating ebuilds to newer eclasses is |
| 27 |
much more important than to fix something that's just cosmetic. But it |
| 28 |
appears that fixing cosmetic issues is easier and more fun to do... |
| 29 |
|
| 30 |
"Kill it with fire!" |
| 31 |
|
| 32 |
> If there are (too) many false positives we should add proper |
| 33 |
> annotations to silence repoman ... |
| 34 |
|
| 35 |
Are there other false positives than the multi-line readme eclass ones? |
| 36 |
|
| 37 |
> > 3. Can USE flags actually be removed from stable ebuilds? |
| 38 |
> |
| 39 |
> Usually removing stable ebuilds makes useflags "disappear", rarely |
| 40 |
> does masking stuff (e.g. old cups) lead to the disappearance of |
| 41 |
> useflags as they would now be broken |
| 42 |
|
| 43 |
The question is about the removal of an USE flag, not the removal of an |
| 44 |
ebuild; it rather addresses changing the ebuild to remove the USE flag, |
| 45 |
to address the context of this thread. |
| 46 |
|
| 47 |
> > 4. ... |
| 48 |
> |
| 49 |
> Do we need to discuss this? |
| 50 |
> |
| 51 |
> No. It's an amazing waste of time, almost as if we had no real |
| 52 |
> problems to focus on. |
| 53 |
|
| 54 |
Maybe, maybe not; some parts of it can yield bike-shedding, but other |
| 55 |
parts of it can definitely be useful to talk about. Eventually we will |
| 56 |
need to discuss as a QA team to focus on getting the harder stuff done; |
| 57 |
because well, just shooting at the low hanging fruit and taking the |
| 58 |
easy way out and only coming together after "something happened" isn't |
| 59 |
the way that works well. This thread is a good demonstration of that... |
| 60 |
|
| 61 |
> > Because this can yield quite some bike-shedding; the alternative |
| 62 |
> > "out of the box thinking" package.use.mask solution satisfies both |
| 63 |
> > parties, which renders that discussion unnecessary. Nobody has |
| 64 |
> > objected this. |
| 65 |
> |
| 66 |
> That is a "fix" specific to this package alone, in the general case it |
| 67 |
> is not valid. |
| 68 |
|
| 69 |
You either want to keep the USE flag description or you don't. |
| 70 |
|
| 71 |
-- |
| 72 |
With kind regards, |
| 73 |
|
| 74 |
Tom Wijsman (TomWij) |
| 75 |
Gentoo Developer |
| 76 |
|
| 77 |
E-mail address : TomWij@g.o |
| 78 |
GPG Public Key : 6D34E57D |
| 79 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives