1 |
Tobias Scherbaum <dertobi123@g.o> posted |
2 |
1244672807.6190.35.camel@××××××××××××××××.de, excerpted below, on Thu, 11 |
3 |
Jun 2009 00:26:47 +0200: |
4 |
|
5 |
>> * The Council votes for final approval, pending Portage implementation. |
6 |
> |
7 |
> Looks good so far. |
8 |
> |
9 |
>> * Portage implements it in ~arch. People start using it in ~arch. |
10 |
> |
11 |
> I'd propose: Portage implements it in ~arch. People can start using it |
12 |
> in overlays. |
13 |
|
14 |
The problem with that is that it's a NOOP. People can use whatever they |
15 |
want in overlays, already, a feature that's a good part of their |
16 |
dynamic. Thus, "can start using it in overlays" is entirely meaningless. |
17 |
|
18 |
Now one could add the single word "official" in there, as in "official |
19 |
overlays", defining that term much as layman does. (Actually, it appears |
20 |
the layman manpage uses the terms "fully supported" and "non-official", |
21 |
not specifically the term "official", altho the contrasting "non- |
22 |
official" does have the implication of making "fully supported" overlays |
23 |
synonymous with "official overlays".) |
24 |
|
25 |
>> * Portage goes stable. People are allowed to start using it in stable |
26 |
>> for things that aren't deps of anything super-critical. |
27 |
> |
28 |
> I'd propose: Portage goes stable. 4 Weeks thereafter people are allowed |
29 |
> to start using it for things that aren't deps of anything |
30 |
> super-critical. |
31 |
|
32 |
Question. Was the omission of a specific ~arch allowed step deliberate? |
33 |
You went from "allowed in overlays" to "allowed in stable", without a |
34 |
stop in ~arch. Either it was deliberate and an reason would have been |
35 |
useful, or it was simply overlooked. |
36 |
|
37 |
(FWIW, a policy that ~arch portage of an approved EAPI allows ~arch |
38 |
packages, stable portage allows stable packages, but with the cost of |
39 |
putting it in ~arch before stable portage has it stated explicitly -- |
40 |
that anyone choosing to do so should be prepared to revert to a previous |
41 |
EAPI should a security bump require it before portage stabilizes -- that |
42 |
sort of policy works for me. Problems we've had can thus be explained as |
43 |
not making that cost of following ~arch portage with ~arch packages |
44 |
explicit, I believe, so make it explicit and let the maintainers then |
45 |
choose based on that. Perhaps add the additional caveat that it may ONLY |
46 |
be done with the signoff of a backup maintainer and/or the supporting |
47 |
project as well, in the hopefully unusual case that the maintainer that |
48 |
did the conversion goes MIA when a security bug comes up to press the |
49 |
matter, so there's always someone else that understands the situation |
50 |
well enough to handle the revert to a stable EAPI as necessary. However |
51 |
that's not a strongly held position and doesn't mean I oppose the above, |
52 |
only that I'd like clarification thereof.) |
53 |
|
54 |
-- |
55 |
Duncan - List replies preferred. No HTML msgs. |
56 |
"Every nonfree program has a lord, a master -- |
57 |
and if you use the program, he is your master." Richard Stallman |