1 |
On Thu, Aug 04, 2016 at 07:25:52PM -0400, Rich Freeman wrote: |
2 |
> On Thu, Aug 4, 2016 at 6:22 PM, William Hubbs <williamh@g.o> wrote: |
3 |
|
4 |
*snip* |
5 |
|
6 |
> > |
7 |
> > My proposal is saying that if you have a version of a package in ~, |
8 |
> > testing is being done, and at the end of the testing period (30 days at |
9 |
> > most), that new version in ~ should move to stable if there are no |
10 |
> > blockers. It would be up to you, the maintainer, or any users running |
11 |
> > the ~ version, to test and file bugs that block stabilization. These |
12 |
> > bugs could be detected automatically. |
13 |
> > |
14 |
> |
15 |
> I'm mostly fine with that, but I'd add just a requirement that |
16 |
> somebody does a quick sanity check on an otherwise-stable system. The |
17 |
> 30 days of testing is really only testing against dependencies that |
18 |
> are in ~arch. Granted, that will become less of a concern if all |
19 |
> those dependencies are also making their way to stable. |
20 |
|
21 |
Repoman will complain loudly if you try to stabilize something that |
22 |
doesn't have all of its reverse dependencies stabilized, so I think we |
23 |
are safe as long as people listen to repoman. I'm not advocating |
24 |
stabilizing things with ~ reverse dependencies, just trying to find a |
25 |
way to move stabilization along better than it has been moving. |
26 |
|
27 |
*snip* |
28 |
|
29 |
> > |
30 |
> > We basically do. I don't have a link in front of me, but the council |
31 |
> > did make a decision allowing the removal of packages from the stable |
32 |
> > tree. It hasn't played out well though, because stable users expect |
33 |
> > that once a package is in the stable tree it will stay there until a |
34 |
> > newer version comes to the stable tree. |
35 |
> |
36 |
> I'd have to look up the exact decision, but it was basically left to |
37 |
> maintainer discretion after some time lag. I think it is a useful |
38 |
> safety valve. If the maintainer feels that the stable version is |
39 |
> de-facto unmaintained and is causing problems, then we're not doing |
40 |
> stable users any favors by just leaving it on their systems. Just go |
41 |
> ahead and drop it and stable users can stick it in an overlay if they |
42 |
> know what they're doing, but they won't just live with some unknown |
43 |
> issue. |
44 |
|
45 |
If we can get the newer version stabilized, we can then remove the |
46 |
older version without breaking stable, so this then becomes a |
47 |
non-issue. |
48 |
|
49 |
Also, getting the newer version stabilized is a more favorable approach |
50 |
because you don't have to deal with breaking the depgraph, or in the |
51 |
case of a package that is in the stages, if you remove the stable |
52 |
version, you can break the stages for that arch. |
53 |
|
54 |
*snip* |
55 |
|
56 |
> > |
57 |
> > 2. if the package is all data files, or if it is written in an |
58 |
> > interpreted language e.g. python, perl, etc., Once the testing period |
59 |
> > has passed, the maintainer will be allowed to stabilize it on all arches |
60 |
> > that have a stable version without a stable request. |
61 |
> |
62 |
> I believe there is already widespread agreement on this point. We've |
63 |
> talked about mechanisms to designate these packages but if we just |
64 |
> want to go with maintainer discretion we might be fine. |
65 |
|
66 |
Well, let me back up a bit on this one. We have the allarches keyword |
67 |
which can be added to a stable request to let the first arch team know |
68 |
to stabilize on all listed arches. |
69 |
|
70 |
Maybe we should forget option 2, and just say that if a package version is in ~ |
71 |
with a stable request opened for more than 30 days with all of its |
72 |
reverse dependencies stable the maintainer can stabilize that version of |
73 |
the package on all arches that have a stable version. |
74 |
|
75 |
William |