Re: [gentoo-portage-dev] .53, .54 and beyond...

[Jason Stubbs]

On Thursday 01 December 2005 22:28, Jason Stubbs wrote:
> On Monday 28 November 2005 03:49, Marius Mauch wrote:
> > Jason Stubbs wrote:
> > > On Sunday 27 November 2005 00:09, Marius Mauch wrote:
> > >>Jason Stubbs wrote:
> > >>Well, the vote was more for the SHA1 change actually as that's the one
> > >>triggering the size increase. The pycrypto stuff itself doesn't do
> > >>anything really, it would just make the size increase more apparent.
> > >
> > > Hmm.. I thought it was for hashes supported by pycrypto being added
> > > into Manifest before Manifest2 comes along. If it was with regard to
> > > SHA1 then I take back my vote to delay.
> >
> > Yeah, I guess the mail could be read both ways.
> >
> > >>Don't think so given that offhand I don't even know what getlist() does
> > >> ...
> > >
> > > getlist() is defined in emerge and is used to access the system and
> > > world sets. It wouldn't be too hard to customize it to handle user sets
> > > and modify other code to support them but the "can't combine sets and
> > > atoms" rule would get a bit messy.
> >
> > So gutting of emerge ... nope, tried that two times already, but gave up
> > after hitting too many direct references to system and world.
> >
> > >>Oh, btw, two things that are in trunk but weren't listed in your
> > >>original mail:
> > >>- the rewritten versioning code (including the cvs and mult-suffix
> > >>enhancements)
> > >>- finally killing of the stupid "masked by -*" message
> > >
> > > That makes the current list for .54:
> > >
> > > * autouse death
> > > * cache rewrite
> > > * dyn_install cleanup
> > > * einfo logging
> > > * exec cleanup
> > > * flattened vdb *DEPENDs
> > > * hash support via pycrypto
> > > * ldconfig fix
> > > * metascan/auxget
> > > * postsync hooks
> > > * recursive grab*
> > > * RRDEPEND/LDEPEND
> > > * sha1 enabling
> > > * splitdebug
> > > * vdb empty file culling
> > >
> > > Are we about there yet? Also, what does this mean for 2.1/2.2?
> >
> > Well, if that featurelist is .54 then I really don't see a point for
> > making a 2.1 or 2.2 release line. Before your mail starting this thread
> > I assumed that .54 would just contain the ldconfig fix, the hash stuff
> > and maybe a few other minor things, while trunk would become 2.2.
> > But if things like elog, the new cache subsystem, splitdebug or the
> > *DEPEND changes don't qualify for a "minor" version bump, then I can't
> > think of anything that would.
>
> The ldconfig bug and the exec cleanup are the only urgent ones among them.
> The exec cleanup could be postponed and the existing code twiddled in a
> couple of places to fix the logging bug. However, the biggest issue that
> users are complaining about at present is the caching. The biggest issue
> for devs is security. Hence my original list:
>
> * cache rewrite
> * exec cleanup
> * ldconfig fix
> * sha1 enabling

Okay, new suggestion.

Postpone the cache rewrite from above. Have only the minimal mods necessary to 
fix the PORT_LOGDIR/tee bug. Include the other two as is. That would be 
2.0.54 as per the attached patch. Get that out soon and get trunk out masked 
at around the same time. As soon as 2.0.54 goes stable put trunk into ~arch. 
However, instead of ~arch meaning "regression fixes only" we could just limit 
it to "minor changes only" (ie. no big refactorings, rewrites or similar high 
risk changes) until it is time to stable it.

However, with the trunk's target (2.1?) rather than letting the arch teams 
decide when we call it stable, I think it would be a better idea to move it 
to the .0 version when we feel it is ready leaving it in ~arch. As 
regressions are fixed the .0 can be bumped to .1, .2 or whatever, but the 
focus can move to what happens beyond that rather than waiting...

First paragraph is more important right now.

--
Jason Stubbs