On Thu, Aug 04, 2016 at 07:25:52PM -0400, Rich Freeman wrote: > On Thu, Aug 4, 2016 at 6:22 PM, William Hubbs wrote: *snip* > > > > My proposal is saying that if you have a version of a package in ~, > > testing is being done, and at the end of the testing period (30 days at > > most), that new version in ~ should move to stable if there are no > > blockers. It would be up to you, the maintainer, or any users running > > the ~ version, to test and file bugs that block stabilization. These > > bugs could be detected automatically. > > > > I'm mostly fine with that, but I'd add just a requirement that > somebody does a quick sanity check on an otherwise-stable system. The > 30 days of testing is really only testing against dependencies that > are in ~arch. Granted, that will become less of a concern if all > those dependencies are also making their way to stable. Repoman will complain loudly if you try to stabilize something that doesn't have all of its reverse dependencies stabilized, so I think we are safe as long as people listen to repoman. I'm not advocating stabilizing things with ~ reverse dependencies, just trying to find a way to move stabilization along better than it has been moving. *snip* > > > > We basically do. I don't have a link in front of me, but the council > > did make a decision allowing the removal of packages from the stable > > tree. It hasn't played out well though, because stable users expect > > that once a package is in the stable tree it will stay there until a > > newer version comes to the stable tree. > > I'd have to look up the exact decision, but it was basically left to > maintainer discretion after some time lag. I think it is a useful > safety valve. If the maintainer feels that the stable version is > de-facto unmaintained and is causing problems, then we're not doing > stable users any favors by just leaving it on their systems. Just go > ahead and drop it and stable users can stick it in an overlay if they > know what they're doing, but they won't just live with some unknown > issue. If we can get the newer version stabilized, we can then remove the older version without breaking stable, so this then becomes a non-issue. Also, getting the newer version stabilized is a more favorable approach because you don't have to deal with breaking the depgraph, or in the case of a package that is in the stages, if you remove the stable version, you can break the stages for that arch. *snip* > > > > 2. if the package is all data files, or if it is written in an > > interpreted language e.g. python, perl, etc., Once the testing period > > has passed, the maintainer will be allowed to stabilize it on all arches > > that have a stable version without a stable request. > > I believe there is already widespread agreement on this point. We've > talked about mechanisms to designate these packages but if we just > want to go with maintainer discretion we might be fine. Well, let me back up a bit on this one. We have the allarches keyword which can be added to a stable request to let the first arch team know to stabilize on all listed arches. Maybe we should forget option 2, and just say that if a package version is in ~ with a stable request opened for more than 30 days with all of its reverse dependencies stable the maintainer can stabilize that version of the package on all arches that have a stable version. William