1 |
All, |
2 |
|
3 |
I am starting a new thread so we don't refer to a specific package, but I |
4 |
am quoting Rich and hasufell from the previous masking thread. |
5 |
|
6 |
On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: |
7 |
> On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@g.o> wrote: |
8 |
> > This is still too vague for me. If it's expected to be short-term, then |
9 |
> > it can as well just land in ~arch. |
10 |
> |
11 |
> A package that hasn't been tested AT ALL doesn't belong in ~arch. |
12 |
> Suppose the maintainer is unable to test some aspect of the package, |
13 |
> or any aspect of the package? Do we want it to break completely for |
14 |
> ~arch? In that event, nobody will run ~arch for that package, and |
15 |
> then it still isn't getting tested. |
16 |
|
17 |
I'm not saying that we should just randomly throw something into ~arch |
18 |
without testing it, but ~arch users are running ~arch with the |
19 |
understanding that their systems will break from time to time and they |
20 |
are expected to be able to deal with it when/if it happens. ~arch is |
21 |
not a second stable branch. |
22 |
|
23 |
> I agree that masking for testing is like having a 3rd branch, but I'm |
24 |
> not convinced that this is a bad thing. ~arch should be for packages |
25 |
> that have received rudimentary testing and which are ready for testing |
26 |
> by a larger population. Masking should be used for packages that |
27 |
> haven't received rudimentary testing - they might not have been tested |
28 |
> at all. |
29 |
|
30 |
The concern with this argument is the definition of rudimentary testing |
31 |
is subjective, especially when a package supports many possible |
32 |
configurations. |
33 |
|
34 |
I think some packages need wide testing before they go stable, and that |
35 |
is where ~arch can help out. |
36 |
|
37 |
In particular, I would argue that for system-critical packages, users |
38 |
should be very careful about running ~arch unless they know what the |
39 |
fallout can be. |
40 |
|
41 |
*snip* |
42 |
|
43 |
> I guess the question is, what exactly are we trying to fix? Even if |
44 |
> occasionally a maintainer drops the ball and leaves something masked |
45 |
> for a year, how is that different from a maintainer dropping the ball |
46 |
> and not adding a new release to the main tree for a year? Would we be |
47 |
> better off if Docker 1 wasn't in the tree at all? If it happened to |
48 |
> have a known issue would ~arch users be better off if some other dev |
49 |
> came along and helpfully added it to the tree unmasked no realizing |
50 |
> that somebody else was already working on it? |
51 |
|
52 |
Take a look at profiles/package.mask. You will see many packages in |
53 |
there with the description, "masked for testing" on their masks, with no |
54 |
bug references, that have been there for multiple years. My view is we |
55 |
should either get those masks resolved or boot the affected |
56 |
packages/versions out of the tree. If they haven't received rudimentary |
57 |
testing by now, it is pretty obvious that no one cares about them. |
58 |
|
59 |
William |