1 |
On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs <williamh@g.o> wrote: |
2 |
> |
3 |
> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: |
4 |
>> On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@g.o> wrote: |
5 |
>> > This is still too vague for me. If it's expected to be short-term, then |
6 |
>> > it can as well just land in ~arch. |
7 |
>> |
8 |
>> A package that hasn't been tested AT ALL doesn't belong in ~arch. |
9 |
>> Suppose the maintainer is unable to test some aspect of the package, |
10 |
>> or any aspect of the package? Do we want it to break completely for |
11 |
>> ~arch? In that event, nobody will run ~arch for that package, and |
12 |
>> then it still isn't getting tested. |
13 |
> |
14 |
> I'm not saying that we should just randomly throw something into ~arch |
15 |
> without testing it, but ~arch users are running ~arch with the |
16 |
> understanding that their systems will break from time to time and they |
17 |
> are expected to be able to deal with it when/if it happens. ~arch is |
18 |
> not a second stable branch. |
19 |
|
20 |
Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED |
21 |
AT ALL. The maintainer knows that they compile, and that is it. Or |
22 |
maybe they tested it in a very limited set of circumstances but know |
23 |
that other untested circumstances are important to the users and they |
24 |
have definite plans to get them tested. |
25 |
|
26 |
> In particular, I would argue that for system-critical packages, users |
27 |
> should be very careful about running ~arch unless they know what the |
28 |
> fallout can be. |
29 |
|
30 |
I agree. I think ~arch should break far more often than it does |
31 |
today. However, I wouldn't extend that to sticking stuff in ~arch |
32 |
that hasn't even been executed. If it is THAT unstable then nobody |
33 |
will want to run it, and that defeats the goal of having more testing. |
34 |
|
35 |
> Take a look at profiles/package.mask. You will see many packages in |
36 |
> there with the description, "masked for testing" on their masks, with no |
37 |
> bug references, that have been there for multiple years. My view is we |
38 |
> should either get those masks resolved or boot the affected |
39 |
> packages/versions out of the tree. If they haven't received rudimentary |
40 |
> testing by now, it is pretty obvious that no one cares about them. |
41 |
|
42 |
Are they even maintained? |
43 |
|
44 |
If not maintained, then leave them alone until treecleaned. If they |
45 |
are maintained, then I'd be interested in hearing from maintainers as |
46 |
to what they're up to. I wouldn't just remove the mask unless |
47 |
somebody is actually going to co-maintain. The issue of absentee |
48 |
maintainers is a different one than masks, though obsolete masks is a |
49 |
symptom of it just like obsolete ebuilds are. |
50 |
|
51 |
Rich |