1 |
Marius Mauch wrote: |
2 |
|
3 |
>On Tue, 6 Dec 2005 23:19:38 +0900 |
4 |
>Jason Stubbs <jstubbs@g.o> wrote: |
5 |
> |
6 |
> |
7 |
> |
8 |
>>So I'm going to make a decision and offer until Friday (Saturday in |
9 |
>>my time) for opposers to solidify and state any opposition. If |
10 |
>>there's no solid opposition, Saturday I will put current trunk into |
11 |
>>~arch as 2.1_beta20051210. I will also post on the 2.0.53 bug that |
12 |
>>fixes are available for the ldconfig bug and the tee bug stating that |
13 |
>>we'd like to also add trunk's cache subsystem to 2.0.54 and that |
14 |
>>dependening on the next council meeting(?) the SHA1 enabling as well. |
15 |
>>Doing it this way will make the ~arch users happy straight away. If |
16 |
>>we look at it as our responsibility to get fixes and new |
17 |
>>functionality into ~arch then our jobs done and we can get back to |
18 |
>>business. |
19 |
>> |
20 |
>> |
21 |
> |
22 |
>Well, I've already stated several times that IMO using a 2.1 branch is |
23 |
>wrong (use 2.2 instead), but if I'm overvoted, so it shall be. |
24 |
>As for the cache rewrite in 2.0.54, I don't really prefer one way or the |
25 |
>other, from an engineering POV it is 2.2 material, but if it is a major |
26 |
>improvement and well tested it can also be in .54 (just in case my |
27 |
>previous mail was misunderstood). |
28 |
> |
29 |
> |
30 |
> |
31 |
>>As for stable users? If arch teams are willing to selectively choose |
32 |
>>what fixes they want backported to stable (when they're not prepared |
33 |
>>to move the ~arch version into stable) things will go much smoother. |
34 |
>>Of course, it would still be our responsibility to get those things |
35 |
>>backported and assert some confidence that it is working. However, |
36 |
>>once the requested fixes are backported all that needs to be done is |
37 |
>>put out the patched stable version with ~arch keywords and then leave |
38 |
>>it up to the arch teams again. Except for the slight extra burden on |
39 |
>>(which I believe many would actually find to be a blessing), it |
40 |
>>should be a win-win situation. |
41 |
>> |
42 |
>> |
43 |
> |
44 |
> |
45 |
> |
46 |
I spoke with Brian today ( no clue if he will be sending mail or not ) |
47 |
but he stressed that he would like the cache rewrite in ~arch. I would |
48 |
prefer that it be in .54, the code itself is old, 6+ months. It is a |
49 |
straight backport from the 2.1 branch (the dead one) and the interface |
50 |
code to make it fit with 2.0 is small compared to the patch size ( Brian |
51 |
estimated 100-150 lines ). I don't have a problem with releasing 2 |
52 |
ebuilds, one with the patch and one without ( or a use flag ) although |
53 |
the question that raises is will the cache rewrite actually end up in |
54 |
.54 final, or will it be put off :) |
55 |
|
56 |
>Just in case you forgot and also for general reference, when I asked |
57 |
>the arch teams about the portage keywording policy a few months ago |
58 |
>(wether we should stable even without testing on all archs or to |
59 |
>delegate that to arch teams) everyone seemed to be happy with the old |
60 |
>policy, at least nobody voted for a change. As portage doesn't really |
61 |
>have any arch specific code and a rather short dep list IMO it also |
62 |
>doesn't yield any real benefit other than more people testing it (which |
63 |
>is of course always a good thing). |
64 |
> |
65 |
>Marius |
66 |
> |
67 |
> |
68 |
> |
69 |
|
70 |
-- |
71 |
gentoo-portage-dev@g.o mailing list |