Re: [gentoo-portage-dev] The road ahead...
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
Re: [gentoo-portage-dev] The road ahead...
On Sat, 22 Oct 2005 00:14:40 +0900 Jason Stubbs [EMAIL PROTECTED] 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. pgpDct4nhZVNI.pgp Description: PGP signature
Re: [gentoo-portage-dev] The road ahead...
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...
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...
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...
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 pgpyf43LU1KZV.pgp Description: PGP signature
Re: [gentoo-portage-dev] The road ahead...
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 [EMAIL PROTECTED] 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...
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...
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
[gentoo-portage-dev] The road ahead...
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...
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 pgppLGjuUd5pB.pgp Description: PGP signature
