1 |
On 2014.06.30 05:01, William Hubbs wrote: |
2 |
> All, |
3 |
> |
4 |
> I am starting a new thread so we don't refer to a specific package, |
5 |
> but I |
6 |
> am quoting Rich and hasufell from the previous masking thread. |
7 |
> |
8 |
> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: |
9 |
> > On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@g.o> |
10 |
> wrote: |
11 |
> > > This is still too vague for me. If it's expected to be short- |
12 |
> term, |
13 |
> then |
14 |
> > > it can as well just land in ~arch. |
15 |
> > |
16 |
> > A package that hasn't been tested AT ALL doesn't belong in ~arch. |
17 |
> > Suppose the maintainer is unable to test some aspect of the |
18 |
> package, |
19 |
> > or any aspect of the package? Do we want it to break completely |
20 |
> for |
21 |
> > ~arch? In that event, nobody will run ~arch for that package, and |
22 |
> > then it still isn't getting tested. |
23 |
> |
24 |
> I'm not saying that we should just randomly throw something into |
25 |
> ~arch |
26 |
> without testing it, but ~arch users are running ~arch with the |
27 |
> understanding that their systems will break from time to time and |
28 |
> they |
29 |
> are expected to be able to deal with it when/if it happens. ~arch is |
30 |
> not a second stable branch. |
31 |
> |
32 |
> > I agree that masking for testing is like having a 3rd branch, but |
33 |
> I'm |
34 |
> > not convinced that this is a bad thing. ~arch should be for |
35 |
> packages |
36 |
> > that have received rudimentary testing and which are ready for |
37 |
> testing |
38 |
> > by a larger population. Masking should be used for packages that |
39 |
> > haven't received rudimentary testing - they might not have been |
40 |
> tested |
41 |
> > at all. |
42 |
> |
43 |
> The concern with this argument is the definition of rudimentary |
44 |
> testing |
45 |
> is subjective, especially when a package supports many possible |
46 |
> configurations. |
47 |
> |
48 |
> I think some packages need wide testing before they go stable, and |
49 |
> that |
50 |
> is where ~arch can help out. |
51 |
> |
52 |
> In particular, I would argue that for system-critical packages, users |
53 |
> should be very careful about running ~arch unless they know what the |
54 |
> fallout can be. |
55 |
> |
56 |
> *snip* |
57 |
> |
58 |
> > I guess the question is, what exactly are we trying to fix? Even |
59 |
> if |
60 |
> > occasionally a maintainer drops the ball and leaves something |
61 |
> masked |
62 |
> > for a year, how is that different from a maintainer dropping the |
63 |
> ball |
64 |
> > and not adding a new release to the main tree for a year? Would we |
65 |
> be |
66 |
> > better off if Docker 1 wasn't in the tree at all? If it happened |
67 |
> to |
68 |
> > have a known issue would ~arch users be better off if some other |
69 |
> dev |
70 |
> > came along and helpfully added it to the tree unmasked no realizing |
71 |
> > that somebody else was already working on it? |
72 |
> |
73 |
> Take a look at profiles/package.mask. You will see many packages in |
74 |
> there with the description, "masked for testing" on their masks, with |
75 |
> no |
76 |
> bug references, that have been there for multiple years. My view is |
77 |
> we |
78 |
> should either get those masks resolved or boot the affected |
79 |
> packages/versions out of the tree. If they haven't received |
80 |
> rudimentary |
81 |
> testing by now, it is pretty obvious that no one cares about them. |
82 |
> |
83 |
> William |
84 |
> |
85 |
> |
86 |
|
87 |
Once upon a time, not so long ago I don't remember it, there were very |
88 |
few overlays. At that time, there was always a lot of packages in the |
89 |
tree "masked for testing". At that time, well before layman, overlays |
90 |
were inconvenient. |
91 |
|
92 |
As overlays have become more widespread and used as a way to lower the |
93 |
barrier to contributing directly to Gentoo, there are fewer packages |
94 |
"masked for testing". |
95 |
|
96 |
I like the old way, it avoids installing yet another overlay but |
97 |
clearly others feel differently or there would not be so many overlays |
98 |
to choose from. The reality is, both ways work for me. |
99 |
Pragmatically, its not practical to merge all of the overlays into the |
100 |
tree, then ban overlays. That would be a return to the old way. |
101 |
|
102 |
This just represents a change of workflow with time. |
103 |
The question then is do we need to formalise the changed workflow, or |
104 |
can both be allowed to continue side by side? |
105 |
|
106 |
-- |
107 |
Regards, |
108 |
|
109 |
Roy Bamford |
110 |
(Neddyseagoon) a member of |
111 |
elections |
112 |
gentoo-ops |
113 |
forum-mods |
114 |
trustees |