1 |
On Mon, Jun 30, 2014 at 01:07:17PM -0400, Rich Freeman wrote: |
2 |
> On Mon, Jun 30, 2014 at 12:32 PM, William Hubbs <williamh@g.o> wrote: |
3 |
> > On Mon, Jun 30, 2014 at 06:13:45PM +0200, Jeroen Roovers wrote: |
4 |
> >> On Mon, 30 Jun 2014 11:40:19 -0400 |
5 |
> >> Ian Stakenvicius <axs@g.o> wrote: |
6 |
> >> |
7 |
> >> > But... if I unmask it, -everyone- using ~arch will install it and |
8 |
> >> > it'll break all the systems that it doesn't work on, which -could- be |
9 |
> >> > quite a lot at this point. :D |
10 |
> >> |
11 |
> >> Which is great, because then you have an actual test result, whereas |
12 |
> >> before you had nothing but a stupid mask. |
13 |
> >> |
14 |
> >> And lots of people are suddenly very much interested in getting any and |
15 |
> >> all bugs fixed in the new ebuild, whereas before you only had the stupid |
16 |
> >> mask. |
17 |
> >> |
18 |
> >> |
19 |
> >> jer |
20 |
> > |
21 |
> > I am going to agree with Jer on this. |
22 |
> > |
23 |
> > As said before, ~arch users know that their systems will break |
24 |
> > sometimes, so if the package works for you, unleash it on ~arch. If |
25 |
> > someone using a configuration you don't have finds that it breaks, I'm |
26 |
> > sure it would be reported. Then you could determine whether the bug is |
27 |
> > severe enough to warrant a mask. |
28 |
> > |
29 |
> |
30 |
> We're not talking about packages that work for the maintainer. We're |
31 |
> talking about packages where the maintainer doesn't know if they work. |
32 |
> Or at least, those are the packages I'm talking about. |
33 |
|
34 |
The debate is sort of two-pronged, and I split out the package.mask |
35 |
question to another thread. There are 6 year old p.mask entries that |
36 |
just say "masked for testing", and those are listed in the new thread I |
37 |
started. |
38 |
|
39 |
> Everybody seems to think that this is a debate between having newer |
40 |
> ebuilds in the tree masked vs unmasked. This is a debate between |
41 |
> having newer ebuilds in the tree masked vs not having them in the tree |
42 |
> at all. Nobody is going to put an ebuild in the tree unmasked if they |
43 |
> don't know that it is going to work, and per earlier comments anybody |
44 |
> who does that probably shouldn't have commit privs. |
45 |
|
46 |
What was said earlier is if a maintainer just runs compile tests then |
47 |
commits the new version that person probably shouldn't have commit |
48 |
privs. |
49 |
|
50 |
> Rules won't make maintainers do more work. They can only prevent |
51 |
> maintainers from doing certain kinds of work. That is why I tend to |
52 |
> oppose more rules unless they actually are preventing some kind of |
53 |
> harm, or having a likely benefit. I just don't see the benefit here. |
54 |
|
55 |
The benefit of getting packages into ~arch vs "masked for testing" is |
56 |
that maintainers can get users to test their packages in configurations |
57 |
that the maintainers are not able to test with. |
58 |
|
59 |
Also, it opens up the package to more testing because it will be |
60 |
exposed to more users with different configurations. |
61 |
|
62 |
> I'm fine with a policy that says that packages should only be masked |
63 |
> for testing if they're actually being tested and there is some kind of |
64 |
> roadmap for getting rid of the mask. |
65 |
|
66 |
The problem I see with "masked for testing" is probably similar to what |
67 |
you are talking about. If something is "masked for testing", there |
68 |
should be a push from somewhere to not keep it "masked for testing". |
69 |
|
70 |
> I don't like seeing 3 year old masks in the profile either. Let's try |
71 |
> to curtail that kind of thing. However, I think we're in danger of |
72 |
> throwing the baby out with the bath water here. I cringe anytime I |
73 |
> hear somebody say that ~arch has fewer issues than stable, but the |
74 |
> solution to that isn't to go looking for opportunities to break ~arch. |
75 |
|
76 |
I don't like seeing old masks in the profiles either. p.mask |
77 |
should never be permanent, but there are other issues associated with |
78 |
making that happen that should be in other threads probably. |
79 |
|
80 |
All I'm saying about ~arch is that it is known to break and will |
81 |
continue to break, so lets not try to pretend otherwise. Someone in this |
82 |
thread said ~arch is semi-stable; it is not. If you use ~arch you are on |
83 |
your own and expected to be able to handle any breakage that comes up. |
84 |
|
85 |
William |