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 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: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 pgpba6ECTb66O.pgp Description: PGP signature
Re: [gentoo-portage-dev] The road ahead...
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 pgphy7wrRqnw3.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] pre/post phase hooks for users
On Friday 21 October 2005 10:07, Brian Harring wrote:
> On Fri, Oct 21, 2005 at 08:43:49AM +0900, Jason Stubbs wrote:
> > I don't get why it's "needed" by java ebuilds? Is it a fasttrack to
> > getting unsandboxed root access?
>
> Env var preservation against portage stomp of the vars. java vars in
> /etc/profile.env automatically stomp the re-loaded env per phase, to
> fix this you need either
>
> A) ebd with it's env saving/restoration
> B1) ebuilds to reset those vars for every phase
> B2) modify 700 ebuilds so they call this new func.
> C1) eclass that defines it's own funcs, src_unpack() { reset_vars;
> jc_src_unpack; } C2) Modify the couple hundred ebuilds that define *any* of
> the phase funcs. C3) Work out the compatibility nightmare when dealing with
> other eclasses D) Add a user feature (bonus for users), and have java
> eclasses abuse it (including warnings), allowing the env fix to be deployed
>without mangling ebuilds, and automatically disabled when the
>executing portage is ebd based.
>
> Granted... I laid it on thick, but D is the cleanest solution that
> solves it now providing a useful user feature, and covering up a major
> issue for java 1.4 -> java 1.5 support ebuild wise, without modifying
> 700 ebuilds.
>
> Clarifying... I have no intention of expanding the phases, this is
> intended to be strictly user hooks, with the exception that java
> eclasses can abuse it right now (no other choice) till 3.0.
> With the java scenario, disabling the env reset (abuse of user hooks)
> works perfectly; under 3.0, they don't _need_ the env reset.
Ok then. :)
--
Jason Stubbs
--
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...
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
