Re: [gentoo-dev] And thanks for all the fish...
On Friday 20 March 2009 09:29:49 Markus Rothe wrote: > Hello, > > it's a classical subject for a classical reason: I don't have time to > contribute work to Gentoo anymore. So please retire me [1]. > > It was fun to work with all of you and it is a great experience to work in > such a big project. > > You can contact me at mar...@unixforces.net. I lately changed my nickname > at freenode from corsair to mrothe. > > Best regards to all of you! And some special regards to the ppc64 team! Bye bye and good luck :) -- Timothy `Drizzt` Redaelli FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson signature.asc Description: This is a digitally signed message part.
[gentoo-dev] perforce client proper license
Hello folks, Qt-creator[1] program can support perforce[2] software configuration manager. My concern is the perforce license. According to their site[3] there is a dual(?) license. There is the standard commercial license[4] and one for free software development[4]. Should I add both? Or am I missing something? Doing some research I found out that perforce-cli was in the portage back in 2006 but not anymore. Can somebody recall the reason why it is not there anymore? If it wasn't a license issue , I want to bring it back ( at least the client for now ). I am waiting your suggestions. Thank you [1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/qt-creator/ [2] http://www.perforce.com/perforce/ [3] http://www.perforce.com/perforce/price.html#license [4] http://www.perforce.com/perforce/price.html#opensource -- Markos Chandras (hwoarang) Gentoo Linux Developer KDE/Qt/Sunrise/Sound Web: http://hwoarang.silverarrow.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] perforce client proper license
On Saturday 21 March 2009, Markos Chandras wrote: > Doing some research I found out that perforce-cli was in the portage > back in 2006 but not anymore. Can somebody recall the reason why it > is not there anymore? If it wasn't a license issue , I want to bring > it back ( at least the client for now ). > I am waiting your suggestions. Thank you Revisiting old bugs, it seems it was removed due to distfile collisions (same name, different content in several perforce packages): https://bugs.gentoo.org/123923 Since we have src_uri arrows now, this is no show-stopper. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] perforce client proper license
On Saturday 21 March 2009 14:50:08 Robert Buchholz wrote: > On Saturday 21 March 2009, Markos Chandras wrote: > > Doing some research I found out that perforce-cli was in the portage > > back in 2006 but not anymore. Can somebody recall the reason why it > > is not there anymore? If it wasn't a license issue , I want to bring > > it back ( at least the client for now ). > > I am waiting your suggestions. Thank you > > Revisiting old bugs, it seems it was removed due to distfile collisions > (same name, different content in several perforce packages): > https://bugs.gentoo.org/123923 > > Since we have src_uri arrows now, this is no show-stopper. > > > Robert Robert, I already used src_uri arrows on that ebuild. The thing is that I don't know how mirrors treat the arrows. Will mirrors save the file using the the normal filename or the one I specified on arrow? If the later, I need to have RESTRICT="nomirror" or something. I took a look on EAPI2 specifications but couldn't find how mirrors behave with arrows. About the licensing issue, i think that the best is to make it dual license cause this is what I get by reading their site over and over again. If there are no objections, this package will be on tree withing the next 48 hours. Thanks - - Markos Chandras (hwoarang) Gentoo Linux Developer KDE/Qt/Sunrise/Sound Web: http://hwoarang.silverarrow.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] perforce client proper license
Markos Chandras wrote: > Hello folks, > > Qt-creator[1] program can support perforce[2] software configuration > manager. > My concern is the perforce license. According to their site[3] there is a > dual(?) license. > There is the standard commercial license[4] and one for free software > development[4]. Should I add both? Or am I missing something? How about a single text file stating the main facts from [3] and [4]? Sebastian > [3] http://www.perforce.com/perforce/price.html#license > [4] http://www.perforce.com/perforce/price.html#opensource
Re: [gentoo-dev] perforce client proper license
On Sat, 21 Mar 2009 15:39:43 +0200
Markos Chandras wrote:
> I took a look on EAPI2 specifications but couldn't find how mirrors
> behave with arrows.
It's supposed to say this:
> In EAPIs supporting arrows, if an arrow is used, the filename used
> when saving to \t{DISTDIR} shall instead be the name on the right of
> the arrow. When consulting mirrors (except for those explicitly
> listed on the left of the arrow, if \t{mirror://} is used), the
> filename to the right of the arrow shall be requested instead of the
> filename in the URI.
But it didn't, thanks to a formatting screwup. I've fixed that now.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] perforce client proper license
On Saturday 21 March 2009 15:46:19 Sebastian Pipping wrote: > Markos Chandras wrote: > > Hello folks, > > > > Qt-creator[1] program can support perforce[2] software configuration > > manager. My concern is the perforce license. According to their site[3] > > there is a dual(?) license. > > There is the standard commercial license[4] and one for free software > > development[4]. Should I add both? Or am I missing something? > > How about a single text file stating the main facts from > [3] and [4]? > > > > Sebastian > > > [3] http://www.perforce.com/perforce/price.html#license > > [4] http://www.perforce.com/perforce/price.html#opensource Sebastian, Why would I want to do that? The license files should stay untouched. There is nothing wrong of having both licenses on ebuild since this is the upstream policy. -- Markos Chandras (hwoarang) Gentoo Linux Developer KDE/Qt/Sunrise/Sound Web: http://hwoarang.silverarrow.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] perforce client proper license
Markos Chandras wrote: > Sebastian, > Why would I want to do that? The license files should stay untouched. > There is > nothing wrong of having both licenses on ebuild since this is the upstream > policy. I forgot that the license files upstream might change so I agree you need a copy downstream. However, if the "End User License Agreement for Open Source Software Development" document alone doesn't say that 1) "Perforce Software reserves the right to approve the Open Source license" (from [4]) and 2) "Execution of a End User License Agreement [..] is required" (from [4]) (which at least I didn't find in the PDF) you will have to add that somewhere somehow because people could otherwise start using then software under that license without being permitted to. Also, please pay extra attention to the difference between the terms "Open Source License" and "Open Source End User License Agreement". Thank you. Sebastian
[gentoo-dev] RFC: Deprecating EAPI0
Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick
Re: [gentoo-dev] perforce client proper license
On Sat, Mar 21, 2009 at 7:11 AM, Ciaran McCreesh
wrote:
> On Sat, 21 Mar 2009 15:39:43 +0200
> Markos Chandras wrote:
>> I took a look on EAPI2 specifications but couldn't find how mirrors
>> behave with arrows.
>
> It's supposed to say this:
>
>> In EAPIs supporting arrows, if an arrow is used, the filename used
>> when saving to \t{DISTDIR} shall instead be the name on the right of
>> the arrow. When consulting mirrors (except for those explicitly
>> listed on the left of the arrow, if \t{mirror://} is used), the
>> filename to the right of the arrow shall be requested instead of the
>> filename in the URI.
>
> But it didn't, thanks to a formatting screwup. I've fixed that now.
I think Markos is talking about the actual mirror-fetch script itself.
The gentoo mirrors still use a flat namespace so someone will need to
update mirror-fetch to rename files based on src_uri arrows. And by
'someone' I mean Zac.
-A
>
> --
> Ciaran McCreesh
>
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, Mar 21, 2009 at 10:37 AM, Patrick Lauer wrote: > Hi all, > > with the discussion about EAPI3 we have now 4 (or 7, depending on how you > count them ;) ) EAPIs available or almost available. This is getting quite > confusing. Be more specific, what actual problems have you encountered? What are some other ways we could mitigate these issues (it seems like tool improvements could be a big one here)? > To make our lives easier I would suggest deprecating EAPI0 and migrating > existing ebuilds over some time to EAPI1 or higher until EAPI0 can be > obsoleted at some point in the future. > I would set the start of deprecation warnings about 3 months from now and the > obsoletion quite a time later, maybe 12 months from now, when a sufficient > amount of ebuilds has been migrated. I am interested in the number of ebuilds at specific APIs in the tree, do you have those numbers? Basically, how much work is this (raw ebuild count)? > > Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to > think about, but since it has some changes like adding src_prepare migration > would not be as trivial. So I'd prefer keeping it around a bit longer. > > Comments? > > > Patrick > >
Re: [gentoo-dev] perforce client proper license
On Saturday 21 March 2009 21:41:39 Alec Warner wrote:
> On Sat, Mar 21, 2009 at 7:11 AM, Ciaran McCreesh
>
> wrote:
> > On Sat, 21 Mar 2009 15:39:43 +0200
> >
> > Markos Chandras wrote:
> >> I took a look on EAPI2 specifications but couldn't find how mirrors
> >> behave with arrows.
> >
> > It's supposed to say this:
> >> In EAPIs supporting arrows, if an arrow is used, the filename used
> >> when saving to \t{DISTDIR} shall instead be the name on the right of
> >> the arrow. When consulting mirrors (except for those explicitly
> >> listed on the left of the arrow, if \t{mirror://} is used), the
> >> filename to the right of the arrow shall be requested instead of the
> >> filename in the URI.
> >
> > But it didn't, thanks to a formatting screwup. I've fixed that now.
>
> I think Markos is talking about the actual mirror-fetch script itself.
> The gentoo mirrors still use a flat namespace so someone will need to
> update mirror-fetch to rename files based on src_uri arrows. And by
> 'someone' I mean Zac.
>
> -A
>
> > --
> > Ciaran McCreesh
Actually I didn't understand completely what Ciaran said. I am still
not
quite sure how mirrors treat the SRC_URI with arrows. Will they fetch the file
from upstream as save it with the filename I specified on arrow or they will
save it respecting the upstream filename? :)
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
KDE/Qt/Sunrise/Sound
Web: http://hwoarang.silverarrow.gr
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Deprecating EAPI0
Alec Warner schrieb am 21.03.2009 20:45: Be more specific, what actual problems have you encountered? What are some other ways we could mitigate these issues (it seems like tool improvements could be a big one here)? Regarding the depreciation of EAPI's I think eclasses will probably benefit from a low number of possible EAPI's. I am thinking about the introduction of more and more EAPI's which all need to be considered in the eclasses which will get tedious. Regards, Daniel
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer wrote: > To make our lives easier I would suggest deprecating EAPI0 and > migrating existing ebuilds over some time to EAPI1 or higher until > EAPI0 can be obsoleted at some point in the future. Uh. Why? Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] pybugz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, if you are following pybugz, we have moved development from google code (which is subversion) to github. The url for the page there is http://www.github.com/ColdWind/pybugz Thanks, - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknFTyQACgkQblQW9DDEZTjxDgCglzxXajjSGUG+6Z5ksJ8FBoKu mOoAoJFUnjdtotMbL0svdC3mkvk3Qje9 =MxtT -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 19:37:12 Patrick Lauer wrote: > Hi all, > > with the discussion about EAPI3 we have now 4 (or 7, depending on how you > count them ;) ) EAPIs available or almost available. This is getting quite > confusing. > To make our lives easier I would suggest deprecating EAPI0 and migrating > existing ebuilds over some time to EAPI1 or higher until EAPI0 can be > obsoleted at some point in the future. > I would set the start of deprecation warnings about 3 months from now and > the obsoletion quite a time later, maybe 12 months from now, when a > sufficient amount of ebuilds has been migrated. > > Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have > to think about, but since it has some changes like adding src_prepare > migration would not be as trivial. So I'd prefer keeping it around a bit > longer. > > Comments? > > > Patrick The gain obtained by this migration doesnt compensate for the efford/work one (we) must put into this. But if we decide to mark EAPI0 as deprecated, first it would be nice to have a tree cleanup cause it doesn't make much sense to migrate broken/unmaintained/old/etc ebuilds onto newer EAPIs. -- Markos Chandras (hwoarang) Gentoo Linux Developer KDE/Qt/Sunrise/Sound Web: http://hwoarang.silverarrow.gr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Deprecating EAPI0
Alec Warner wrote: > I am interested in the number of ebuilds at specific APIs in the tree, > do you have those numbers? > Basically, how much work is this (raw ebuild count)? > Total ebuilds 26209 EAPI0 ebuilds 22880 EAPI1 ebuilds 1855 EAPI2 ebuilds 1474 this numbers based on regexps =) -- Alexey 'Alexxy' Shvetsov Gentoo/KDE Gentoo/MIPS Gentoo/SCI Gentoo Team Ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote: > On Sat, 21 Mar 2009 18:37:12 +0100 > > Patrick Lauer wrote: > > To make our lives easier I would suggest deprecating EAPI0 and > > migrating existing ebuilds over some time to EAPI1 or higher until > > EAPI0 can be obsoleted at some point in the future. > > Uh. Why? Because, as you have noticed before, developers get confused which eapi has which features available. And eapi1 is a superset of eapi0, so we don't have to rewrite tons of things. > Introducing a policy encouraging moving things that definitely aren't > in the least bit likely to be a system dep on a bump, sure. Making 1 or > 2 the default for new packages, sure. But rewriting existing things? > That's just an accident waiting to happen. What kind of accident do you expect to happen? Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 21:53:16 +0100 Patrick Lauer wrote: > Because, as you have noticed before, developers get confused which > eapi has which features available. And eapi1 is a superset of eapi0, > so we don't have to rewrite tons of things. So? When people do new things, they can move the EAPI forward. That's not a reason to modify existing things. > > Introducing a policy encouraging moving things that definitely > > aren't in the least bit likely to be a system dep on a bump, sure. > > Making 1 or 2 the default for new packages, sure. But rewriting > > existing things? That's just an accident waiting to happen. > > What kind of accident do you expect to happen? The same kind that always happens when lots of ebuilds get changed. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
Alexey Shvetsov wrote: Alec Warner wrote: I am interested in the number of ebuilds at specific APIs in the tree, do you have those numbers? Basically, how much work is this (raw ebuild count)? Total ebuilds 26209 EAPI0 ebuilds 22880 EAPI1 ebuilds 1855 EAPI2 ebuilds 1474 this numbers based on regexps =) With these numbers, I don't exactly see the point of deprecating EAPI0. Too much work that we could be spending elsewhere.. Although, I suppose someone will propose to make the "default EAPI" be 1 instead of 0. I don't see a point for that either. -Jeremy
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote: > On Sat, 21 Mar 2009 21:53:16 +0100 > > Patrick Lauer wrote: > > Because, as you have noticed before, developers get confused which > > eapi has which features available. And eapi1 is a superset of eapi0, > > so we don't have to rewrite tons of things. > > So? When people do new things, they can move the EAPI forward. That's > not a reason to modify existing things. The added complexity of having a dozen eapis does not offer any benefits to the average developer. Limiting the amount of complexity tends to reduce the amount of errors, be it simple developer mistakes or unexpected interaction errors between different EAPIs in the package manager. > > > Introducing a policy encouraging moving things that definitely > > > aren't in the least bit likely to be a system dep on a bump, sure. > > > Making 1 or 2 the default for new packages, sure. But rewriting > > > existing things? That's just an accident waiting to happen. > > > > What kind of accident do you expect to happen? > > The same kind that always happens when lots of ebuilds get changed. ... lots of new features and a few bugs that get fixed the next day? Hey, that sounds quite bad. And maybe some new herd testers? How rude! So what technical reason(s) do we have to keep archaic EAPIs around forever? Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 22:02:54 +0100 Patrick Lauer wrote: > > So? When people do new things, they can move the EAPI forward. > > That's not a reason to modify existing things. > > The added complexity of having a dozen eapis does not offer any > benefits to the average developer. There is no added complexity. Those things are already there. > > The same kind that always happens when lots of ebuilds get changed. > > ... lots of new features and a few bugs that get fixed the next day? You must be new around here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, Mar 21, 2009 at 2:02 PM, Patrick Lauer wrote: > On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote: >> On Sat, 21 Mar 2009 21:53:16 +0100 >> >> Patrick Lauer wrote: >> > Because, as you have noticed before, developers get confused which >> > eapi has which features available. And eapi1 is a superset of eapi0, >> > so we don't have to rewrite tons of things. >> >> So? When people do new things, they can move the EAPI forward. That's >> not a reason to modify existing things. > > The added complexity of having a dozen eapis does not offer any benefits to > the average developer. Limiting the amount of complexity tends to reduce the > amount of errors, be it simple developer mistakes or unexpected interaction > errors between different EAPIs in the package manager. But you are still talking around the issue. Your logic is that "lots of EAPIs mean its harder to write ebuilds." I buy that argument (complexity implies difficult, no problem!) but it is a very generic argument. What about the complexity of many EAPIs are developers having issues with? What can we do to mitigate these problems? Are people using IUSE_DEFAULTS in EAPI0? Are they not bumping the EAPI when adding src_configure to an ebuild? You claim there are all kinds of problems, I want to hear about them so we can fix the tools (aka repoman) to help point out where developers go wrong so they can fix them. Over 80% of the tree is still EAPI0, so deprecating it seems a bad choice at this time, even for a 12-16 month timeline. > >> > > Introducing a policy encouraging moving things that definitely >> > > aren't in the least bit likely to be a system dep on a bump, sure. >> > > Making 1 or 2 the default for new packages, sure. But rewriting >> > > existing things? That's just an accident waiting to happen. >> > >> > What kind of accident do you expect to happen? >> >> The same kind that always happens when lots of ebuilds get changed. > > ... lots of new features and a few bugs that get fixed the next day? Hey, that > sounds quite bad. And maybe some new herd testers? How rude! I don't see the correlation between EAPI bumps and new herd testers. > > So what technical reason(s) do we have to keep archaic EAPIs around forever? None, luckily this is more than a technical project ;) > > Patrick > >
Re: [gentoo-dev] perforce client proper license
On Sat, Mar 21, 2009 at 12:58 PM, Markos Chandras wrote:
> On Saturday 21 March 2009 21:41:39 Alec Warner wrote:
>> On Sat, Mar 21, 2009 at 7:11 AM, Ciaran McCreesh
>>
>> wrote:
>> > On Sat, 21 Mar 2009 15:39:43 +0200
>> >
>> > Markos Chandras wrote:
>> >> I took a look on EAPI2 specifications but couldn't find how mirrors
>> >> behave with arrows.
>> >
>> > It's supposed to say this:
>> >> In EAPIs supporting arrows, if an arrow is used, the filename used
>> >> when saving to \t{DISTDIR} shall instead be the name on the right of
>> >> the arrow. When consulting mirrors (except for those explicitly
>> >> listed on the left of the arrow, if \t{mirror://} is used), the
>> >> filename to the right of the arrow shall be requested instead of the
>> >> filename in the URI.
>> >
>> > But it didn't, thanks to a formatting screwup. I've fixed that now.
>>
>> I think Markos is talking about the actual mirror-fetch script itself.
>> The gentoo mirrors still use a flat namespace so someone will need to
>> update mirror-fetch to rename files based on src_uri arrows. And by
>> 'someone' I mean Zac.
>>
>> -A
>>
>> > --
>> > Ciaran McCreesh
>Actually I didn't understand completely what Ciaran said. I am still
> not
> quite sure how mirrors treat the SRC_URI with arrows. Will they fetch the file
> from upstream as save it with the filename I specified on arrow or they will
> save it respecting the upstream filename? :)
I think you will encounter namespace collisions, thats why I CC'd zac
as he maintains mirror-dist ;p
> --
> Markos Chandras (hwoarang)
> Gentoo Linux Developer
> KDE/Qt/Sunrise/Sound
> Web: http://hwoarang.silverarrow.gr
>
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer wrote: > To make our lives easier I would suggest deprecating EAPI0 and > migrating existing ebuilds over some time to EAPI1 or higher until > EAPI0 can be obsoleted at some point in the future. > I would set the start of deprecation warnings about 3 months from now > and the obsoletion quite a time later, maybe 12 months from now, when > a sufficient amount of ebuilds has been migrated. As always, wording is important. I think having too many EAPIs in active use unnecessarily complicates things, such as remembering which features are offered by which EAPIs, etc. I think we should start deprecating EAPI=0 usage *now* with a repoman warning whenever a new ebuild is committed that does not use EAPI=1 or EAPI=2. This warning should encourage use of the newest EAPI, EAPI=2. Obsoleting EAPI=0 should occur when the decision to do so merely codifies the state of the tree (at 90% EAPI>0, to pick a number ), at which point the warning would be changed to an error. We could then use a couple of bugdays to convert the remainder of the ebuilds or hand them over to treecleaners if it's just unmaintained cruft. In a year or so, we could change the repoman warning to trigger with EAPI=1 also and make it point to EAPI=3 as the EAPI-of-choice. > Deprecating EAPI1 at the same time would reduce the amount of EAPIs > we have to think about, but since it has some changes like adding > src_prepare migration would not be as trivial. So I'd prefer keeping > it around a bit longer. > > Comments? We need to make this a part of the EAPI-upgrade process that whenever a new EAPI is added, we consider including another EAPI in the repoman warning. My hope is that at some point in the future (4 years?), we'll be able to cut out some of the ugly phase hacks we have in many eclasses that had EAPI=2 grafted onto them. /loki_val
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 22:26:41 Alec Warner wrote: > >> > > Introducing a policy encouraging moving things that definitely > >> > > aren't in the least bit likely to be a system dep on a bump, sure. > >> > > Making 1 or 2 the default for new packages, sure. But rewriting > >> > > existing things? That's just an accident waiting to happen. > >> > > >> > What kind of accident do you expect to happen? > >> > >> The same kind that always happens when lots of ebuilds get changed. > > > > ... lots of new features and a few bugs that get fixed the next day? Hey, > > that sounds quite bad. And maybe some new herd testers? How rude! > > I don't see the correlation between EAPI bumps and new herd testers. Well, ciaran said that the same thing happens that always happens when lots of ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice herd testers plus a new dev or two, so I am confused too. Maybe ciaran can explain what he meant to say so we don't have to come to unexpected conclusions (that would actually be a quite nice change to the average discussion - saying what you mean instead of hinting at star constellations and the importance of meat loaf) > > So what technical reason(s) do we have to keep archaic EAPIs around > > forever? > None, luckily this is more than a technical project ;) Stop confusing me, antarus, I thought you were against removing eapi0 and now you support the removal? ;) Anyway. Most of the "porting" effort (assuming no other issues sneaking in) would be adding a "EAPI=1" line to ebuilds, which could be done "lazily" on version bumps. There's no rush to get it killed now now now, but in a year we might be at EAPI 5, and then I don't want to be the one writing the docs that split apart what features are where and what syntax is valid and all that. So phasing out eapi0 would be an obvious step towards making things simpler for those of us that don't enjoy studying lists and tables ... Patrick
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 22:51:11 +0100 Patrick Lauer wrote: > > >> The same kind that always happens when lots of ebuilds get > > >> changed. > > > > > > ... lots of new features and a few bugs that get fixed the next > > > day? Hey, that sounds quite bad. And maybe some new herd testers? > > > How rude! > > > > I don't see the correlation between EAPI bumps and new herd testers. > > Well, ciaran said that the same thing happens that always happens > when lots of ebuilds get changed. Last time I saw that happen (think > KDE4) we got some nice herd testers plus a new dev or two, so I am > confused too. And a massive amount of breakage, some of which still isn't fixed, yes. Have a look at bugzilla sometime. > Anyway. Most of the "porting" effort (assuming no other issues > sneaking in) would be adding a "EAPI=1" line to ebuilds, which could > be done "lazily" on version bumps. There's no rush to get it killed > now now now, but in a year we might be at EAPI 5, and then I don't > want to be the one writing the docs that split apart what features > are where and what syntax is valid and all that. Fortunately, you won't be. As the person who probably will be, I can assure you that killing off EAPI 0 won't help in the slightest. It won't mean we can remove all mention of EAPI 0 from the documentation, since package managers need to support EAPIs indefinitely for uninstalls. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, Mar 21, 2009 at 2:51 PM, Patrick Lauer wrote: > On Saturday 21 March 2009 22:26:41 Alec Warner wrote: >> >> > > Introducing a policy encouraging moving things that definitely >> >> > > aren't in the least bit likely to be a system dep on a bump, sure. >> >> > > Making 1 or 2 the default for new packages, sure. But rewriting >> >> > > existing things? That's just an accident waiting to happen. >> >> > >> >> > What kind of accident do you expect to happen? >> >> >> >> The same kind that always happens when lots of ebuilds get changed. >> > >> > ... lots of new features and a few bugs that get fixed the next day? Hey, >> > that sounds quite bad. And maybe some new herd testers? How rude! >> >> I don't see the correlation between EAPI bumps and new herd testers. > > Well, ciaran said that the same thing happens that always happens when lots of > ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice > herd testers plus a new dev or two, so I am confused too. Maybe ciaran can > explain what he meant to say so we don't have to come to unexpected > conclusions (that would actually be a quite nice change to the average > discussion - saying what you mean instead of hinting at star constellations > and the importance of meat loaf) > >> > So what technical reason(s) do we have to keep archaic EAPIs around >> > forever? >> None, luckily this is more than a technical project ;) > > Stop confusing me, antarus, I thought you were against removing eapi0 and now > you support the removal? ;) Editing 2 ebuilds is not 'technical' in nature, its grunt work. It is a social problem, not a technical one. I also haven't stated my support in either direction since you have provided no specific arguments as to why we should do this; there is nothing to argue against. > > Anyway. Most of the "porting" effort (assuming no other issues sneaking in) > would be adding a "EAPI=1" line to ebuilds, which could be done "lazily" on > version bumps. There's no rush to get it killed now now now, but in a year we > might be at EAPI 5, and then I don't want to be the one writing the docs that > split apart what features are where and what syntax is valid and all that. Or we might be at EAPI 3; we have no EAPI roadmap and I don't like guessing. Again I'm looking for specifics here. You are asking the community to do a lot of work for relatively little gain; because you haven't specified what the gain is. So I ask again "What specific problems does this solve?" > > So phasing out eapi0 would be an obvious step towards making things simpler > for those of us that don't enjoy studying lists and tables ... > > > Patrick > > >
Re: [gentoo-dev] RFC: Deprecating EAPI0
Patrick Lauer wrote: Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick While there definitely arguments for deprecating EAPIs, I would suggest caution. A low number of active EAPIs can make life easier for developers, but it can also make life harder for some users. There are still users coming to the forums upgrading systems which only understand EAPI 0. I accept that Gentoo is certainly a relatively fast moving distro, but I think that developers also do need to consider users who have systems that are currently "just working" and may not upgrade often (once a year or even less). As such, I would suggest that forcing a move to the most recent stable EAPI is possibly unwise. I believe that forcing EAPIs to move forward at too quick a pace will cause more issues for these users. An answer to this could be to set a standard for the minimum time between upgrades - for example, 1 year - and ensure that users with anything that old can atleast upgrade portage and its dependencies to the minimum required versions without major issues. I understand that this may cause extra work in some respects, but if such a standard is set and documented then it will help users (admins) by giving them a set frequency at which they must upgrade at least the package manager, if not @system. Secondly, it was suggested that a project to upgrade all ebuilds in the tree from EAPI 0 could bring new developers, offering KDE4 as an example. I would offer caution on this assumption. KDE4 was not simply about upgrading ebuilds, but about users (contributors) and developers being able to install and test packages they wanted to install and test. I can not realistically see such an effort being asserted in the name of simply deprecating EAPIs. Yes, breakage occurred, but this was as far as I can see a complete rewrite of the KDE packaging from scratch. As such I would suggest that a certain level of breakage was to be expected. I would also suggest that the speed at which bugs are being fixed may be more of an indicator of lack of man power than anything else, and that the situation could be improved by looking at expending more effort on encouraging contributions and ultimately recruiting developers. I realize that getting people to expend effort on non-coding work can be difficult, but I think that ultimately the effort expended will be repaid in terms of extra contributions. In general, I would have to agree with those who believe there are currently better ways to expend effort within Gentoo. As such I would suggest that at most, EAPI deprecation only applies to new packages and version bumps. AllenJB
Re: [gentoo-dev] And thanks for all the fish...
And thankyou for all the fish you've given. http://cia.vc/stats/author/corsair You've done a pretty good job of making Gentoo great especially for ppc64. Good luck with whatever you do next.
Re: [gentoo-dev] perforce client proper license
On Sun, Mar 22, 2009 at 2:58 AM, Alec Warner wrote: > I think you will encounter namespace collisions, thats why I CC'd zac > as he maintains mirror-dist ;p > Why the hell didn't we think of this before!? :o The mirror-dist script *cannot* rename the upstream files for storage, since emerge will be looking for the *original* filename on the gentoo mirror. And if we keep them the same, we'll have collisions on the mirror, which is more probable (and severe) than a collision on a user's local DISTDIR. The easiest solution I can think of is for emerge to give special consideration to the mirrors in GENTOO_MIRRORS, and look for the renamed file there instead of the original ones. -- ~Nirbheek Chauhan who is extremely bewildered by this oversight
