Re: [gentoo-portage-dev] The road ahead...

[Brian Harring]

On Sat, Oct 15, 2005 at 01:45:42PM +0900, Jason Stubbs wrote:
> Since I've fallen into the terrible pit of "trying to make everybody happy"
> and since IRC sucks for making decisions due to lack of continuity, let's
> battle it out here. ;)
/me refills the napalm, and gets ready...

> Where we're at:
>

<snip the branch estimates that I agree with>

> Which leaves us with 2.0 and a set of refactorings and features. I think it's
> pretty much decided that these will be backported to 2.0. The only question
> at this stage is when. The only complicating factor here is the current 225
> open bug reports. That and what to call 2.0+refactorings+features.
>
> So, there's pretty much three ways we can go:
>
> 1) Backport refactorings+features and release.
> 2) Fix more bugs, backport refactorings+features and release.
> 3) Fix more bugs, release, backport refactorings+features and release.
>
> There's still a lot of bugs that can be fixed without too much work, so I'd
> like to go with 2) or 3). I was thinking to go with 3) with the backported
> stuff being named 2.1.0, which is how we arrived at this thread.

Aside from the 2.1 name being already slightly abused, prefer option 
4, bug/release work, integrating chunks in as they're ready and 
releasing when things are stable.  Basically... when the chunks are 
ready to be integrated, they've been tested (ala cache patch + some 
more time), yank the suckers in, and continue with stabilising towards 
a release.

On the subject of versions, hich ever version the chunks get included 
under, they're going to need integration testing, so versioning isn't 
as much an issue to me as time.

The delta between 2.1 and 2.0, last time I generated it was half a 
meg; pulling chunks from 2.1 into 2.0 requires rewriting a chunk of 
glue, so minimizing the time/delta is something of a concern- eg, 
doing 2.0.* for a while, then a 2.1 I'm not totally much for.

My two cents, at least.
~harring