On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted: > >> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <anta...@gentoo.org> >> wrote: >>> >>> >>> Sorry, to be clear the conclusion I was hoping to draw is that one has >>> 2 repos instead of 1. >>> >>> 1) Rolling. >>> 2) Stable. >>> >>> Rolling is typical ~arch Gentoo. People in rolling can do whatever they >>> want; they can't affect stable at all. >>> >>> Stable is an entirely separate repo, a fork, where CPVs are pulled from >>> Rolling into Stable. If Stable wants to keep a gnarly old version of >>> some package around; great! But the rolling people don't have to care. >>> >>> >> This seems like it would be fairly painful to maintain. You'd need to >> constantly pull in new packages, and prune out old ones. It would >> duplicate many of the functions maintainers already do. I doubt anybody >> would go to the trouble to make this happen. > > FWIW, the gentoo/kde team effectively do this right now, tho only with kde > packages and some of their deps, and it's live/prerelease/release-staging > vs ~arch/stable, not ~arch vs stable. But the amount of work is surely > similar, and they've been doing it now for a number of years and over a > major kde version bump, an upstream svn/git upgrade and general upstream > remodularization. >
The difficulty isn't in moving the ebuilds around. The difficulty is in knowing WHICH ebuilds to move around. In the case of KDE it is the maintainers doing the maintaining, so they already understand which versions should move. They've all been tested, so I suspect it is likely a lift and place of the entire thing. In the proposed multi-repository approach the maintainers would not be the ones doing the moving. Now, I guess you could have a snapshot/release-based approach. Take a snapshot of the ENTIRE ~arch tree. Then do whatever level of QA, and after a delay move the ENTIRE ~arch tree to stable. The problem with this is that you'll probably pick that oddball version of some package that is about to be replaced and isn't a good stable candidate, and so on. It also would be difficult to actually test it all. And if you're going to get the maintainers to move all their own stuff, then you're just giving them extra work compared to just using the KEYWORDS variable. In the current state the maintainer is at the heart of the stabilization process, so the person who already needs to understand the individual package is the one deciding which versions go stable. Duplicating this level of knowledge would not be straightforward. -- Rich
