1 |
On 20/08/2013 22:25, Tom Wijsman wrote: |
2 |
> On Tue, 20 Aug 2013 22:00:52 +0200 |
3 |
> Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
4 |
> |
5 |
>> As a long time user and citizen of -user I can tell you what the |
6 |
>> general feeling of arch vs ~arch there is: |
7 |
> |
8 |
> Thanks for jumping into the discussion. |
9 |
> |
10 |
>> arch has plenty old stuff in it |
11 |
> |
12 |
> Yes, it keeps me from using it; I would have to unmask too much... |
13 |
> |
14 |
>> ~arch is plenty good enough for everything except very mission |
15 |
>> critical stuff |
16 |
>> |
17 |
>> ~arch does not break every other day, and breakage is actually |
18 |
>> surprisingly rare. And, it's usually confined to |
19 |
>> openrc/udev/systemd/baselayout and other critical packages where one |
20 |
>> just knows upfront anyway that danger may lurk ahead. |
21 |
>> |
22 |
>> Some folks like me sync daily and accept that I deal with occasional |
23 |
>> breakage maybe once a month. Usually I just mask an offending package |
24 |
>> and move on. Others wait a few days and if no reported bugs, then |
25 |
>> emerge it. |
26 |
> |
27 |
> This really sounds like what would be the description of stable; I |
28 |
> mean, for mission critical stuff someone would plan out a migration and |
29 |
> "test" the upgrade prior to applying it to the server. For the rest, |
30 |
> except for maybe that critical packages shouldn't break; an issue once |
31 |
> a month is something that slips through, eg. see the stable bugs... |
32 |
> |
33 |
>> I get the sense that hard masked and -9999 is the new testing, |
34 |
> |
35 |
> Actually, hard masked is usually something that is really broken; while |
36 |
> there are some things masked for some other reasons, you can't really |
37 |
> regard it as testing. But yeah, as for -9999, it could be considered |
38 |
> testing; although it is often broken, because of broken patches, ... |
39 |
> |
40 |
>> I also get the sense that arch progresses too slowly for many people. |
41 |
> |
42 |
> +1 that's one of the points that came up on IRC; 30 days and more |
43 |
> being too long, because not everyone follows up with that time |
44 |
> schedule (we are people, not cronjobs), it even gets a bit longer... |
45 |
> |
46 |
>> How long did we wait for MySQL-5.5 to reach arch? Folk wanted that |
47 |
>> one in stable reasonably early and mixing arch/~arch is very very bad |
48 |
>> in real life. Hence the recommendation to switch to ~arch, and it |
49 |
>> usually works out just fine. |
50 |
> |
51 |
> Yes, but we don't want to end up having everyone having mixed trees or |
52 |
> be on ~arch; if we do, stabilization is going to become a wasted effort. |
53 |
|
54 |
Perhaps the area to be clarified is "what is the intended risk profile |
55 |
for arch and ~arch?" |
56 |
|
57 |
stable and unstable mean very different things to different people, they |
58 |
are quite overloaded terms, so a proper definition is in order. Then |
59 |
users can also accurately just what they are going to get in arch as |
60 |
well as the intended level of stability. |
61 |
|
62 |
We already have a good beginning with the usual description of ~arch as |
63 |
"works pretty much OK most of the time but new ebuilds go in here first |
64 |
so expect some breakage sometimes". Let's express that in terms of risk. |
65 |
|
66 |
Something else we should also keep in mind - binary distros often |
67 |
recommend that autoupdates be enabled. If people do this it changes the |
68 |
game play as they really don't know what is coming down the wire at all. |
69 |
Gentoo is different - nothing changes until you sync and emerge world |
70 |
and this really does require that the sysadmin eyeballs the output. This |
71 |
removes a lot of the risk from the devs (you can't really know what my |
72 |
USE will do on my end so I must assume some responsibility for my |
73 |
choices). I do believe this gives the devs a lot of wiggle room to get |
74 |
things into arch quicker without having to test and verify every little |
75 |
thing. |
76 |
|
77 |
-- |
78 |
Alan McKinnon |
79 |
alan.mckinnon@×××××.com |