| 1 |
On Tue, 6 Dec 2005 23:19:38 +0900 |
| 2 |
Jason Stubbs <jstubbs@g.o> wrote: |
| 3 |
|
| 4 |
> So I'm going to make a decision and offer until Friday (Saturday in |
| 5 |
> my time) for opposers to solidify and state any opposition. If |
| 6 |
> there's no solid opposition, Saturday I will put current trunk into |
| 7 |
> ~arch as 2.1_beta20051210. I will also post on the 2.0.53 bug that |
| 8 |
> fixes are available for the ldconfig bug and the tee bug stating that |
| 9 |
> we'd like to also add trunk's cache subsystem to 2.0.54 and that |
| 10 |
> dependening on the next council meeting(?) the SHA1 enabling as well. |
| 11 |
> Doing it this way will make the ~arch users happy straight away. If |
| 12 |
> we look at it as our responsibility to get fixes and new |
| 13 |
> functionality into ~arch then our jobs done and we can get back to |
| 14 |
> business. |
| 15 |
|
| 16 |
Well, I've already stated several times that IMO using a 2.1 branch is |
| 17 |
wrong (use 2.2 instead), but if I'm overvoted, so it shall be. |
| 18 |
As for the cache rewrite in 2.0.54, I don't really prefer one way or the |
| 19 |
other, from an engineering POV it is 2.2 material, but if it is a major |
| 20 |
improvement and well tested it can also be in .54 (just in case my |
| 21 |
previous mail was misunderstood). |
| 22 |
|
| 23 |
> As for stable users? If arch teams are willing to selectively choose |
| 24 |
> what fixes they want backported to stable (when they're not prepared |
| 25 |
> to move the ~arch version into stable) things will go much smoother. |
| 26 |
> Of course, it would still be our responsibility to get those things |
| 27 |
> backported and assert some confidence that it is working. However, |
| 28 |
> once the requested fixes are backported all that needs to be done is |
| 29 |
> put out the patched stable version with ~arch keywords and then leave |
| 30 |
> it up to the arch teams again. Except for the slight extra burden on |
| 31 |
> (which I believe many would actually find to be a blessing), it |
| 32 |
> should be a win-win situation. |
| 33 |
|
| 34 |
Just in case you forgot and also for general reference, when I asked |
| 35 |
the arch teams about the portage keywording policy a few months ago |
| 36 |
(wether we should stable even without testing on all archs or to |
| 37 |
delegate that to arch teams) everyone seemed to be happy with the old |
| 38 |
policy, at least nobody voted for a change. As portage doesn't really |
| 39 |
have any arch specific code and a rather short dep list IMO it also |
| 40 |
doesn't yield any real benefit other than more people testing it (which |
| 41 |
is of course always a good thing). |
| 42 |
|
| 43 |
Marius |
| 44 |
|
| 45 |
-- |
| 46 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 47 |
|
| 48 |
In the beginning, there was nothing. And God said, 'Let there be |
| 49 |
Light.' And there was still nothing, but you could see a bit better. |
Archives