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

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

[Jason Stubbs]

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. ;)

Where we're at:

branches/2.0/
Branch from which releases are being made. Very stable as far as portage goes.

branches/savior/
Rewrite which will eventually become 3.0. Still in the early stages.

trunk/
I think Brian summed it up quite well. A lot of experimentation, some 
haphazard refactoring, some well done refactoring, some incomplete features 
and some completed features. Currently quite buggy.

At an estimate, trunk would take at least 3 months of dedicated work to 
stabilize. Given the fact that it will be obsoleted by savior, it would not 
be economical to focus our efforts there. That leaves us with savior, 2.0 and 
a set of refactorings and features. Savior is easy enough. Keep working on it 
until it's ready. ;)

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.

Anyway, flame-war time. :D

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Zac Medico]

Brian Harring wrote:
> On Sat, Oct 15, 2005 at 01:45:42PM +0900, Jason Stubbs wrote:
>>
>>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.
> 

I am very impressed with the number of bugs closed in preparation for the 2.0.53 release (dependencies of bug 108082) and it seems like it is in everyone's best interest to keep up this pace so that all the easy bugs are closed ASAP.  There is already a large list of *open* dependencies for the 2.0.54 (bug 108262) that will hopefully be closed and released soon.  :)

> 
> 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.
> 

It should be possible to integrate some refactorings+features without too much slowdown of the easy bugfix release pace (call it the EBRP for now).  IMO the timing of such merges should be limited to times that everyone (people with commit access) agrees will have a minimal impact on the EBRP.

Brian's cache rewrite backport seems like an example of something that can be merged relatively soon.  The modularity of the existing cache makes it relatively easy to replace without causing regressions.  In addition, the cache backport almost falls into the category of an "easy bugfix" considering problems with the existing cache code (bug 108412 for example).

Zac
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

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. ;)

Something I forgot to tag into the other email...
Personally, I can live with which ever direction things go.  What I'm 
mainly after is that whatever route/plan choosen, is stuck to.

Really not much for 2.1 (existing ebd based) being brought up as a 
release line N months down the line, since 2 branches of development 
is a pita enough, let alone 3 with fairly radical differences between 
each branch.  Not saying the path can't be tweaked as we're 
proceeding, but would *really* like to know that as a group/community, 
this is what we're going towards rather then in N different 
directions.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Jason Stubbs]

On Sunday 16 October 2005 14:20, Zac Medico wrote:
> I am very impressed with the number of bugs closed in preparation for the
> 2.0.53 release (dependencies of bug 108082) and it seems like it is in
> everyone's best interest to keep up this pace so that all the easy bugs are
> closed ASAP.  There is already a large list of *open* dependencies for the
> 2.0.54 (bug 108262) that will hopefully be closed and released soon.  :)

It will likely be that some of the bugs marked against 108262 won't be fixed 
in time. Perhaps it would have been better to just open a metabug when the 
branch is opened and mark bugs against it as they are fixed.

> It should be possible to integrate some refactorings+features without too
> much slowdown of the easy bugfix release pace (call it the EBRP for now). 
> IMO the timing of such merges should be limited to times that everyone
> (people with commit access) agrees will have a minimal impact on the EBRP.

Stabalizing 2.0.53 took 2 weeks - assuming all the regressions are now worked 
out. Perhaps something like a 6 week cycle would be good? 2 weeks for any 
change, 2 weeks for small changes only, 2 weeks stabalizing...

On Saturday 15 October 2005 14:16, Brian Harring wrote:
> Really not much for 2.1 (existing ebd based) being brought up as a
> release line N months down the line, since 2 branches of development
> is a pita enough, let alone 3 with fairly radical differences between
> each branch.  Not saying the path can't be tweaked as we're
> proceeding, but would *really* like to know that as a group/community,
> this is what we're going towards rather then in N different
> directions.

I don't really like the idea of trunk being stabalized either. Too much work 
to bring forward all the changes in stable as well as fixing its own bugs.

On Saturday 15 October 2005 13:59, Brian Harring wrote:
> On Sat, Oct 15, 2005 at 01:45:42PM +0900, Jason Stubbs wrote:
> > 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.
>
> 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.

To clarify: Treat backports as regular bugs and go through cycles of open the 
2.0 branch for fixes for a while followed by stabalizing for a while?

> On the subject of versions, which 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.

The thing I'm concerned about is the backports and bigger bugs that will 
require a longer stabalizing period. That and the fact that a few of them are 
also quite major in terms of what the user sees. It makes sense to me to 
group these together, bump the version to 2.1 and finally make the version 
numbers meaningful.

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Zac Medico]

Jason Stubbs wrote:
>
> It will likely be that some of the bugs marked against 108262 won't be fixed 
> in time. Perhaps it would have been better to just open a metabug when the 
> branch is opened and mark bugs against it as they are fixed.

It's nice to have a list of open bugs against the release where everyone can see it.  I suppose this mailing list can serve that purpose though.

> 
>>It should be possible to integrate some refactorings+features without too
>>much slowdown of the easy bugfix release pace (call it the EBRP for now). 
>>IMO the timing of such merges should be limited to times that everyone
>>(people with commit access) agrees will have a minimal impact on the EBRP.
> 
> 
> Stabalizing 2.0.53 took 2 weeks - assuming all the regressions are now worked 
> out. Perhaps something like a 6 week cycle would be good? 2 weeks for any 
> change, 2 weeks for small changes only, 2 weeks stabalizing...
> 

I'm not so sure about the "2 weeks for *any* change" part. We need to be very selective about the larger changes.

<snip>
> 
> To clarify: Treat backports as regular bugs and go through cycles of open the 
> 2.0 branch for fixes for a while followed by stabalizing for a while?
> 
<snip>
> 
> The thing I'm concerned about is the backports and bigger bugs that will 
> require a longer stabalizing period. That and the fact that a few of them are 
> also quite major in terms of what the user sees. It makes sense to me to 
> group these together, bump the version to 2.1 and finally make the version 
> numbers meaningful.
> 

Longer stabilization periods also concern me.  Many of the larger changes should probably be reserved for a major version bump.  However, it's possible that along the way, some larger changes will be possible without significantly increasing the stabilization periods.  Of course, such changes should be carefully evaluated and the time that they are merged should be carefully coordinated.

Zac
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Jason Stubbs]

On Monday 17 October 2005 08:25, Zac Medico wrote:
> Jason Stubbs wrote:
> > It will likely be that some of the bugs marked against 108262 won't be
> > fixed in time. Perhaps it would have been better to just open a metabug
> > when the branch is opened and mark bugs against it as they are fixed.
>
> It's nice to have a list of open bugs against the release where everyone
> can see it.  I suppose this mailing list can serve that purpose though.

That's the thing though.. Most of the bugs we should be looking at fixing are 
15 minute jobs - maybe an hour on the "big" ones. If bugs are marked as 
blocking as patches are made and committed and then marked as fixed when a 
release is made, it should still be as easy to follow the progress.

Looking closer at some of the bugs I've marked as possible targets for .54, a 
few will likely have to be deferred. That just means more junk mail from 
apache@bugs.gentoo.org and broken hopes for those that had activity on their 
bugs.

> >>It should be possible to integrate some refactorings+features without too
> >>much slowdown of the easy bugfix release pace (call it the EBRP for now).
> >>IMO the timing of such merges should be limited to times that everyone
> >>(people with commit access) agrees will have a minimal impact on the
> >> EBRP.
> >
> > Stabalizing 2.0.53 took 2 weeks - assuming all the regressions are now
> > worked out. Perhaps something like a 6 week cycle would be good? 2 weeks
> > for any change, 2 weeks for small changes only, 2 weeks stabalizing...
>
> I'm not so sure about the "2 weeks for *any* change" part. We need to be
> very selective about the larger changes.

After thinking about it, incremental "feature creep" does seem like the best 
way to go at this late stage in 2.0's life. The problem is how to guage what 
is and what is not more trouble than worth. Perhaps adhering to the kernel's 
rule of "Separate each logical change into its own patch" would help to ease 
the possible impact of larger changes?

> > To clarify: Treat backports as regular bugs and go through cycles of open
> > the 2.0 branch for fixes for a while followed by stabalizing for a while?

So where shall we head next? 2.0.53_rc6 is tagged and a tarball is making it's 
way to the mirrors. I'm pretty confident that this is the last - that is to 
say, 2.0.53 will essentially just be a renamed tarball - so time's pretty 
much up for deciding on the above. I know I'm itching to start knocking of 
some bugs again...

Speaking of which, if something does crop up with 2.0.53 while the arch guys 
are deciding if it's stable, how should that be dealt with in subversion? 
Continue development under branches/2.0 and, should an issue crop up, `svn cp 
tags/2.0.53_rc6 tags/2.0.53_rc7` and make any required change directly under 
the tag?

Another "by the way", `svn -v log > ChangeLog` for 2.0.53_rc6. I'm open to 
anything better if anybody has a good format for autogeneration. The quality 
of the commit messages themselves isn't really useful though without knowing 
their context, so this might be a bit of a catch 22.. For 2.0.54, viewsvn 
should be available so it might be better to just use the tracker bug to 
manually create a summary of notable changes.

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Marius Mauch]

Jason Stubbs wrote:
> After thinking about it, incremental "feature creep" does seem like the best 
> way to go at this late stage in 2.0's life. The problem is how to guage what 
> is and what is not more trouble than worth. Perhaps adhering to the kernel's 
> rule of "Separate each logical change into its own patch" would help to ease 
> the possible impact of larger changes?

Probably the best solution.

> Speaking of which, if something does crop up with 2.0.53 while the arch guys 
> are deciding if it's stable, how should that be dealt with in subversion? 
> Continue development under branches/2.0 and, should an issue crop up, `svn cp 
> tags/2.0.53_rc6 tags/2.0.53_rc7` and make any required change directly under 
> the tag?

Never commit to a tag, make a branch (branches are cheap in svn), and if 
the branch is finished make a tag. Btw, anyone object to swap 
branches/2.0 with trunk (seeing that 2.1 is dead)?

> Another "by the way", `svn -v log > ChangeLog` for 2.0.53_rc6. I'm open to 
> anything better if anybody has a good format for autogeneration. The quality 
> of the commit messages themselves isn't really useful though without knowing 
> their context, so this might be a bit of a catch 22.. For 2.0.54, viewsvn 
> should be available so it might be better to just use the tracker bug to 
> manually create a summary of notable changes.

Hmm, so you want to change the ChangeLog into release notes? IMO we 
should have both (a detailed technical ChangeLog and user friendly 
release notes).

Marius
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Jason Stubbs]

On Friday 21 October 2005 19:06, Marius Mauch wrote:
> Jason Stubbs wrote:
> > After thinking about it, incremental "feature creep" does seem like the
> > best way to go at this late stage in 2.0's life. The problem is how to
> > guage what is and what is not more trouble than worth. Perhaps adhering
> > to the kernel's rule of "Separate each logical change into its own patch"
> > would help to ease the possible impact of larger changes?
>
> Probably the best solution.

Brian, you agree on this? It'll mean splitting up the cache patch...

> > Speaking of which, if something does crop up with 2.0.53 while the arch
> > guys are deciding if it's stable, how should that be dealt with in
> > subversion? Continue development under branches/2.0 and, should an issue
> > crop up, `svn cp tags/2.0.53_rc6 tags/2.0.53_rc7` and make any required
> > change directly under the tag?
>
> Never commit to a tag, make a branch (branches are cheap in svn), and if
> the branch is finished make a tag.

The cheapness is exactly why I was questioning. Consider:

# svn cp tags/2.0.53 branches/2.0.53-branch
# cd branches/2.0.53-branch
# patch < something-that-needs-fixing-now.patch
# svn ci
# cd ../..
# svn cp branches/2.0.53-branch tags/2.0.53-r1
# svn rm branches/2.0.53-branch
# svn ci

compared to:

# svn cp tags/2.0.53 tags/2.0.53-r1
# cd tags/2.0.53-r1
# patch < something-that-needs-fixing-now.patch
# svn ci

With the way subversion works, I would have thought the end result would be 
identical...

> Btw, anyone object to swap branches/2.0 with trunk (seeing that 2.1 is 
> dead)? 

No objections here.

> > Another "by the way", `svn -v log > ChangeLog` for 2.0.53_rc6. I'm open
> > to anything better if anybody has a good format for autogeneration. The
> > quality of the commit messages themselves isn't really useful though
> > without knowing their context, so this might be a bit of a catch 22.. For
> > 2.0.54, viewsvn should be available so it might be better to just use the
> > tracker bug to manually create a summary of notable changes.
>
> Hmm, so you want to change the ChangeLog into release notes? IMO we
> should have both (a detailed technical ChangeLog and user friendly
> release notes).

I'm not much for the ChangeLog at all really. At least not without going over 
what makes a good commit message and setting up some guidelines. I'm 
definitely for any ChangeLog being autogenerated though.

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

On Sat, Oct 22, 2005 at 12:14:40AM +0900, Jason Stubbs wrote:
> On Friday 21 October 2005 19:06, Marius Mauch wrote:
> > Jason Stubbs wrote:
> > > After thinking about it, incremental "feature creep" does seem like the
> > > best way to go at this late stage in 2.0's life. The problem is how to
> > > guage what is and what is not more trouble than worth. Perhaps adhering
> > > to the kernel's rule of "Separate each logical change into its own patch"
> > > would help to ease the possible impact of larger changes?
> >
> > Probably the best solution.
> 
> Brian, you agree on this? It'll mean splitting up the cache patch...
Would be curious how it would be chunked up...
patch of the new subsystem, patch of portage.py modifications?

Depends on def. of logical changes I guess; in the case of the cache 
patch, it's kind of all or none with the changes.
Suggestions/preferences?

> I'm not much for the ChangeLog at all really. At least not without going over 
> what makes a good commit message and setting up some guidelines. I'm 
> definitely for any ChangeLog being autogenerated though.
No ChangeLog will piss off users; dev's already poke about it on each 
release.

So... guideliness. ?
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Jason Stubbs]

On Saturday 22 October 2005 10:08, Brian Harring wrote:
> On Sat, Oct 22, 2005 at 12:14:40AM +0900, Jason Stubbs wrote:
> > On Friday 21 October 2005 19:06, Marius Mauch wrote:
> > > Jason Stubbs wrote:
> > > > After thinking about it, incremental "feature creep" does seem like
> > > > the best way to go at this late stage in 2.0's life. The problem is
> > > > how to guage what is and what is not more trouble than worth. Perhaps
> > > > adhering to the kernel's rule of "Separate each logical change into
> > > > its own patch" would help to ease the possible impact of larger
> > > > changes?
> > >
> > > Probably the best solution.
> >
> > Brian, you agree on this? It'll mean splitting up the cache patch...
>
> Would be curious how it would be chunked up...
> patch of the new subsystem, patch of portage.py modifications?
>
> Depends on def. of logical changes I guess; in the case of the cache
> patch, it's kind of all or none with the changes.
> Suggestions/preferences?

Something like:
* Add base class(es) for new cache framework
* Add cache backend for XYZ database
* Switch portdbapi to the new framework
* Remove old framework

> > I'm not much for the ChangeLog at all really. At least not without going
> > over what makes a good commit message and setting up some guidelines. I'm
> > definitely for any ChangeLog being autogenerated though.
>
> No ChangeLog will piss off users; dev's already poke about it on each
> release.

Nothing at all will(/has) piss(ed) of users. I can't see people not being 
happy with a concise set of major changes though. I don't mind much either 
way.

> So... guideliness. ?

Should start a new thread about it later. I'd like to get this one finalized 
first. :)

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

On Sat, Oct 22, 2005 at 12:13:42PM +0900, Jason Stubbs wrote:
> Something like:
> * Add base class(es) for new cache framework
> * Add cache backend for XYZ database
> * Switch portdbapi to the new framework
> * Remove old framework
eclass_cache.py chunking (portage.py removal)
cache replacement (base + implementations)
portage.py (dbapi), emerge changes (integration of new cache).
removal patch

That said... would be curious about suggestions on how to do this 
sanely.  Chunking the beast up (patch jockeying) after the fact I can 
do, but in instances like this... it's not easy to chunk it down into 
features/tweaks.  Basically is big ass blobs of "new stuff", 
"conversion to new stuff", "remove old stuff".

Even with that... still is tricky.

Offhand, the existing cache patch could be reduced pretty heavily by 
breaking it down into addition, and removal of old cache.

Obviously after review ability, but also would note the further down 
you push the required granularity of the patches, the harder it is to 
have a big picture view of the patchset changes (imo).


> > So... guideliness. ?
> 
> Should start a new thread about it later. I'd like to get this one finalized 
> first. :)
Personally, I'm kind of inclined to just have people state stuff.
a commit message of "fixed shit" doesn't really cover it, obviously, 
but I'd say what's been coming in on the portage-commits alias as of 
late covers it (both 3.0 and 2.0 commit messages)

Seperate discussion maybe, but kind of think of it as a no-brainer :)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Jason Stubbs]

On Saturday 22 October 2005 12:30, Brian Harring wrote:
> On Sat, Oct 22, 2005 at 12:13:42PM +0900, Jason Stubbs wrote:
> > Something like:
> > * Add base class(es) for new cache framework
> > * Add cache backend for XYZ database
> > * Switch portdbapi to the new framework
> > * Remove old framework
>
> eclass_cache.py chunking (portage.py removal)
> cache replacement (base + implementations)
> portage.py (dbapi), emerge changes (integration of new cache).
> removal patch
>
> That said... would be curious about suggestions on how to do this
> sanely.  Chunking the beast up (patch jockeying) after the fact I can
> do, but in instances like this... it's not easy to chunk it down into
> features/tweaks.  Basically is big ass blobs of "new stuff",
> "conversion to new stuff", "remove old stuff".
>
> Even with that... still is tricky.
>
> Offhand, the existing cache patch could be reduced pretty heavily by
> breaking it down into addition, and removal of old cache.

Heh.. You're rambling a bit here. Addition, conversion, removal is pretty much 
what my list is above. The only difference being that the individual backends 
are separated out as well.

The most important thing in the case of this patch-set is that it can be 
easily seen how the new framework works and how existing code changes to 
accomodate it. The removal of the old stuff and the reworked backends are 
really auxillary.

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Sat, Oct 22, 2005 at 09:25:49PM +0900, Jason Stubbs wrote:
> On Saturday 22 October 2005 12:30, Brian Harring wrote:
> > On Sat, Oct 22, 2005 at 12:13:42PM +0900, Jason Stubbs wrote:
> > > Something like:
> > > * Add base class(es) for new cache framework
> > > * Add cache backend for XYZ database
> > > * Switch portdbapi to the new framework
> > > * Remove old framework
> >
> > eclass_cache.py chunking (portage.py removal)
> > cache replacement (base + implementations)
> > portage.py (dbapi), emerge changes (integration of new cache).
> > removal patch
> >
> > That said... would be curious about suggestions on how to do this
> > sanely.  Chunking the beast up (patch jockeying) after the fact I can
> > do, but in instances like this... it's not easy to chunk it down into
> > features/tweaks.  Basically is big ass blobs of "new stuff",
> > "conversion to new stuff", "remove old stuff".
> >
> > Even with that... still is tricky.
> >
> > Offhand, the existing cache patch could be reduced pretty heavily by
> > breaking it down into addition, and removal of old cache.
> 
> Heh.. You're rambling a bit here. Addition, conversion, removal is pretty much 
> what my list is above. The only difference being that the individual backends 
> are separated out as well.
At least I'm not arguing with myself... ;)

> The most important thing in the case of this patch-set is that it can be 
> easily seen how the new framework works and how existing code changes to 
> accomodate it. The removal of the old stuff and the reworked backends are 
> really auxillary.
Yah.  Will chunk up the patch today/tonight and repost.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Sat, 22 Oct 2005 00:14:40 +0900
Jason Stubbs <jstubbs@gentoo.org> wrote:

> The cheapness is exactly why I was questioning. Consider:
> 
> # svn cp tags/2.0.53 branches/2.0.53-branch
> # cd branches/2.0.53-branch
> # patch < something-that-needs-fixing-now.patch
> # svn ci
> # cd ../..
> # svn cp branches/2.0.53-branch tags/2.0.53-r1
> # svn rm branches/2.0.53-branch
> # svn ci

The last fives steps are easier to do:
# svn ci # could even omit this, but that's bad practice
# svn mv . ../../tags/2.0.53-something
# cd ../..
# svn ci

> compared to:
> 
> # svn cp tags/2.0.53 tags/2.0.53-r1
> # cd tags/2.0.53-r1
> # patch < something-that-needs-fixing-now.patch
> # svn ci
> 
> With the way subversion works, I would have thought the end result
> would be identical...

It is, but the concept of a tag in vcs (as I understand it) is that
it's immutable, and branches are the mutable counterpart. Technically
it doesn't matter to svn.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Fri, Oct 21, 2005 at 01:06:07PM +0300, Marius Mauch wrote:
> the branch is finished make a tag. Btw, anyone object to swap 
> branches/2.0 with trunk (seeing that 2.1 is dead)?
Would be nice, yah.

> >Another "by the way", `svn -v log > ChangeLog` for 2.0.53_rc6. I'm open to 
> >anything better if anybody has a good format for autogeneration. The 
> >quality of the commit messages themselves isn't really useful though 
> >without knowing their context, so this might be a bit of a catch 22.. For 
> >2.0.54, viewsvn should be available so it might be better to just use the 
> >tracker bug to manually create a summary of notable changes.
> 
> Hmm, so you want to change the ChangeLog into release notes? IMO we 
> should have both (a detailed technical ChangeLog and user friendly 
> release notes).
ChangeLog++

Should just tag in a script for generating a release.  Hand it a 
version, it bails if the branch isn't clean (unknown files), else it 
tags, generates changelog, and tarballs the beast.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Jason Stubbs]

On Friday 21 October 2005 19:06, Marius Mauch wrote:
> Jason Stubbs wrote:
> > After thinking about it, incremental "feature creep" does seem like the
> > best way to go at this late stage in 2.0's life. The problem is how to
> > guage what is and what is not more trouble than worth. Perhaps adhering
> > to the kernel's rule of "Separate each logical change into its own patch"
> > would help to ease the possible impact of larger changes?
>
> Probably the best solution.

So we're all agreed then?

* 2.x will never go beyond 2.0
* New features are considered on a case by case basis
* New features can be integrated whenever they're ready (and we're not 
  stabalizing or the feature doesn't aid stabalizing)
* Major changes need to be split up

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list