Re: [gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: > On Sat, Apr 15, 2006 at 11:01:56AM +0900, Jason Stubbs wrote: >> On Saturday 15 April 2006 03:31, Brian Harring wrote: >>> cache backend selection (failed import == defaults to sys default) >> This is incorrect. It displays an error message and quits. > Still leaves the other features then (and raises the question that > it's not internally totally standard)... > > Either way, standard for it is preferable (again, prefer failures > myself, but I'm not a normal user)... We could make it an optional feature, for example, users could add -autoadapt to FEATURES if they want portage to exit instead of autoadapt. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEQJzk/ejvha5XGaMRAsk5AJ9nUlpGuLxJHahhtuBqml56kNUg3QCfS+HE jtwyY9k2x8LEUlwN1LbvR4w= =HQd5 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Sat, Apr 15, 2006 at 11:01:56AM +0900, Jason Stubbs wrote: > On Saturday 15 April 2006 03:31, Brian Harring wrote: > > cache backend selection (failed import == defaults to sys default) > > This is incorrect. It displays an error message and quits. Still leaves the other features then (and raises the question that it's not internally totally standard)... Either way, standard for it is preferable (again, prefer failures myself, but I'm not a normal user)... ~harring pgpEc8sZvtMRn.pgp Description: PGP signature
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Saturday 15 April 2006 03:31, Brian Harring wrote: > cache backend selection (failed import == defaults to sys default) This is incorrect. It displays an error message and quits. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
s/ftp/nfs/ in the mail that I just sent. -- Jason Stubbsw -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Saturday 15 April 2006 03:31, Brian Harring wrote: > Sidenote, why is userfetch a feature? That seems like something that > should be userpriv by default to me... It broke somebody's ftp setup. http://bugs.gentoo.org/show_bug.cgi?id=92960 -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Fri, Apr 14, 2006 at 02:10:27PM -0400, Alec Warner wrote: > Brian Harring wrote: > >>it. But it did not work because i had not emerged confcache. I think > >>this check should be stricter, if i want confcache and have > >>FEATURES="confcache" and confcache is not emerged, i think > >>emerge ... should die, not just say "Ok, you said you want it but > >>you don't have it, so i don't use it". What do you think about that? > > > >Precedent is against you in this case...sandbox is the same way > >(notify instead of bailing). > > > >Personally I prefer the "if I told you to do something, bail if you > >can't" approach, but for features portage has usually done the > >opposite. > >~harring > > Meh, past behavior is not really a great excuse here. If the majority > thinks it sucks, then it can always be changed. The "I'm going to help you out" approach is in use in (quick look through) cache backend selection (failed import == defaults to sys default) PORT_LOGDIR ccache distcc sandbox/usersandbox PORTDIR_OVERLAY (disables non existant directories) parallel-fetch (disables if distlocks isn't on) gpg feature Basically... all existing features that are optional disable themselves if they don't work (exemption being strict/stricter/servere, since not applicable to them). What I'm saying is be consistant- I say the existing standard sucks, but going willy/nilly per feature isn't good for users. Sidenote, why is userfetch a feature? That seems like something that should be userpriv by default to me... ~harring pgpEPF8Bvc20f.pgp Description: PGP signature
Re: [gentoo-portage-dev] 2.1 release candidate soon?
Brian Harring wrote: On Fri, Apr 14, 2006 at 05:15:53PM +0200, Philipp Riegger wrote: On Apr 7, 2006, at 5:26 PM, Alec Warner wrote: We have a new cache format, confcache, parallel fetch, etc... The bonus is these features are already mature and relatively old ( a year + as of now ). Reading about confcache i have one question: When i saw, that this feature exists (in make.examples) i activated it. But it did not work because i had not emerged confcache. I think this check should be stricter, if i want confcache and have FEATURES="confcache" and confcache is not emerged, i think emerge ... should die, not just say "Ok, you said you want it but you don't have it, so i don't use it". What do you think about that? Precedent is against you in this case...sandbox is the same way (notify instead of bailing). Personally I prefer the "if I told you to do something, bail if you can't" approach, but for features portage has usually done the opposite. ~harring Meh, past behavior is not really a great excuse here. If the majority thinks it sucks, then it can always be changed. -Alec -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Fri, Apr 14, 2006 at 05:15:53PM +0200, Philipp Riegger wrote: > On Apr 7, 2006, at 5:26 PM, Alec Warner wrote: > > >We have a new cache format, confcache, parallel fetch, etc... The > >bonus > >is these features are already mature and relatively old ( a year + > >as of > >now ). > > Reading about confcache i have one question: > > When i saw, that this feature exists (in make.examples) i activated > it. But it did not work because i had not emerged confcache. I think > this check should be stricter, if i want confcache and have > FEATURES="confcache" and confcache is not emerged, i think > emerge ... should die, not just say "Ok, you said you want it but > you don't have it, so i don't use it". What do you think about that? Precedent is against you in this case...sandbox is the same way (notify instead of bailing). Personally I prefer the "if I told you to do something, bail if you can't" approach, but for features portage has usually done the opposite. ~harring pgpZNDBdMy8pf.pgp Description: PGP signature
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Apr 7, 2006, at 5:26 PM, Alec Warner wrote: We have a new cache format, confcache, parallel fetch, etc... The bonus is these features are already mature and relatively old ( a year + as of now ). Reading about confcache i have one question: When i saw, that this feature exists (in make.examples) i activated it. But it did not work because i had not emerged confcache. I think this check should be stricter, if i want confcache and have FEATURES="confcache" and confcache is not emerged, i think emerge ... should die, not just say "Ok, you said you want it but you don't have it, so i don't use it". What do you think about that? Philipp -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Saturday 08 April 2006 21:48, Ned Ludd wrote:
> On Sat, 2006-04-08 at 11:18 +0900, Jason Stubbs wrote:
> > On Saturday 08 April 2006 07:36, Ned Ludd wrote:
> > > On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
> > > > FEATURES="buildpkg" ROOT=/ emerge gcc
> > > > rm -rf /dev/shm/foo
> > > >
> > > > ROOT=/dev/shm/foo emerge gcc -pvK
> > > >
> > > > Notice how it selects the incorrect deps?
> > > > IE: eselect cuz it's the first listed dep in the || ( ) vs the
> > > > gcc-config
> > >
> > > + When you already have a copy of gcc-config installed on / and in
> > > .tbz2 format in ${PKGDIR}/All and no eselect anywhere.
> >
> > This should work. I believed I had fixed it by adding the use_binaries
> > parameter and code paths to dep_zapdeps. If it's not working then there must
> > be a bug left somewhere.
>
> Must be a bug left somewhere then. I just tested with
> Portage 2.1_pre7-r4 and the result is the same.
Got it. The bug was in bindbapi. For consistency's sake, I changed most of the
db["/"] to db[myroot] except where db["/"] is specifically required. However,
db[myroot]["bintree"].dbapi.* were all working with an empty repository as
bintree holds all the data and uses lazy initialization which bindbapi wasn't
triggering.
I've fixed the current use case and covered aux_get as well, but this bug could
easily come back if another method of bindbapi is used.
> > Having a quick look at the dep_zapdeps function, I can't see what but I
> > think
> > I've discovered another bug. If use_binaries is true, porttree isn't checked
> > for matches which means that it'll fall through to the "last resort" code
> > when there's no matching binaries which could end up selecting an atom that
> > only has masked porttree matches.
>
> yikes.
This is and isn't the case. use_binaries is only enabled with -K so masking
doesn't take affect anyway.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Sat, 2006-04-08 at 11:18 +0900, Jason Stubbs wrote:
> On Saturday 08 April 2006 07:36, Ned Ludd wrote:
> > On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
> > > FEATURES="buildpkg" ROOT=/ emerge gcc
> > > rm -rf /dev/shm/foo
> > >
> > > ROOT=/dev/shm/foo emerge gcc -pvK
> > >
> > > Notice how it selects the incorrect deps?
> > > IE: eselect cuz it's the first listed dep in the || ( ) vs the
> > > gcc-config
> >
> > + When you already have a copy of gcc-config installed on / and in
> > .tbz2 format in ${PKGDIR}/All and no eselect anywhere.
>
> This should work. I believed I had fixed it by adding the use_binaries
> parameter and code paths to dep_zapdeps. If it's not working then there must
> be a bug left somewhere.
Must be a bug left somewhere then. I just tested with
Portage 2.1_pre7-r4 and the result is the same.
> Having a quick look at the dep_zapdeps function, I can't see what but I think
> I've discovered another bug. If use_binaries is true, porttree isn't checked
> for matches which means that it'll fall through to the "last resort" code
> when there's no matching binaries which could end up selecting an atom that
> only has masked porttree matches.
yikes.
> Hmm, there could be a problem the other way too. If there is a binary package
> of a masked package and -k (rather than -K) is used, the binary package might
> still be chosen. Either way, I'll do some tests and figure out what's not
> working.
Thanks I/we* appreciate that Jason. If you want me to attempt to file
a bug for this I can try but I probably wont do it justice.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Fri, 2006-04-07 at 18:39 -0700, Zac Medico wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ned Ludd wrote: > > If this has been repeated elsewhere than sorry for the re-post. > > > > The resolver still needs a bit of work before it's ready. > > > > Handling of the || () in ROOT!=/ via the -K option is not in that > > good of shape in 2.1_NXX and can't really be used. Till that's > > addressed 2.1(re-ping jason) in my eyes absolutely should > > not even be considered for any rc status. > > Well, please file a bug then. How are we supposed to fix bugs that we aren't > aware of? :) Everytime somebody mentions || () I make little comments about it not working properly. Seriously however. When it comes to our resolver I'm scared like a like a preacher boy in a chruch where spanky is the preacher. I don't know how to file it, and properly describe the problem. Where the root problem lies etc.. The resolver scares me and I'd just assume pass on what I know to those who do understand the resolver for further investigation. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
Zac Medico wrote: > Well, please file a bug then. How are we supposed to fix bugs that we aren't > aware of? :) With the portage regression test suite, of course. =) Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Saturday 08 April 2006 07:36, Ned Ludd wrote:
> On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
> > FEATURES="buildpkg" ROOT=/ emerge gcc
> > rm -rf /dev/shm/foo
> >
> > ROOT=/dev/shm/foo emerge gcc -pvK
> >
> > Notice how it selects the incorrect deps?
> > IE: eselect cuz it's the first listed dep in the || ( ) vs the
> > gcc-config
>
> + When you already have a copy of gcc-config installed on / and in
> .tbz2 format in ${PKGDIR}/All and no eselect anywhere.
This should work. I believed I had fixed it by adding the use_binaries
parameter and code paths to dep_zapdeps. If it's not working then there must
be a bug left somewhere.
Having a quick look at the dep_zapdeps function, I can't see what but I think
I've discovered another bug. If use_binaries is true, porttree isn't checked
for matches which means that it'll fall through to the "last resort" code
when there's no matching binaries which could end up selecting an atom that
only has masked porttree matches.
Hmm, there could be a problem the other way too. If there is a binary package
of a masked package and -k (rather than -K) is used, the binary package might
still be chosen. Either way, I'll do some tests and figure out what's not
working.
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Ludd wrote: > If this has been repeated elsewhere than sorry for the re-post. > > The resolver still needs a bit of work before it's ready. > > Handling of the || () in ROOT!=/ via the -K option is not in that > good of shape in 2.1_NXX and can't really be used. Till that's > addressed 2.1(re-ping jason) in my eyes absolutely should > not even be considered for any rc status. Well, please file a bug then. How are we supposed to fix bugs that we aren't aware of? :) Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENxRG/ejvha5XGaMRApyAAJ44feaq6ffajWN0aVYqMZud9DDFmQCglHpP wwVlQI1KxYr9CREv1K6v1Wg= =UmQq -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Fri, 2006-04-07 at 14:19 -0400, solar wrote:
> On Fri, 2006-04-07 at 21:06 +0900, Jason Stubbs wrote:
> > On Friday 07 April 2006 20:54, Ned Ludd wrote:
> > > Handling of the || () in ROOT!=/ via the -K option is not in that
> > > good of shape in 2.1_NXX and can't really be used. Till that's
> > > addressed 2.1(re-ping jason) in my eyes absolutely should
> > > not even be considered for any rc status.
> >
> > Can you refresh my memory on what the issue is here?
>
> Example off the top of my head:
>
> FEATURES="buildpkg" ROOT=/ emerge gcc
> rm -rf /dev/shm/foo
>
> ROOT=/dev/shm/foo emerge gcc -pvK
>
> Notice how it selects the incorrect deps?
> IE: eselect cuz it's the first listed dep in the || ( ) vs the
> gcc-config
+ When you already have a copy of gcc-config installed on / and in
.tbz2 format in ${PKGDIR}/All and no eselect anywhere.
Depstring: || ( app-admin/eselect-compiler
>=sys-devel/gcc-config-1.3.12-r4 ) ...
Candidates: ['app-admin/eselect-compiler', '>=sys-libs/ncurses-5.2-r2']
Then compare with
ROOT=/dev/shm/foo emerge -pvk gcc
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: > See my problem is that some of the features proposed aren't "two month" > testing features. Particularly when you rewrite decent portions of the > application you need longer than two months to get decent testing > coverage. Sure Unit Tests are helpful for that too, but they don't > cover all cases and really the best testing platform is to let the > people who play with portage do the testing and get some real results > prior to release. Sure, it's possible that a "two month" release cycle might not be possible to achieve in some cases due to the nature of the changes that have occurred. However, that's not to say that it's never possible. Furthermore, we can be selective about the changes that are integrated during a particular release cycle, and changes that require disproportionate amounts of testing can be bumped from the current release cycle (for later integration, at a time that does not interfere with the release of well tested features). Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENt9n/ejvha5XGaMRAhY6AJ4nMLOkpQ+lmjpoEGPHJlgPjJXQoACg4REK lXvWWC3BLk/ttplyCd2BjDg= =xk4t -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Fri, 2006-04-07 at 21:06 +0900, Jason Stubbs wrote: > On Friday 07 April 2006 20:54, Ned Ludd wrote: > > Handling of the || () in ROOT!=/ via the -K option is not in that > > good of shape in 2.1_NXX and can't really be used. Till that's > > addressed 2.1(re-ping jason) in my eyes absolutely should > > not even be considered for any rc status. > > Can you refresh my memory on what the issue is here? Example off the topof my head: FEATURES="buildpkg" ROOT=/ emerge gcc rm -rf /dev/shm/foo ROOT=/dev/shm/foo emerge gcc -pvK Notice how it selects the incorrect deps? IE: eselect cuz it's the first listed dep in the || ( ) vs the gcc-config I forget what the title of the subject was but I recall us talking about it a bit on the portage alias a month or two ago and you more or less stated it's not broken at this point it's just not been coded to handle such cases yet. Other ppl who do alot of work with either || () / $ROOT such as Donnie or Alec should also be able to give some insights also. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
Zac Medico wrote: > > > This kind of thing will be less of a problem if we shorten the period of the > release cycle. If we shorted it to 2 months or so, then it won't matter much > when something gets bumped to the next cycle. > > >>>Also this isn't exactly news to you all as I sent my intentions already >>>a while ago, and last I asked you all agreed with them, so is there any >>>reason to rush this now? > > > Like I've said above, I'm annoyed by the length of this release cycle. The > gap between 2.0.x and 2.1 has grown so large that a 2.0.55 release seems (in > my mind) like beating a dead horse. The way I see it, a shorter release > cycle is needed so that bug fixes are released in _stable_ versions sooner. > > Zac See my problem is that some of the features proposed aren't "two month" testing features. Particularly when you rewrite decent portions of the application you need longer than two months to get decent testing coverage. Sure Unit Tests are helpful for that too, but they don't cover all cases and really the best testing platform is to let the people who play with portage do the testing and get some real results prior to release. The great thing about 2.1 is that *everyone* uses it. Of course they use it because it's better, which may not necessary be the case for future versions. We have a new cache format, confcache, parallel fetch, etc... The bonus is these features are already mature and relatively old ( a year + as of now ). -Alec -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Friday 07 April 2006 20:54, Ned Ludd wrote: > Handling of the || () in ROOT!=/ via the -K option is not in that > good of shape in 2.1_NXX and can't really be used. Till that's > addressed 2.1(re-ping jason) in my eyes absolutely should > not even be considered for any rc status. Can you refresh my memory on what the issue is here? -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Thu, 2006-04-06 at 13:13 -0700, Zac Medico wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everyone, > > I think the current quality level of the 2.1 branch is good enough to make it > a release candidate. From my perspective, it seems like a waste of > everyone's time to roll a 2.0.55 release when 2.1 is a perfectly good > replacement (with lots of bug fixes relative to 2.0.54). > > I know there are probably some additional features that people would like to > get into 2.1 before we make this transition. Despite this, I think that it's > in everyone's best interest to retire the the 2.0.x branch as soon as > possible so that it doesn't waste people's time. This transition doesn't > necessarily mean that it's going to be "a long time" before some desired > feature X is available in the stable version of portage. The next release > after 2.1 (2.2 or whatever) doesn't necessarily have to be too far off in the > future. > > So, I'd like to create 2.1 branch that is closed to mostly anything except > regression fixes and release it as portage-2.1_rc1 this Saturday. We can > continue to do ~arch releases of the development branch (2.2 or whatever it > becomes) every 2 weeks. Does now seem like a good time for this transition? > Your feedback would be appreciated. If this has been repeated elsewhere than sorry for the re-post. The resolver still needs a bit of work before it's ready. Handling of the || () in ROOT!=/ via the -K option is not in that good of shape in 2.1_NXX and can't really be used. Till that's addressed 2.1(re-ping jason) in my eyes absolutely should not even be considered for any rc status. Other than that I'm quite pleased with many aspects of 2.1 -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [Fwd: Re: [gentoo-portage-dev] 2.1 release candidate soon?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: > Vapier in particular has backported some changes into the 2.0.54 tree > with I assume hopes to make a 2.0.55 release. The 2.1 release is a > large change over the 2.0 series, I'd like to give people a bit more > time on 2.0. For a while this may mean 2.0 and 2.1 stable at the same > time, although there is no harm in that either. We haven't had a new > 2.0 release in a while, and there are features worth backporting IMHO. > > Remember that while most of the development community runs portage-2.1 > many of the users do not; and they have not seen a 2.0 release in some > time. I think we can stable 2.0.55 faster than 2.1, as 2.1 will > probably need a series of _rc releases before being considered stable. Maybe 2.0.55 can be stabled slightly faster. But is it really worth anyones time, even to keyword it? Not it my mind. As the gap widens between 2.0.54 and 2.1, the value of a 2.0.55 release diminishes accordingly. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENgwq/ejvha5XGaMRApvTAKDDr2QLizhvrgouTcf8UBidfnhsvQCgvWKC XFW64BXfCDTw2aPe2usj2eE= =N5au -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > On Thu, 06 Apr 2006 19:11:49 -0700 > Zac Medico <[EMAIL PROTECTED]> wrote: > >> The manifest code doesn't have very many use cases so I'd expect that >> we would have hit most major problems by now (even with a small >> sample). Any necessary changes are likely to be small patches. As >> an alternative, we can cut the 2.1 branch at the point before >> manifest2 was merged (2.1_pre7, essentially). > > Releasing 2.1 without manifest2 is a no go, it would significantly > delay the deployment and transition.I'm not requesting to delay 2.1 > for another few months, just one more pre release so people get a > chance to test it for one or two weeks. Well, 2 weeks isn't so bad. I'm just annoyed by the length of this release cycle and would prefer shorter release cycles in the future. >>> The remaining feature I'd like to get into 2.1 is the >>> tree-format-check issue, but that could probably be slipped in in >>> the rc phase (don't really like that idea, but it's an option). >> I don't want to rush the development of new features such as >> manifest2 or the tree-format-check. We have a 2.1 branch that, in >> it's current state (2.1_pre7-r4, for example), provides significant >> benefits over the 2.0.x branch. By delaying 2.1's release for the >> addition of _new_ features, we run the risk of the release being >> delayed indefinitely by "just one more feature" syndrome. >> Personally, I'd rather have shorter release periods so that "just one >> more feature" syndrome becomes less of an issue. > > Ehm, this is not "just one more feature", both manifest2 and > the tree-format-check are things to improve forward compability (or for > the latter even enable forward compability at all), so delaying them > will hinder future development, not only for us. This kind of thing will be less of a problem if we shorten the period of the release cycle. If we shorted it to 2 months or so, then it won't matter much when something gets bumped to the next cycle. > Also this isn't exactly news to you all as I sent my intentions already > a while ago, and last I asked you all agreed with them, so is there any > reason to rush this now? Like I've said above, I'm annoyed by the length of this release cycle. The gap between 2.0.x and 2.1 has grown so large that a 2.0.55 release seems (in my mind) like beating a dead horse. The way I see it, a shorter release cycle is needed so that bug fixes are released in _stable_ versions sooner. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENgiD/ejvha5XGaMRAu2qAKDst/u+JAPsKzthJp519I/01h3/WwCeO3RP jxoDVyn0MeeeMY+6qxq7QQY= =CdiB -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[Fwd: Re: [gentoo-portage-dev] 2.1 release candidate soon?]
Sorry, send with wrong address earlier. Original Message Subject: Re: [gentoo-portage-dev] 2.1 release candidate soon? Date: Thu, 06 Apr 2006 20:09:06 -0400 From: Alec Warner <[EMAIL PROTECTED]> To: gentoo-portage-dev@lists.gentoo.org References: <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Hi everyone, > > I think the current quality level of the 2.1 branch is good enough to > make it a release candidate. From my perspective, it seems like a > waste of everyone's time to roll a 2.0.55 release when 2.1 is a > perfectly good replacement (with lots of bug fixes relative to > 2.0.54). (Pardon if this looks weird, Thunderbird is doing all kinds of weird things to this E-mail) Vapier in particular has backported some changes into the 2.0.54 tree with I assume hopes to make a 2.0.55 release. The 2.1 release is a large change over the 2.0 series, I'd like to give people a bit more time on 2.0. For a while this may mean 2.0 and 2.1 stable at the same time, although there is no harm in that either. We haven't had a new 2.0 release in a while, and there are features worth backporting IMHO. Remember that while most of the development community runs portage-2.1 many of the users do not; and they have not seen a 2.0 release in some time. I think we can stable 2.0.55 faster than 2.1, as 2.1 will probably need a series of _rc releases before being considered stable. -Alec Warner (antarus) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On 4/6/06, Marius Mauch <[EMAIL PROTECTED]> wrote:
> On Thu, 06 Apr 2006 19:11:49 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
> > The manifest code doesn't have very many use cases so I'd expect that
> > we would have hit most major problems by now (even with a small
> > sample). Any necessary changes are likely to be small patches. As
> > an alternative, we can cut the 2.1 branch at the point before
> > manifest2 was merged (2.1_pre7, essentially).
>
> Releasing 2.1 without manifest2 is a no go, it would significantly
> delay the deployment and transition. I'm not requesting to delay 2.1
> for another few months, just one more pre release so people get a
> chance to test it for one or two weeks.
The manifest2 code is still pretty raw from where I'm sitting and has
a few design problems.
Offhand,
1) usage of settings sucks (awareness of PORTAGE_ACTUAL_DISTDIR is an
indication right there that distdir should be passed in rather then
manifest code knowing of settings). Throwing around a big ole dict of
settings while easy, isn't exactly encapsulated/seperated all that
well (thus making any changes to config class that much more of a
mess).
2) triggering __init__ within create is pretty dodgy and definitely a
"wtf" trick
3) usual loading everything into memory rather then iterating over
objects (file objects in particular)
4) incomplete class; notably the sign chunks.
5) lack of protection in digest parsing; flipping through it, any
old/deviate from the norm digest's generated (say files//blah) the
code doesn't protect itself against.
6) impenetrable code.
This should be simple/easily grokable code- as is, I don't think it is.
fex.
cpvlist = [os.path.join(self.pkgdir.rstrip(os.sep).split(os.sep)[-2],
x[:-7]) for x in \
portage.listdir(self.pkgdir) if x.endswith(".ebuild")]
I'm not in front of a gentoo box right now, and the best I can figure
that code is doing is pulling the ebuild name and joining the ebuild
name + version to it- and I'm pretty sure that's not a correct
interpretation of it.
The code should be _readable_ by folks, fhashdict (fex) should have an
explanation in __init__ explaining it's structure. Else folks are
stuck popping open the interpretter, and inspecting the object to
figure out what the code sets it to- which sucks because if you have
to inspect the implementation to determine it's intentions, finding
bugs in the implementation is that much harder.
Realistially, tend to think the code would be cleaner/more readable if
split into manifest1 and manifest2 classes. Combine then via a
derivative class instead of making manifest2 code (which will live on)
nastier to read.
Aside from that, my usual rant about creating uneccessary lists, using
.keys() when should just be iterating over the dict all apply for this
code, in general efficient code (usually resulting in less lines)
applies.
Honestly? Main issue I have with the code is that while the previous
digest/manifest code was icky, it was at least known to be stable via
live testing/usage by users/devs (for better or worse). The new code,
while containing most functionality in one spot is roughly just as
dense/opaque in trying to eyeball, but it lacks a year+ of being in
actual testing. That combination right there makes it harder to view
as "good to go".
/me notes also that he applies same criteria to what he has in the
past tried to push into portage; beyond features/bug fixes, whats the
cost in terms of maintenance? Will someone else be able to actually
grok this code without having to use pdb or liter it with print
statements?
Not intending to be an ass about the code, just think it needs to be
simpler then it is. Effectively it's just marshalling code (yes it
triggers chksum calls, but that's minor); it's not that complex of a
thing and the implementation should reflect that (or at least be
heavily documented if not).
> > > The remaining feature I'd like to get into 2.1 is the
> > > tree-format-check issue, but that could probably be slipped in in
> > > the rc phase (don't really like that idea, but it's an option).
> >
> > I don't want to rush the development of new features such as
> > manifest2 or the tree-format-check. We have a 2.1 branch that, in
> > it's current state (2.1_pre7-r4, for example), provides significant
> > benefits over the 2.0.x branch. By delaying 2.1's release for the
> > addition of _new_ features, we run the risk of the release being
> > delayed indefinitely by "just one more feature" syndrome.
> > Personally, I'd rather have shorter release periods so that "just one
> > more feature" syndrome becomes less of an issue.
>
> Ehm, this is not "just one more feature", both manifest2 and
> the tree-format-check are things to improve forward compability (or for
> the latter even enable forward compability at all), so delaying them
> will hinder future development, not only for us.
> Also this isn't exactly news to you all as I sent my intentions already
> a while ago, and last I asked you a
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Thu, 06 Apr 2006 19:11:49 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > The manifest code doesn't have very many use cases so I'd expect that > we would have hit most major problems by now (even with a small > sample). Any necessary changes are likely to be small patches. As > an alternative, we can cut the 2.1 branch at the point before > manifest2 was merged (2.1_pre7, essentially). Releasing 2.1 without manifest2 is a no go, it would significantly delay the deployment and transition. I'm not requesting to delay 2.1 for another few months, just one more pre release so people get a chance to test it for one or two weeks. > > The remaining feature I'd like to get into 2.1 is the > > tree-format-check issue, but that could probably be slipped in in > > the rc phase (don't really like that idea, but it's an option). > > I don't want to rush the development of new features such as > manifest2 or the tree-format-check. We have a 2.1 branch that, in > it's current state (2.1_pre7-r4, for example), provides significant > benefits over the 2.0.x branch. By delaying 2.1's release for the > addition of _new_ features, we run the risk of the release being > delayed indefinitely by "just one more feature" syndrome. > Personally, I'd rather have shorter release periods so that "just one > more feature" syndrome becomes less of an issue. Ehm, this is not "just one more feature", both manifest2 and the tree-format-check are things to improve forward compability (or for the latter even enable forward compability at all), so delaying them will hinder future development, not only for us. Also this isn't exactly news to you all as I sent my intentions already a while ago, and last I asked you all agreed with them, so is there any reason to rush this now? Marius -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > On Thu, 06 Apr 2006 13:13:34 -0700 > Zac Medico <[EMAIL PROTECTED]> wrote: > >> So, I'd like to create 2.1 branch that is closed to mostly anything >> except regression fixes and release it as portage-2.1_rc1 this >> Saturday. We can continue to do ~arch releases of the development >> branch (2.2 or whatever it becomes) every 2 weeks. Does now seem >> like a good time for this transition? Your feedback would be >> appreciated. > > I'd like to hold off with the rc status until the manifest2 code got > some public testing first in another pre release. I don't feel > comfortable labeling 2.1 as "basically release ready" when only a dozen > people have tested something that critical. The manifest code doesn't have very many use cases so I'd expect that we would have hit most major problems by now (even with a small sample). Any necessary changes are likely to be small patches. As an alternative, we can cut the 2.1 branch at the point before manifest2 was merged (2.1_pre7, essentially). > The remaining feature I'd like to get into 2.1 is the tree-format-check > issue, but that could probably be slipped in in the rc phase (don't > really like that idea, but it's an option). I don't want to rush the development of new features such as manifest2 or the tree-format-check. We have a 2.1 branch that, in it's current state (2.1_pre7-r4, for example), provides significant benefits over the 2.0.x branch. By delaying 2.1's release for the addition of _new_ features, we run the risk of the release being delayed indefinitely by "just one more feature" syndrome. Personally, I'd rather have shorter release periods so that "just one more feature" syndrome becomes less of an issue. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENcpj/ejvha5XGaMRAlxzAKDEzo4fq1HtzZtGkhAAjviO+srchQCeN3Rb +30YB9/v9KwohcsgGHYQ7mE= =eHNd -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Thu, 06 Apr 2006 13:13:34 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > So, I'd like to create 2.1 branch that is closed to mostly anything > except regression fixes and release it as portage-2.1_rc1 this > Saturday. We can continue to do ~arch releases of the development > branch (2.2 or whatever it becomes) every 2 weeks. Does now seem > like a good time for this transition? Your feedback would be > appreciated. I'd like to hold off with the rc status until the manifest2 code got some public testing first in another pre release. I don't feel comfortable labeling 2.1 as "basically release ready" when only a dozen people have tested something that critical. The remaining feature I'd like to get into 2.1 is the tree-format-check issue, but that could probably be slipped in in the rc phase (don't really like that idea, but it's an option). Marius -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I think the current quality level of the 2.1 branch is good enough to make it a release candidate. From my perspective, it seems like a waste of everyone's time to roll a 2.0.55 release when 2.1 is a perfectly good replacement (with lots of bug fixes relative to 2.0.54). I know there are probably some additional features that people would like to get into 2.1 before we make this transition. Despite this, I think that it's in everyone's best interest to retire the the 2.0.x branch as soon as possible so that it doesn't waste people's time. This transition doesn't necessarily mean that it's going to be "a long time" before some desired feature X is available in the stable version of portage. The next release after 2.1 (2.2 or whatever) doesn't necessarily have to be too far off in the future. So, I'd like to create 2.1 branch that is closed to mostly anything except regression fixes and release it as portage-2.1_rc1 this Saturday. We can continue to do ~arch releases of the development branch (2.2 or whatever it becomes) every 2 weeks. Does now seem like a good time for this transition? Your feedback would be appreciated. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENXZt/ejvha5XGaMRAqHmAJ0bBUU08XeyWe8vigWuU3228IvpWACg07u5 3Ncnef3STQ4s5t6PqCXviis= =nRr8 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
