1 |
On 06/30/2014 09:25, Rich Freeman wrote: |
2 |
> On Mon, Jun 30, 2014 at 12:01 AM, William Hubbs <williamh@g.o> wrote: |
3 |
>> |
4 |
>> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: |
5 |
>>> On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@g.o> wrote: |
6 |
>>>> This is still too vague for me. If it's expected to be short-term, then |
7 |
>>>> it can as well just land in ~arch. |
8 |
>>> |
9 |
>>> A package that hasn't been tested AT ALL doesn't belong in ~arch. |
10 |
>>> Suppose the maintainer is unable to test some aspect of the package, |
11 |
>>> or any aspect of the package? Do we want it to break completely for |
12 |
>>> ~arch? In that event, nobody will run ~arch for that package, and |
13 |
>>> then it still isn't getting tested. |
14 |
>> |
15 |
>> I'm not saying that we should just randomly throw something into ~arch |
16 |
>> without testing it, but ~arch users are running ~arch with the |
17 |
>> understanding that their systems will break from time to time and they |
18 |
>> are expected to be able to deal with it when/if it happens. ~arch is |
19 |
>> not a second stable branch. |
20 |
> |
21 |
> Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED |
22 |
> AT ALL. The maintainer knows that they compile, and that is it. Or |
23 |
> maybe they tested it in a very limited set of circumstances but know |
24 |
> that other untested circumstances are important to the users and they |
25 |
> have definite plans to get them tested. |
26 |
|
27 |
I think what needs to be defined here is "testing". What if I know of a |
28 |
group of packages that are not only open-source and compile w/o major |
29 |
issues, but are in use in enterprise environments, and not yet in Gentoo? |
30 |
Would not a "compile and ship it" approach, into "~arch", work best for |
31 |
something like that? Do I really need to set up a testing platform for them |
32 |
and test each one out? |
33 |
|
34 |
That's just one example, though. Perhaps we need to work up some very broad |
35 |
and general guidelines on what "testing" means, and apply that to ~arch. |
36 |
|
37 |
|
38 |
>> In particular, I would argue that for system-critical packages, users |
39 |
>> should be very careful about running ~arch unless they know what the |
40 |
>> fallout can be. |
41 |
> |
42 |
> I agree. I think ~arch should break far more often than it does |
43 |
> today. However, I wouldn't extend that to sticking stuff in ~arch |
44 |
> that hasn't even been executed. If it is THAT unstable then nobody |
45 |
> will want to run it, and that defeats the goal of having more testing. |
46 |
|
47 |
I've been running ~arch for years and very rarely, do I see a breakage. |
48 |
We're not one of the BSDs, or even Debian, in which we maintain a static |
49 |
branch of specific package versions. In a way, I view "arch" to imply |
50 |
something very close to FreeBSD's -RELEASE branch, just with the flexibility |
51 |
of getting new major revisions periodically. "~arch" is more like -STABLE, |
52 |
but it moves faster and potentially introduces minor breakages once in a |
53 |
while, but nothing that requires a complete reinstall. |
54 |
|
55 |
We don't really have anything that's like -CURRENT or a nightly-like build, |
56 |
in which major, massive breakages are more common. TBH, I don't know if we |
57 |
should have something like that. The hybrid-like approach we have now seems |
58 |
to work out best for us. |
59 |
|
60 |
|
61 |
>> Take a look at profiles/package.mask. You will see many packages in |
62 |
>> there with the description, "masked for testing" on their masks, with no |
63 |
>> bug references, that have been there for multiple years. My view is we |
64 |
>> should either get those masks resolved or boot the affected |
65 |
>> packages/versions out of the tree. If they haven't received rudimentary |
66 |
>> testing by now, it is pretty obvious that no one cares about them. |
67 |
> |
68 |
> Are they even maintained? |
69 |
|
70 |
We probably just need to step up review and cleaning out of package.mask |
71 |
more often. Since Portage tools can parse the file already, it shouldn't be |
72 |
too hard to determine if there are any masks in there for packages or |
73 |
package versions that no longer exist in the tree and prune it down some. |
74 |
|
75 |
|
76 |
> If not maintained, then leave them alone until treecleaned. If they |
77 |
> are maintained, then I'd be interested in hearing from maintainers as |
78 |
> to what they're up to. I wouldn't just remove the mask unless |
79 |
> somebody is actually going to co-maintain. The issue of absentee |
80 |
> maintainers is a different one than masks, though obsolete masks is a |
81 |
> symptom of it just like obsolete ebuilds are. |
82 |
|
83 |
Perhaps some periodic, automated reminders to anyone who adds a package to |
84 |
package.mask to check up on it? If the mask persists for a while after such |
85 |
a notification, it escalates to QA or to -dev? |
86 |
|
87 |
-- |
88 |
Joshua Kinard |
89 |
Gentoo/MIPS |
90 |
kumba@g.o |
91 |
4096R/D25D95E3 2011-03-28 |
92 |
|
93 |
"The past tempts us, the present confuses us, the future frightens us. And |
94 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
95 |
|
96 |
--Emperor Turhan, Centauri Republic |