1 |
On 2017.12.21 00:35, William Hubbs wrote: |
2 |
> On Wed, Dec 20, 2017 at 07:12:45PM -0500, Michael Orlitzky wrote: |
3 |
> > On 12/20/2017 06:58 PM, William Hubbs wrote: |
4 |
> > > |
5 |
> > > There already is an overlay for dying packages, it is called |
6 |
> graveyard, |
7 |
> > > but no one is putting things there. |
8 |
> > > |
9 |
> > > This email conflates old dying packages with new versions, which |
10 |
> are a |
11 |
> > > completely separate issue. |
12 |
> > > |
13 |
> > |
14 |
> > Lack of new versions *is* dying. But I can make a package not-dying |
15 |
> in a |
16 |
> > few seconds by merging a PR, so long as you don't expect me to do |
17 |
> the |
18 |
> > (relatively high) level of QA required for ~arch. |
19 |
> > |
20 |
> > |
21 |
> > > If a new version of a package is known to cause wide scale |
22 |
> breakage, it |
23 |
> > > goes in package.mask until the breakage is resolved. Otherwise, |
24 |
> putting |
25 |
> > > it in ~ is fine. I don't see the need for another level of |
26 |
> keywords. |
27 |
> > |
28 |
> > The quality of ~arch is its own worst enemy; these days, stable |
29 |
> packages |
30 |
> > are just old ~arch packages. Users and developers expect ~arch to |
31 |
> work, |
32 |
> > and we have no real policy or documentation stating that it won't. |
33 |
> Many |
34 |
> > people will tell you that ~arch works better than stable, because it |
35 |
> > gets fixed faster. |
36 |
> |
37 |
> ~arch *will* have breakages from time to time, sometimes major |
38 |
> breakages, until they are masked or fixed. We are not supposed to |
39 |
> leave |
40 |
> major breakages there, but ~arch is definitely not for the faint of |
41 |
> heart. If you are using ~arch, you are expected to be a power user at |
42 |
> leasst and be able to recover if your system breaks. Production |
43 |
> servers |
44 |
> should not be running ~arch at all. That's the whole reason ~arch |
45 |
> exists. |
46 |
> |
47 |
> Yes, ~arch gets fixed faster than stable, but that is to be expected. |
48 |
> However, it is definitely not a good reason to put your production |
49 |
> system on |
50 |
> full ~arch. |
51 |
> |
52 |
> So, I guess this means that the quality of the ~arch tree is supposed |
53 |
> to |
54 |
> be somewhat lower than the quality of the stable tree. |
55 |
> |
56 |
> William |
57 |
> |
58 |
> |
59 |
|
60 |
William, |
61 |
|
62 |
I've been running ~arch everywhere since May 2002 and had exactly |
63 |
two major issues. They were :- |
64 |
Xorg going modular ... which I was aware of before it happened and |
65 |
expat which came as a surprise while I was dealing with modular |
66 |
Xorg. |
67 |
|
68 |
There have been some minor inconviences along the way too but |
69 |
problems running ~arch have reduced over the years. |
70 |
|
71 |
Nobody should run Gentoo at all in production unless they build |
72 |
and test packages offline before pushing the binaries to production. |
73 |
Then they can run whatever they want. |
74 |
Every Gentoo install is different and very few possible |
75 |
combinations are actually tested. |
76 |
|
77 |
By all means lower the bar for ~arch. Say, to "builds and works for |
78 |
me, needs more testing". The down side is that it will create more |
79 |
bug reports and more work, so it may only exchange one problem |
80 |
for another. |
81 |
|
82 |
-- |
83 |
Regards, |
84 |
|
85 |
Roy Bamford |
86 |
(Neddyseagoon) a member of |
87 |
elections |
88 |
gentoo-ops |
89 |
forum-mods |