| 1 |
On Tuesday 06 December 2005 11:29, Zac Medico wrote: |
| 2 |
> Ned Ludd wrote: |
| 3 |
> > On Mon, 2005-12-05 at 23:06 +0900, Jason Stubbs wrote: |
| 4 |
> >>Okay, new suggestion. |
| 5 |
> >> |
| 6 |
> >>Postpone the cache rewrite from above. Have only the minimal mods |
| 7 |
> >> necessary to fix the PORT_LOGDIR/tee bug. Include the other two as is. |
| 8 |
> >> That would be 2.0.54 as per the attached patch. Get that out soon and |
| 9 |
> >> get trunk out masked at around the same time. As soon as 2.0.54 goes |
| 10 |
> >> stable put trunk into ~arch. However, instead of ~arch meaning |
| 11 |
> >> "regression fixes only" we could just limit it to "minor changes only" |
| 12 |
> >> (ie. no big refactorings, rewrites or similar high risk changes) until |
| 13 |
> >> it is time to stable it. |
| 14 |
> > |
| 15 |
> > I think it would be wise to reconsider the cache fixes. I know you have |
| 16 |
> > been away from irc for a while now and have missed the daily events, |
| 17 |
> > but most of the people we have interacted with are expecting the cache |
| 18 |
> > updates in .54 (alot of people complaining about the hanging at 50%) |
| 19 |
> > |
| 20 |
> > The code has been pretty well tested and seems safe on the surface. I |
| 21 |
> > think ferringb's testing has shown that the cache updates use about 14M |
| 22 |
> > of ram where the existing code (as of .52.x) uses about 80M of ram. |
| 23 |
> |
| 24 |
> But still, it's annoying to be stuck with only 2 tiers. Why not put a |
| 25 |
> snapshot of trunk in the tree and package.mask it? Wouldn't that make |
| 26 |
> everyone happy? |
| 27 |
|
| 28 |
That's what I'm thinking. Given that the people that are being asked to stable |
| 29 |
2.0.53 are complaining that the ldconfig fix and exec/tee fix aren't in it, |
| 30 |
I'm certain that 2.0.54 would likely go stable *before* 2.0.53 if it is |
| 31 |
pushed out soon. If the SHA1 stuff is dropped, I can pretty much guarantee |
| 32 |
it. And as soon as it goes stable, trunk can be pushed into ~arch. |
| 33 |
|
| 34 |
Doing it this way, the cache rewrite gets into ~arch at pretty much the same |
| 35 |
time but all the other bits get added along with it. Sure it will mean that |
| 36 |
there will be a bit of a delay before it gets into stable but if we can speed |
| 37 |
up the release cycle the delay won't be by very much. |
| 38 |
|
| 39 |
-- |
| 40 |
Jason Stubbs |
| 41 |
-- |
| 42 |
gentoo-portage-dev@g.o mailing list |
Archives