1 |
On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
> Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted: |
3 |
> |
4 |
>> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner <antarus@g.o> |
5 |
>> wrote: |
6 |
>>> |
7 |
>>> |
8 |
>>> Sorry, to be clear the conclusion I was hoping to draw is that one has |
9 |
>>> 2 repos instead of 1. |
10 |
>>> |
11 |
>>> 1) Rolling. |
12 |
>>> 2) Stable. |
13 |
>>> |
14 |
>>> Rolling is typical ~arch Gentoo. People in rolling can do whatever they |
15 |
>>> want; they can't affect stable at all. |
16 |
>>> |
17 |
>>> Stable is an entirely separate repo, a fork, where CPVs are pulled from |
18 |
>>> Rolling into Stable. If Stable wants to keep a gnarly old version of |
19 |
>>> some package around; great! But the rolling people don't have to care. |
20 |
>>> |
21 |
>>> |
22 |
>> This seems like it would be fairly painful to maintain. You'd need to |
23 |
>> constantly pull in new packages, and prune out old ones. It would |
24 |
>> duplicate many of the functions maintainers already do. I doubt anybody |
25 |
>> would go to the trouble to make this happen. |
26 |
> |
27 |
> FWIW, the gentoo/kde team effectively do this right now, tho only with kde |
28 |
> packages and some of their deps, and it's live/prerelease/release-staging |
29 |
> vs ~arch/stable, not ~arch vs stable. But the amount of work is surely |
30 |
> similar, and they've been doing it now for a number of years and over a |
31 |
> major kde version bump, an upstream svn/git upgrade and general upstream |
32 |
> remodularization. |
33 |
> |
34 |
|
35 |
The difficulty isn't in moving the ebuilds around. |
36 |
|
37 |
The difficulty is in knowing WHICH ebuilds to move around. |
38 |
|
39 |
In the case of KDE it is the maintainers doing the maintaining, so |
40 |
they already understand which versions should move. They've all been |
41 |
tested, so I suspect it is likely a lift and place of the entire |
42 |
thing. |
43 |
|
44 |
In the proposed multi-repository approach the maintainers would not be |
45 |
the ones doing the moving. |
46 |
|
47 |
Now, I guess you could have a snapshot/release-based approach. Take a |
48 |
snapshot of the ENTIRE ~arch tree. Then do whatever level of QA, and |
49 |
after a delay move the ENTIRE ~arch tree to stable. The problem with |
50 |
this is that you'll probably pick that oddball version of some package |
51 |
that is about to be replaced and isn't a good stable candidate, and so |
52 |
on. It also would be difficult to actually test it all. |
53 |
|
54 |
And if you're going to get the maintainers to move all their own |
55 |
stuff, then you're just giving them extra work compared to just using |
56 |
the KEYWORDS variable. |
57 |
|
58 |
In the current state the maintainer is at the heart of the |
59 |
stabilization process, so the person who already needs to understand |
60 |
the individual package is the one deciding which versions go stable. |
61 |
Duplicating this level of knowledge would not be straightforward. |
62 |
|
63 |
-- |
64 |
Rich |