[gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
Hi, Mike Frysinger vap...@gentoo.org: On Monday, January 24, 2011 07:31:20 Christian Faulhammer wrote: over the course of the years the x86 (and other architectures as well) has given away permissions to maintainers/teams to mark packages stable themselves. As there never was a definitive list what exceptions exist, I compiled a list of the ones I could get from the top of my head in [1]. Please yell if you have those permissions so I can complete the list for reference purposes. how about we extend metadata.xml to avoid the multiple data locations always leads to bitrot ? Sounds like an excellent idea. Who can add this? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions
Hi, Markos Chandras hwoar...@gentoo.org: I think it would be better if we kept a single list instead of compiling a separate list for every arch. Mike's proposal sounds like the ideal solution. If one wants we can autogenerate a list. For now I will collect it manually and move it over once the DTD is fixed. Can we also add a paragraph to devmanual about exceptions or shouldn't we advertise that feature? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] EAPI usage in main tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to upgrade tree-wide policy for EAPI usage in main tree. Currently we say that developers can use any named version they wish or find sufficient. I would on other hand like to have all ebuilds to use Latest EAPI version possible (given the eclasses support it [hint hint maintainers of eclasses should always try to support latest :P]) with expection for base-system or more specialy depgraph for portage that needs to be EAPI0. [[ And here we need to find out some upgrade proccess that would work for everyone so we could somehow migrate them too :)]] With this usually new developers should be aware only of latest EAPI and wont need to memorize what which EAPI support. Heck even I sometimes forget what i can do with some version and whatnot. Winner for being PITA in this race is python.eclass that HAS completely different behavior based on EAPI version used... Cheers Tomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+sf4ACgkQHB6c3gNBRYeR6wCeNKsc8LnLw3ltkc1KKllzMP3u bXMAnRlbWZjGpQ7Zc2abdxtoJFKRVszS =lkXl -END PGP SIGNATURE-
[gentoo-dev] Slacker arches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Given the talk on last council meeting I would like this policy to be in effect over main tree: Every arch teams should stabilise OR write out reason why they can't do so to stable bug in 90 days. If any arch team fails to do so the maintainer can decide to drop their keywords to testing. Given depgraph breakages the maintainer can coordinate with the QA team to drop all reverse dependencies to testing too. Only exception from this rule are toolchain and base-system bugs, since testing-only effectively means that the arch lost stable status as whole. In order to accommodate this goals Arch Teams can generate Arch Testers which can comment on the bugs in their name, where maintainer then can act upon their comments (eg: if ARM at say that everything is ok, maintainer can stabilise it on arm...). (Come on for most stable testing you don't really need to be fully fledged Gentoo dev, but you just need the named hardware and working brain :)) Cheers Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+thsACgkQHB6c3gNBRYfW4wCfXbctXUgKoK53Pd45QuAMgY7r Sy4AoMU6z/oS/JvUum6/29SHYsmuoQBs =LQj9 -END PGP SIGNATURE-
Re: [gentoo-dev] Slacker arches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 25.1.2011 12:38, Tomáš Chvátal napsal(a): Hi, Given the talk on last council meeting I would like this policy to be in effect over main tree: Every arch teams should stabilise OR write out reason why they can't do so to stable bug in 90 days. If any arch team fails to do so the maintainer can decide to drop their keywords to testing. Given depgraph breakages the maintainer can coordinate with the QA team to drop all reverse dependencies to testing too. Only exception from this rule are toolchain and base-system bugs, since testing-only effectively means that the arch lost stable status as whole. In order to accommodate this goals Arch Teams can generate Arch Testers which can comment on the bugs in their name, where maintainer then can act upon their comments (eg: if ARM at say that everything is ok, maintainer can stabilise it on arm...). (Come on for most stable testing you don't really need to be fully fledged Gentoo dev, but you just need the named hardware and working brain :)) Cheers Tom AAnd as Mark told me I actually didn't say that i want feedback and opinions on those two mails i just sent to this ML, so please tell us how do you feel about it and what would you like to be done differently :) These two mails (slacker arches, eapi usage) are not policies in effect but stuff council would like to decide about and want to know the devhood opinions. Cheers Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+vJMACgkQHB6c3gNBRYc4+wCeLPeysLA/xTacnofptQBbai5z jpEAn0jyipxEV/U/IQylCmzj3IVbe3NZ =LHQi -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI usage in main tree
On 1/25/11 12:20 PM, Tomáš Chvátal wrote: I would like to upgrade tree-wide policy for EAPI usage in main tree. I have a great idea for you. How about creating a project (possibly a subproject of QA or something else) that would help people do that? In case of no response from maintainers just do your job, and that should get the tree converted more quickly than setting a policy. My main point is that said X should be Y does not automatically make it so. We'd have to think about the migration plan anyway. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Slacker arches
On 1/25/11 12:38 PM, Tomáš Chvátal wrote: Every arch teams should stabilise OR write out reason why they can't do so to stable bug in 90 days. If any arch team fails to do so the maintainer can decide to drop their keywords to testing. Given depgraph breakages the maintainer can coordinate with the QA team to drop all reverse dependencies to testing too. Seconded. Reality++ Be prepared for some issues though. Sometimes maintainers don't agree with reasons arch teams provide that block stabilizations. In those cases, who makes the decision? My suggestion is QA. Also, we should have someone to check for stale stabilization bugs. I'm not sure if all reporters are able to take care of that, especially if they have a lot of bugs open. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: EAPI usage in main tree
On Tue, Jan 25, 2011 at 12:20:30PM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to upgrade tree-wide policy for EAPI usage in main tree. Currently we say that developers can use any named version they wish or find sufficient. I would on other hand like to have all ebuilds to use Latest EAPI version possible (given the eclasses support it [hint hint maintainers of eclasses should always try to support latest :P]) with expection for base-system or more specialy depgraph for portage that needs to be EAPI0. [[ And here we need to find out some upgrade proccess that would work for everyone so we could somehow migrate them too :)]] With this usually new developers should be aware only of latest EAPI and wont need to memorize what which EAPI support. Heck even I sometimes forget what i can do with some version and whatnot. Winner for being PITA in this race is python.eclass that HAS completely different behavior based on EAPI version used... I agree with the idea, however, just creating the policy won't be enough. We should make repoman print a warning if an older EAPI is used, maybe even refuse to commit (without -f), at least on version bumps, to get the devs' attention. base-system excluded for now, obviously. Cheers Tomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+sf4ACgkQHB6c3gNBRYeR6wCeNKsc8LnLw3ltkc1KKllzMP3u bXMAnRlbWZjGpQ7Zc2abdxtoJFKRVszS =lkXl -END PGP SIGNATURE- -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com pgpyPp4InK8Yn.pgp Description: PGP signature
Re: [gentoo-dev] EAPI usage in main tree
On Tue, Jan 25, 2011 at 01:13:06PM +0100, Paweł Hajdan, Jr. wrote: On 1/25/11 12:20 PM, Tomáš Chvátal wrote: I would like to upgrade tree-wide policy for EAPI usage in main tree. I have a great idea for you. How about creating a project (possibly a subproject of QA or something else) that would help people do that? In case of no response from maintainers just do your job, and that should get the tree converted more quickly than setting a policy. Please don't! QA is way too understaffed. We ain't gonna convert any ebuilds. This has nothing to do with QA. Let maintainers handle this My main point is that said X should be Y does not automatically make it so. We'd have to think about the migration plan anyway. Paweł @Tomas, I don't follow. You mean migrate existing ebuilds or use the latest EAPI from now on? Regards, -- Markos Chandras (hwoarang) Gentoo Linux Developer Key ID: B4AFF2C2 Key FP: 660A 0742 84EC 26F1 9EDB F00A FA83 5A15 B4AF F2C2 pgpqtOxMDWT2n.pgp Description: PGP signature
Re: [gentoo-dev] EAPI usage in main tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 25.1.2011 13:13, Paweł Hajdan, Jr. napsal(a): On 1/25/11 12:20 PM, Tomáš Chvátal wrote: I would like to upgrade tree-wide policy for EAPI usage in main tree. I have a great idea for you. How about creating a project (possibly a subproject of QA or something else) that would help people do that? In case of no response from maintainers just do your job, and that should get the tree converted more quickly than setting a policy. My main point is that said X should be Y does not automatically make it so. We'd have to think about the migration plan anyway. Paweł Why would we need subproject for this. QA team itself is done to help developers with this tasks. So if someone come to #gentoo-qa and ask us to help him with his shiny eclass we won't sent him somewhere else where sun is not shining :P And that apply even if developer itself is not maintainer and did not get reply from the maintainer... :) Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+wiIACgkQHB6c3gNBRYcXQwCgmnvpToj97h+P11ljcXjJiL3j 55UAn3FPehseXf8OkwoJvqbSp9dECdsK =1zHu -END PGP SIGNATURE-
Re: [gentoo-dev] Re: EAPI usage in main tree
On 25-01-2011 14:25:05 +0200, Alex Alexander wrote: We should make repoman print a warning if an older EAPI is used, maybe even refuse to commit (without -f), at least on version bumps, to get the devs' attention. base-system excluded for now, obviously. How obvious is that if Python is already EAPI 0? -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Slacker arches
On Tue, Jan 25, 2011 at 01:20:29PM +0100, Paweł Hajdan, Jr. wrote: On 1/25/11 12:38 PM, Tomáš Chvátal wrote: Every arch teams should stabilise OR write out reason why they can't do so to stable bug in 90 days. If any arch team fails to do so the maintainer can decide to drop their keywords to testing. Given depgraph breakages the maintainer can coordinate with the QA team to drop all reverse dependencies to testing too. Seconded. Reality++ Be prepared for some issues though. Sometimes maintainers don't agree with reasons arch teams provide that block stabilizations. In those cases, who makes the decision? My suggestion is QA. QA is not a solution to everything. The problem Tomas is trying to counter here is the idle/slacking arches. If the arch is active but have some concerns regarding the stabilization then let the maintainer deal with it. This is the way we do it now anyway Also, we should have someone to check for stale stabilization bugs. I'm not sure if all reporters are able to take care of that, especially if they have a lot of bugs open. Paweł Thats really their problem. Arches can always remove themselves from the bugs. No need to care about stale bugs. If the maintainers don't care then we(arches) don't care. Regards, -- Markos Chandras (hwoarang) Gentoo Linux Developer Key ID: B4AFF2C2 Key FP: 660A 0742 84EC 26F1 9EDB F00A FA83 5A15 B4AF F2C2 pgpctzIsQqDcN.pgp Description: PGP signature
Re: [gentoo-dev] EAPI usage in main tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 25.1.2011 13:25, Markos Chandras napsal(a): On Tue, Jan 25, 2011 at 01:13:06PM +0100, Paweł Hajdan, Jr. wrote: How about creating a project (possibly a subproject of QA or something else) that would help people do that? In case of no response from maintainers just do your job, and that should get the tree converted more quickly than setting a policy. Please don't! QA is way too understaffed. We ain't gonna convert any ebuilds. This has nothing to do with QA. Let maintainers handle this Pavel does not ask for us to migrate the ebuilds, but the eclasses, wich we do anyway now :) My main point is that said X should be Y does not automatically make it so. We'd have to think about the migration plan anyway. Paweł @Tomas, I don't follow. You mean migrate existing ebuilds or use the latest EAPI from now on? God no, when you do bump you use new eapi :) not retroactively revert all ebuilds to latest. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+wtoACgkQHB6c3gNBRYe0lACeI/ir1DEcoxIpL/l0TEjDr5IZ smQAn2ydpf013aaqR94t7A6MYb7nkslF =j9iM -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI usage in main tree
On Tue, Jan 25, 2011 at 01:32:27PM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 25.1.2011 13:25, Markos Chandras napsal(a): On Tue, Jan 25, 2011 at 01:13:06PM +0100, Paweł Hajdan, Jr. wrote: How about creating a project (possibly a subproject of QA or something else) that would help people do that? In case of no response from maintainers just do your job, and that should get the tree converted more quickly than setting a policy. Please don't! QA is way too understaffed. We ain't gonna convert any ebuilds. This has nothing to do with QA. Let maintainers handle this Pavel does not ask for us to migrate the ebuilds, but the eclasses, wich we do anyway now :) Then I am sorry My main point is that said X should be Y does not automatically make it so. We'd have to think about the migration plan anyway. Paweł @Tomas, I don't follow. You mean migrate existing ebuilds or use the latest EAPI from now on? God no, when you do bump you use new eapi :) not retroactively revert all ebuilds to latest. Ok that works for me. As Alex said, maybe a repoman warning would be a good start -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+wtoACgkQHB6c3gNBRYe0lACeI/ir1DEcoxIpL/l0TEjDr5IZ smQAn2ydpf013aaqR94t7A6MYb7nkslF =j9iM -END PGP SIGNATURE- -- Markos Chandras (hwoarang) Gentoo Linux Developer Key ID: B4AFF2C2 Key FP: 660A 0742 84EC 26F1 9EDB F00A FA83 5A15 B4AF F2C2 pgpxStDexDgXj.pgp Description: PGP signature
Re: [gentoo-dev] EAPI usage in main tree
Am 25.01.2011 12:20, schrieb Tomáš Chvátal: Hi, I would like to upgrade tree-wide policy for EAPI usage in main tree. Currently we say that developers can use any named version they wish or find sufficient. I would on other hand like to have all ebuilds to use Latest EAPI version possible (given the eclasses support it [hint hint maintainers of eclasses should always try to support latest :P]) with expection for base-system or more specialy depgraph for portage that needs to be EAPI0. [[ And here we need to find out some upgrade proccess that would work for everyone so we could somehow migrate them too :)]] With this usually new developers should be aware only of latest EAPI and wont need to memorize what which EAPI support. Heck even I sometimes forget what i can do with some version and whatnot. Do you have some more arguments for your request? Most new developers will have to know about all EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not use the newest EAPI. As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you maintain, you can always bump them to the latest EAPI. But why do you want to force this on all developers? If i have an EAPI-0 ebuild and am fine with it, why should i convert it to the latest EAPI? Winner for being PITA in this race is python.eclass that HAS completely different behavior based on EAPI version used... The python eclass issues are not just EAPI related, the complete eclass is very complex and hard to read/understand. And just because the eclass has additional EAPI-specific behaviour, this is specific to this eclass and should not be an argument for the general EAPI discussion. Cheers Tomas -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI usage in main tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 25.1.2011 14:33, Thomas Sachau napsal(a): Do you have some more arguments for your request? Most new developers will have to know about all EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not use the newest EAPI. As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you maintain, you can always bump them to the latest EAPI. But why do you want to force this on all developers? If i have an EAPI-0 ebuild and am fine with it, why should i convert it to the latest EAPI? 1) less stuff to memorize: seriously mostly if you just use latest EAPI and 0 you can make yourself not to bother for example with quirks required to use prefix properly in EAPI2 2) easier migration and deprecation of old EAPIs: If we enforce latest EAPI to be used EAPIs will be phased out by automatic upgrade process where we can migrate them. 3) using less codepaths: so we can find out what the heck is wrong easier in both eclasses and portage if we know that it was hit with the latest code 4) eapis are done to bring shiny features: usually ebuilds using new EAPI should be cleaner and easier to read than the old EAPI ones, by worst case scenario you just add the EAPI=Version line to the ebuild which makes it bit larger. Winner for being PITA in this race is python.eclass that HAS completely different behavior based on EAPI version used... The python eclass issues are not just EAPI related, the complete eclass is very complex and hard to read/understand. And just because the eclass has additional EAPI-specific behaviour, this is specific to this eclass and should not be an argument for the general EAPI discussion. I just said that the eclass has different behaviour for each eapi. Which is true, nothing more nothing less. And you have to memorize it and check the behavior in reported bug with various EAPIs. Tomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+2YIACgkQHB6c3gNBRYdW/gCbB/Ki35r13CfUJPiaDNhgoAEO BfUAn3b/t9BEpU6Cd26btvCReTsizv66 =qFH3 -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI usage in main tree
Am 25.01.2011 15:09, schrieb Tomáš Chvátal: Dne 25.1.2011 14:33, Thomas Sachau napsal(a): Do you have some more arguments for your request? Most new developers will have to know about all EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not use the newest EAPI. As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you maintain, you can always bump them to the latest EAPI. But why do you want to force this on all developers? If i have an EAPI-0 ebuild and am fine with it, why should i convert it to the latest EAPI? 1) less stuff to memorize: seriously mostly if you just use latest EAPI and 0 you can make yourself not to bother for example with quirks required to use prefix properly in EAPI2 You are free to only use latest EAPI and EAPI-0 in your ebuilds. So you dont have to memorize the changes in the other EAPI versions. But why do you want to force this on me too? I have to maintain my ebuilds and have to debug the bugs for it, so why not give me the choice to use whatever i prefer to use? 2) easier migration and deprecation of old EAPIs: If we enforce latest EAPI to be used EAPIs will be phased out by automatic upgrade process where we can migrate them. Why would any migration be easier? You always have to check the difference between current and planned EAPI during a migration, this wont change with the policy. And why do you want to deprecate older EAPI versions? 3) using less codepaths: so we can find out what the heck is wrong easier in both eclasses and portage if we know that it was hit with the latest code As i said for the previous points: If you maintain something, you can use whatever you like, including the latest versions, so this is no issue i can see. 4) eapis are done to bring shiny features: usually ebuilds using new EAPI should be cleaner and easier to read than the old EAPI ones, by worst case scenario you just add the EAPI=Version line to the ebuild which makes it bit larger. Sure, but if it is just another line and nothing else changes, why should i then even add that line? I prefer to keep things to the minimum required and if it works fine for me without the additional line, why should i add it? Winner for being PITA in this race is python.eclass that HAS completely different behavior based on EAPI version used... The python eclass issues are not just EAPI related, the complete eclass is very complex and hard to read/understand. And just because the eclass has additional EAPI-specific behaviour, this is specific to this eclass and should not be an argument for the general EAPI discussion. I just said that the eclass has different behaviour for each eapi. Which is true, nothing more nothing less. And you have to memorize it and check the behavior in reported bug with various EAPIs. This means, that you either have to convince the python eclass maintainers to reduce the complexity of their eclass or you dont maintain ebuilds, which have to use their eclasses. Alternatively you can just remember the behaviour for the latest EAPI and use that in your ebuilds, so how does the different behaviour for previous EAPI versions create issues for you? Tomas -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrite: sys-auth/policykit
# Samuli Suominen ssuomi...@gentoo.org (25 Jan 2011) # Replaced by sys-auth/polkit. Removal in 30 days. # Bug 340331. sys-auth/policykit Maybe things will get a little bit less confusing now... ;-)
[gentoo-dev] Lastrite: sys-auth/policykit
# Samuli Suominen ssuomi...@gentoo.org (25 Jan 2011) # Replaced by sys-auth/polkit. Removal in 30 days. # Bug 340331. sys-auth/policykit Maybe things will get a little big less confusing now... ;-)
Re: [gentoo-dev] Lastrite: sys-auth/policykit
On 01/25/2011 04:45 PM, Samuli Suominen wrote: # Samuli Suominen ssuomi...@gentoo.org (25 Jan 2011) # Replaced by sys-auth/polkit. Removal in 30 days. # Bug 340331. sys-auth/policykit Maybe things will get a little big less confusing now... ;-) hah. looks like I was too slow at hitting cancel. :) s/big/bit/
Re: [gentoo-dev] Slacker arches
On Tue, 25 Jan 2011 12:38:03 +0100, Tomáš Chvátal wrote: Only exception from this rule are toolchain and base-system bugs, since In both threads you recently started, you used the term base-system bugs but I think you mean @system packages - there are a ton of base-system packages that are not critical and wouldn't apply to either of your threads. Is this an accurate assumption on my part here? -Jeremy
Re: [gentoo-dev] EAPI usage in main tree
On 1/25/11 1:29 PM, Tomáš Chvátal wrote: Why would we need subproject for this. The idea was that if you want to introduce a new policy, you should also provide resources to make it possible. The below satisfies most of that. QA team itself is done to help developers with this tasks. So if someone come to #gentoo-qa and ask us to help him with his shiny eclass we won't sent him somewhere else where sun is not shining :P SGTM. One additional point is that there may be rarely bumped packages that won't be migrated naturally, but will need an update just for the EAPI bump, and the maintainers may just ignore this, so there should be someone actively monitoring the progress. And that apply even if developer itself is not maintainer and did not get reply from the maintainer... :) Yes, definitely. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Slacker arches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 25.1.2011 16:49, Jeremy Olexa napsal(a): On Tue, 25 Jan 2011 12:38:03 +0100, Tomáš Chvátal wrote: Only exception from this rule are toolchain and base-system bugs, since In both threads you recently started, you used the term base-system bugs but I think you mean @system packages - there are a ton of base-system packages that are not critical and wouldn't apply to either of your threads. Is this an accurate assumption on my part here? -Jeremy Yeah you are right :P mea culpa maxima -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+8p4ACgkQHB6c3gNBRYfCHQCggR3NiP+1R/vhHU/tAHSzJC2p ZhAAn0VHw3HaadJstoTpLgLeYG9HL63m =HLLa -END PGP SIGNATURE-
Re: [gentoo-dev] EAPI usage in main tree
В Втр, 25/01/2011 в 14:33 +0100, Thomas Sachau пишет: Do you have some more arguments for your request? Most new developers will have to know about all EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not use the newest EAPI. As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you maintain, you can always bump them to the latest EAPI. But why do you want to force this on all developers? I think your first paragraph is actually the argument to use latest EAPI whenever possible. Such policy provides us with the path to avoid situation you described while insisting on keeping old EAPI's obviously will force new developer to learn ancient knowledge. IOW, such policy provides path to simplify work in team. -- Peter.
Re: [gentoo-dev] EAPI usage in main tree
2011-01-25 15:34:58 Thomas Sachau napisał(a): This means, that you either have to convince the python eclass maintainers to reduce the complexity of their eclass There are plans to remove some EAPI-specific behavior by removing support for old EAPIs. E.g. when there are no remaining ebuilds using distutils.eclass, python_mod_optimize() or python_mod_cleanup() in old EAPIs, then it will be possible to remove large parts of python_mod_optimize() and python_mod_cleanup(). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage in main tree
Am 25.01.2011 17:40, schrieb Peter Volkov: В Втр, 25/01/2011 в 14:33 +0100, Thomas Sachau пишет: Do you have some more arguments for your request? Most new developers will have to know about all EAPi versions anyway since they join an existing team with existing ebuilds, which will mostly not use the newest EAPI. As an argument againt this: Noone forces you to keep older EAPI versions of the ebuilds you maintain, you can always bump them to the latest EAPI. But why do you want to force this on all developers? I think your first paragraph is actually the argument to use latest EAPI whenever possible. Such policy provides us with the path to avoid situation you described while insisting on keeping old EAPI's obviously will force new developer to learn ancient knowledge. IOW, such policy provides path to simplify work in team. If you as a maintainer or the maintaining team want to migrate your ebuilds to the latest EAPI, this is your decision. But if i am fine with an older EAPI version in those ebuilds i do maintain, what is wrong with that? Why do you want to force others into migrating to a newer EAPI, if they dont want it for whatever reason (like no need or upgrade path)? The only nice to have situation is, when you take over an existing ebuild. If it already uses the latest EAPI, you dont have to migrate it. On one side, you wont be able to avoid the migration, since exactly those ebuilds, which need a new maintainer wont be touched, so also wont be using the latest EAPI. On the other side, we have docs, which show you the changes with each EAPI, so you can read it once, adjust the ebuild and forget it again. I see nothing gained in this situation either, so we are back to my question above. The (maybe inofficial) suggestion is already to use the latest EAPI in new ebuilds. This is ok for me, as long as it is a suggestion. The same goes for the migration of ebuilds to the latest EAPI. But i am against the idea to enforce this for either new or even existing ebuilds. I prefer to do other work than useless EAPI-migration without a real need/benefit for me or the users. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI usage in main tree
On Tuesday 25 January 2011 20:13:40 Thomas Sachau wrote: The (maybe inofficial) suggestion is already to use the latest EAPI in new ebuilds. This is ok for me, as long as it is a suggestion. The same goes for the migration of ebuilds to the latest EAPI. But i am against the idea to enforce this for either new or even existing ebuilds. I prefer to do other work than useless EAPI-migration without a real need/benefit for me or the users. This is fine as long as you do pure standalone work. As soon as you use a single eclass, you basically require the eclass maintainers to provide support for each and every EAPI - and that's an important point here. AFAIK the kde team will soon require EAPI ()= 3 for all ebuilds using kde4-* eclasses. Similar restrictions already exist in other cases _in order to ease maintainability_. Why not go all the way and clean the mess out? -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: dev-dotnet/ndoc
# Pacho Ramos pa...@gentoo.org (25 Jan 2011) # Doesn't work with mono-2.8, upstream died since 2005, # nothing in the tree uses it (bug #342023). # Removal in 30 days. dev-dotnet/ndoc signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI usage in main tree
Hi, I don'f feel very well with this idea especially because no matter how hard I try I don't get comfortable with EAPI-3. No offense to our prefix guys, you surely did a hell of a good job and EAPI-3 seems to really get you out of quite some trouble you had with earlier EAPIs, but... I for myself never tried a prefix installation and I don't have any intentions to do this in the foreseeable future so I still prefer EAPI-2 wherever I can simply because EAPI-3 imposes overhead on my side which I have no real benefit from and I have no real clue about how to write proper EAPI-3 ebuilds. -- Lars Wendler (Polynomial-C) Gentoo package maintainer and bug-wrangler Am Dienstag 25 Januar 2011, 12:20:30 schrieb Tomáš Chvátal: Hi, I would like to upgrade tree-wide policy for EAPI usage in main tree. Currently we say that developers can use any named version they wish or find sufficient. I would on other hand like to have all ebuilds to use Latest EAPI version possible (given the eclasses support it [hint hint maintainers of eclasses should always try to support latest :P]) with expection for base-system or more specialy depgraph for portage that needs to be EAPI0. [[ And here we need to find out some upgrade proccess that would work for everyone so we could somehow migrate them too :)]] With this usually new developers should be aware only of latest EAPI and wont need to memorize what which EAPI support. Heck even I sometimes forget what i can do with some version and whatnot. Winner for being PITA in this race is python.eclass that HAS completely different behavior based on EAPI version used... Cheers Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage in main tree
2011-01-25 22:33:16 Lars Wendler napisał(a): Hi, I don'f feel very well with this idea especially because no matter how hard I try I don't get comfortable with EAPI-3. No offense to our prefix guys, you surely did a hell of a good job and EAPI-3 seems to really get you out of quite some trouble you had with earlier EAPIs, but... I for myself never tried a prefix installation and I don't have any intentions to do this in the foreseeable future so I still prefer EAPI-2 wherever I can simply because EAPI-3 imposes overhead on my side which I have no real benefit from and I have no real clue about how to write proper EAPI-3 ebuilds. You can use EAPI=3 without supporting prefix installations. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage in main tree
On 25/01/11 22:33, Lars Wendler wrote: Hi, I don'f feel very well with this idea especially because no matter how hard I try I don't get comfortable with EAPI-3. No offense to our prefix guys, you surely did a hell of a good job and EAPI-3 seems to really get you out of quite some trouble you had with earlier EAPIs, but... I for myself never tried a prefix installation and I don't have any intentions to do this in the foreseeable future so I still prefer EAPI-2 wherever I can simply because EAPI-3 imposes overhead on my side which I have no real benefit from and I have no real clue about how to write proper EAPI-3 ebuilds. You can use EAPI=3 completely independent from prefix support. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI usage in main tree
On Tue, 25 Jan 2011, Lars Wendler wrote: I don'f feel very well with this idea especially because no matter how hard I try I don't get comfortable with EAPI-3. No offense to our prefix guys, you surely did a hell of a good job and EAPI-3 seems to really get you out of quite some trouble you had with earlier EAPIs, but... I for myself never tried a prefix installation and I don't have any intentions to do this in the foreseeable future so I still prefer EAPI-2 wherever I can simply because EAPI-3 imposes overhead on my side which I have no real benefit from and I have no real clue about how to write proper EAPI-3 ebuilds. As long as your ebuild doesn't need any keywords for prefix architectures, nothing forces you to use ED and EROOT variables instead of D and ROOT. In other words, you can simply change the EAPI declaration in an ebuild from 2 to 3 and it will continue to work. Ulrich
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Saturday 22 January 2011 20:06:06 Sebastian Pipping wrote: On 01/22/11 13:32, Theo Chatzimichos wrote: Well, the distinction for unofficial/official overlays happen mostly in layman -L, I don't think users pay attention to our git repo list. Furthermore, I got at least three requests from developers to move their repo from user/ to dev/ (same problem when devs retired). This distinction doesn't make any sense. Three request over what time? Compared to a screen height of user repos created, maybe that's not much. Sebastian I'm sorry I don't share your point. I think I was quite clear, the user/developer distinction (or better, the unofficial/official overlay) should happen in layman list and in overlays website, not in gitolite. Take a look at the current list in gitweb and tell me honestly how clear and distinct is that thing for you. For the record: the following overlays should move from dev/ to user/: b33fc0d3, hawking, uberlord, welp the following should move from user/ to dev/: dilfridge at least two people with user/ overlays are going to be gentoo devs soon and last but not least, smithdanea overlay is useless because c1pher has a dev overlay as well now not to mention the proj/ list. And now, imagine the state of the user/ dev/ list mess in, say, two or five years -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Wed, Jan 26, 2011 at 12:02:16AM +0200, Theo Chatzimichos wrote: And now, imagine the state of the user/ dev/ list mess in, say, two or five years So you're in favour of making it 'people/' and just distinguishing in the descriptions and Layman? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpvVuVxDow1z.pgp Description: PGP signature
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 25.1.2011 23:08, Robin H. Johnson napsal(a): On Wed, Jan 26, 2011 at 12:02:16AM +0200, Theo Chatzimichos wrote: And now, imagine the state of the user/ dev/ list mess in, say, two or five years So you're in favour of making it 'people/' and just distinguishing in the descriptions and Layman? Could you guys do it like mammals/ Kthx :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0/SrsACgkQHB6c3gNBRYc6aQCgnWhn+TpaL2ZridSW21wernJL ZQIAoKhqrbD28kGr4BtV/kBRIGAVhsm7 =AU/O -END PGP SIGNATURE-
[gentoo-dev] Re: Stabilisation exceptions
On Mon, 24 Jan 2011 13:31:20 +0100 Christian Faulhammer fa...@gentoo.org wrote: Hi, over the course of the years the x86 (and other architectures as well) has given away permissions to maintainers/teams to mark packages stable themselves. As there never was a definitive list what exceptions exist, I compiled a list of the ones I could get from the top of my head in [1]. Please yell if you have those permissions so I can complete the list for reference purposes. V-Li [1] http://www.gentoo.org/proj/en/base/x86/exceptions.xml sys-libs/timezone-data most of app-doc (ie. anything installing just docs or text) I'd also like permission to stabilize fonts ourselves once they've cleared amd64 and x86. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Slacker arches
On Tue, 25 Jan 2011 12:38:03 +0100 Tomáš Chvátal scarab...@gentoo.org wrote: Every arch teams should stabilise OR write out reason why they can't do so to stable bug in 90 days. If any arch team fails to do so the maintainer can decide to drop their keywords to testing. Given depgraph breakages the maintainer can coordinate with the QA team to drop all reverse dependencies to testing too. Won't this just pile on more work on already stressed to the max arch teams? As in, now they have to stabilize more packages to get back to where they were in the first place? And as I understand it, the reason maintainers are complaining is because they want to drop old versions. Meaning stable users of these archs can suddenly lose large parts of the tree if this happens. From their point of view, we've just broken perfectly working systems. That's pretty much the opposite of what stable is supposed to promise. And I've never been an arch tester, but I bet after the first few times I tested a package only to have it dropped to ~arch because no developer was around to commit the keyword change, I wouldn't feel much like doing it anymore. How about the opposite? If everyone but $arch has stabilized the package, and you can't get a response from them in a reasonable time, then use your discretion as maintainer and mark it stable yourself. This isn't ideal, and it could cause something to break for stable users now and then, but it's better than the guaranteed breakage of just dropping the stable keyword for it and its dependencies. Arch testers would remain useful by giving the maintainer some measure of assurance that they won't accidently break anything for that arch. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
like on the discovery channel? -A 2011/1/25 Tomáš Chvátal scarab...@gentoo.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 25.1.2011 23:08, Robin H. Johnson napsal(a): On Wed, Jan 26, 2011 at 12:02:16AM +0200, Theo Chatzimichos wrote: And now, imagine the state of the user/ dev/ list mess in, say, two or five years So you're in favour of making it 'people/' and just distinguishing in the descriptions and Layman? Could you guys do it like mammals/ Kthx :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0/SrsACgkQHB6c3gNBRYc6aQCgnWhn+TpaL2ZridSW21wernJL ZQIAoKhqrbD28kGr4BtV/kBRIGAVhsm7 =AU/O -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Slacker arches
On 1/26/11 3:14 AM, Ryan Hill wrote: On Tue, 25 Jan 2011 12:38:03 +0100 Tomáš Chvátal scarab...@gentoo.org wrote: Won't this just pile on more work on already stressed to the max arch teams? As in, now they have to stabilize more packages to get back to where they were in the first place? This seems to be a self-balancing system to me. If the arch team is so stressed that it can't stabilize something within 90 days, and can't even state a reason for that, just move the package back to testing. After some time, the stable set for that arch should be small enough to let the arch team handle it on time. And as I understand it, the reason maintainers are complaining is because they want to drop old versions. I'm not sure why maintainers are complaining, but generally managing bugs that sit there for a long time is harder. Meaning stable users of these archs can suddenly lose large parts of the tree if this happens. From their point of view, we've just broken perfectly working systems. That's pretty much the opposite of what stable is supposed to promise. That's an important point. I think that a message should be sent somewhere (gentoo-dev-announce?) that something like that is going to happen, and wait some 60 days for someone to save the package. And I've never been an arch tester, but I bet after the first few times I tested a package only to have it dropped to ~arch because no developer was around to commit the keyword change, I wouldn't feel much like doing it anymore. Good point. How about the opposite? If everyone but $arch has stabilized the package, and you can't get a response from them in a reasonable time, then use your discretion as maintainer and mark it stable yourself. Very dangerous, especially for exotic arches. I think we should not go that way, or at least _require_ the maintainer to test on that arch. We have some development machines for various arches so it should be technically possible. But it generally seems to me that maintainers miss more problems than arch testers/developers. Arch testers would remain useful by giving the maintainer some measure of assurance that they won't accidently break anything for that arch. Good point, again provided the maintainer at least compile-tests the package on that arch. Paweł signature.asc Description: OpenPGP digital signature
