1 |
Hi guys, |
2 |
|
3 |
As some of you have noticed, I made a change recently in ekeyword that |
4 |
causes ekeyword to alphabetize the keywords. I've realized I should |
5 |
have brought it up for discussion before making the change to the |
6 |
program. On that note, I apologize for unilaterally making that |
7 |
change without consulting the developer body for opinions. |
8 |
|
9 |
Here is the the fuzzy history of keywording in a nutshell. Please |
10 |
bear in mind that these bullet points happened over a period of years. |
11 |
|
12 |
- Daniel originally wanted them alphabetized. |
13 |
|
14 |
- A few people, myself included, pointed out that there's some |
15 |
valuable information available when keywords are always added to |
16 |
the end rather than being alphabetized. In particular, the |
17 |
concept of a "maintainer arch" is possible, in which the first |
18 |
arch in the list is supposed to indicate general stability of |
19 |
the ebuild, a leader for other arches to follow. |
20 |
|
21 |
- Some people disagreed with the "maintainer arch" concept. They |
22 |
felt that the arch teams do a better job of testing than some |
23 |
maintainers, and there's no point waiting for a maintainer to |
24 |
decide something is stable. |
25 |
|
26 |
- Some developers recently mentioned to me that alphabetizing |
27 |
would probably be fine. At this point I felt that the tree was |
28 |
diluted enough that there was no point resisting, so I went |
29 |
ahead and made the change silently. |
30 |
|
31 |
- My action was questioned privately on IRC, and I realized |
32 |
I made the decision without proper discussion. So I'm writing |
33 |
this email. |
34 |
|
35 |
Honestly, the arguments aren't very strong in either direction. |
36 |
I think everybody understands this, but nonetheless people have their |
37 |
preferences. Here are some of the basic arguments: |
38 |
|
39 |
alpha |
40 |
----------------------------- |
41 |
- looks nicer (subjective) |
42 |
- easier to tell at a glance if a given keyword is in the list |
43 |
|
44 |
append |
45 |
----------------------------- |
46 |
- slightly less cvs/rsync traffic |
47 |
- allows "maintainer arch" to continue until another solution is |
48 |
produced, for those who still depend on that method |
49 |
- some developers are accustomed to the "append" method and don't want |
50 |
things to change, at least not without discussion |
51 |
|
52 |
I am willing to revert the ekeyword change if that is what devs would |
53 |
prefer, but I won't make the change without a discussion on -dev, |
54 |
which was my mistake last time. Your thoughts? |
55 |
|
56 |
If the thread isn't obviously unified one direction or the other, |
57 |
I guess we'll eventually put this up to a developer or manager vote |
58 |
(I'm not sure which is appropriate) |
59 |
|
60 |
Regards, |
61 |
Aron |
62 |
|
63 |
-- |
64 |
Aron Griffis |
65 |
Gentoo Linux Developer |