1 |
On Thu, Aug 4, 2016 at 6:22 PM, William Hubbs <williamh@g.o> wrote: |
2 |
> On Thu, Aug 04, 2016 at 11:12:24PM +0300, Andrew Savchenko wrote: |
3 |
>> |
4 |
>> Thank you for caring about this issue. I had similar thoughts |
5 |
>> myself, but was too slow on writing e-mail :) IMO stable tree has |
6 |
>> three problems: |
7 |
>> 1) too old packages |
8 |
>> 2) too few packages |
9 |
>> 3) stabilization often takes too long, such stable packages are |
10 |
>> broken or buggy, while their unstable versions are fixed and work |
11 |
>> fine. (It is not possible to fix all bugs without version or |
12 |
>> revision bump, thus stabilization is needed to fix many bugs.) |
13 |
> |
14 |
> "too few packages" doesn't really affect things much, I'm more |
15 |
> concerned about 1 and 3. If packages are not stable in the first place, |
16 |
> that is because the maintainer hasn't requested stabilization, and that |
17 |
> is a separate issue. |
18 |
|
19 |
I'm less concerned with old (within reason) and few. I think the |
20 |
primary criteria has to always be that the packages are reliable. If |
21 |
somebody wants to make the tradeoff less reliability and fresher |
22 |
packages they can just install testing. |
23 |
|
24 |
> |
25 |
> My proposal is saying that if you have a version of a package in ~, |
26 |
> testing is being done, and at the end of the testing period (30 days at |
27 |
> most), that new version in ~ should move to stable if there are no |
28 |
> blockers. It would be up to you, the maintainer, or any users running |
29 |
> the ~ version, to test and file bugs that block stabilization. These |
30 |
> bugs could be detected automatically. |
31 |
> |
32 |
|
33 |
I'm mostly fine with that, but I'd add just a requirement that |
34 |
somebody does a quick sanity check on an otherwise-stable system. The |
35 |
30 days of testing is really only testing against dependencies that |
36 |
are in ~arch. Granted, that will become less of a concern if all |
37 |
those dependencies are also making their way to stable. |
38 |
|
39 |
I'm not suggesting anything rigorous. However, it would be a bit |
40 |
embarrassing to stabilize a package and find that it doesn't even |
41 |
build, or which has some glaring issue. Build testing at least could |
42 |
be automated, but I'm not sure if we need more than that. I'm not |
43 |
entirely opposed to loosening things up on a trial basis and seeing |
44 |
how it goes. However, if we're going to do that I wouldn't go nuts |
45 |
with automation in case we decide to back off. |
46 |
|
47 |
> |
48 |
> We basically do. I don't have a link in front of me, but the council |
49 |
> did make a decision allowing the removal of packages from the stable |
50 |
> tree. It hasn't played out well though, because stable users expect |
51 |
> that once a package is in the stable tree it will stay there until a |
52 |
> newer version comes to the stable tree. |
53 |
|
54 |
I'd have to look up the exact decision, but it was basically left to |
55 |
maintainer discretion after some time lag. I think it is a useful |
56 |
safety valve. If the maintainer feels that the stable version is |
57 |
de-facto unmaintained and is causing problems, then we're not doing |
58 |
stable users any favors by just leaving it on their systems. Just go |
59 |
ahead and drop it and stable users can stick it in an overlay if they |
60 |
know what they're doing, but they won't just live with some unknown |
61 |
issue. |
62 |
|
63 |
However, this shouldn't be done lightly. This isn't for that package |
64 |
that is 60 days old. And it really should be the last resort when the |
65 |
maintainer can't just stabilize it on their own (it is a bigger issue |
66 |
for minor archs where hardware is less available and arch teams don't |
67 |
have time to touch it). |
68 |
|
69 |
> |
70 |
> 2. if the package is all data files, or if it is written in an |
71 |
> interpreted language e.g. python, perl, etc., Once the testing period |
72 |
> has passed, the maintainer will be allowed to stabilize it on all arches |
73 |
> that have a stable version without a stable request. |
74 |
|
75 |
I believe there is already widespread agreement on this point. We've |
76 |
talked about mechanisms to designate these packages but if we just |
77 |
want to go with maintainer discretion we might be fine. |
78 |
|
79 |
-- |
80 |
Rich |