| 1 |
I've tried to divide up the various things being discussed here. |
| 2 |
|
| 3 |
|
| 4 |
Regarding paludis: |
| 5 |
|
| 6 |
- The syntax change in question affects >=paludis-0.24 |
| 7 |
- The old syntax is still accepted |
| 8 |
- A warning message is printed to the console by paludis when |
| 9 |
the old (deprecated) syntax is detected |
| 10 |
- The warning message includes basic instructions on how to fix the |
| 11 |
deprecated syntax. |
| 12 |
- The user isn't affected by the change in any other way |
| 13 |
- The syntax can't be fixed automatically |
| 14 |
|
| 15 |
Is the above correct? |
| 16 |
|
| 17 |
|
| 18 |
|
| 19 |
Regarding the GLEP: |
| 20 |
|
| 21 |
There's reasonable doubt whether the news item can be classified as |
| 22 |
"critical news", and also whether it satisfies this sentence from the GLEP: |
| 23 |
|
| 24 |
News items must only be for important changes that may cause |
| 25 |
serious upgrade or compatibility problems. |
| 26 |
|
| 27 |
However, Ciaran (the primary GLEP author) tells us that the GLEP was |
| 28 |
written with the mindset to allow these kinds of news items, i.e. some |
| 29 |
of us are misinterpreting the text. |
| 30 |
|
| 31 |
Specifically, the news is useful/beneficial/interesting to all or almost |
| 32 |
all paludis users so it should be put in place regardless of importance: |
| 33 |
|
| 34 |
It's something that is of sufficient interest to those who will |
| 35 |
read the news item that a news item is warranted. |
| 36 |
|
| 37 |
I can understand that the system may have been dreamed up with this in |
| 38 |
mind, and this certainly isn't an unreasonable design, but I don't see |
| 39 |
the corresponding text in the GLEP. |
| 40 |
|
| 41 |
Mike already suggested that we set some news standards. I think we |
| 42 |
should go further: after discussion if we do decide this kind of article |
| 43 |
is valid news, then we should carefully reword some parts of the GLEP |
| 44 |
and maybe even rename it. Adding a few examples of valid and invalid |
| 45 |
items (plus explanations why) would be beneficial as well. |
| 46 |
|
| 47 |
|
| 48 |
|
| 49 |
Regarding elog: |
| 50 |
|
| 51 |
Some people have suggested that elog is a suitable way of providing the |
| 52 |
syntax change information here. The main argument against this is that |
| 53 |
the Portage implementation isn't good enough (or perhaps isn't good |
| 54 |
enough by default, or perhaps isn't good enough in the released versions). |
| 55 |
|
| 56 |
If we can agree that the concept of elog satisfies the requirements |
| 57 |
here, then we should be focusing on fixing that rather than arguing |
| 58 |
about a different news system which isn't even implemented in the latest |
| 59 |
released version of Portage, right? Portage's news implementation might |
| 60 |
even be worse than the elog implementation... |
| 61 |
|
| 62 |
|
| 63 |
|
| 64 |
Regarding the committed news item: |
| 65 |
|
| 66 |
I spoke to Alec on IRC. Even after doing so, I don't really understand |
| 67 |
why he committed this, but it sounds like he wanted to stir things up. |
| 68 |
He doesn't acknowledge that he had any particular power to make the |
| 69 |
decision in this situation. He is surprised that nobody approached him |
| 70 |
before complaining to the council (not that any complaints have been |
| 71 |
filed in any official sense to my knowledge). |
| 72 |
|
| 73 |
He was already aware that he violated the GLEP, which requires at least |
| 74 |
72 hours before the news item gets committed. |
| 75 |
|
| 76 |
I think someone should revert this commit until discussion has settled |
| 77 |
and the GLEP wording has been refined. |
| 78 |
|
| 79 |
|
| 80 |
|
| 81 |
Corrections appreciated. |
| 82 |
Daniel |
| 83 |
-- |
| 84 |
gentoo-dev@g.o mailing list |
Archives