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 |