Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
On Sun, 20 Oct 2013 12:41:02 +0100 Markos Chandras hwoar...@gentoo.org wrote: No I never meant broken depgraphs. Well for broken deps, repoman does not let you commit. If you use --force to workaround broken deps, well, then you get what you deserve. No, apparently tomwij can get not only away with this (and apparently others as well on a regular basis). Not just that: he gets to write a lengthy apology that merely blames others / documentation / common sense, and then proceeds to call me unprofessional for pointing out in public the several mistakes he made. I feel very much that he's not getting it (what he deserves). jer
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
On Sun, 20 Oct 2013 14:30:56 +0200 Tom Wijsman tom...@gentoo.org wrote: Yes, I am sorry for that; it didn't came to mind to unkeyword HPPA, because I planned to unkeyword the USE flags instead and have planned to have a bug filed, I'll pay more attention to not -f again in a hurry. There is no instead. The default policy (did you read the devmanual yet?) is to DROP KEYWORDS (and let arch teams re-add them) -unless- that is really cumbersome (when you need to drop more and more keywords as a result). Since you don't seem to get why this is. Let me give you an example. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Minor Arch User: I want cat-more/pkg with USE=foo but I can't enable it. Why is USE=interesting masked? Minor Arch Dev: I don't know. Let me look it up. Minor Arch Dev: Ah, it's in profiles/default/linux/somearch/package.use.mask: # Some Package Maintainer some@package.maintainer (1 Jan 1970) # dev-libs/interesting not keyworded so disabling, kthxbye cat-more/pkg interesting Minor Arch Dev: Apparently it was put there a long time ago. It has no bug reference and I can't find a ChangeLog entry. Oh wait, it's mentioned in profiles/ChangeLog-1971 but with the same uninformative text. Minor Arch User: So what do I need to do? Minor Arch Dev: Er, you write an entry in /etc/portage/profile/package.keywords for the dev-libs/interesting package (make sure to put the ~arch or '**', yeah?), and another entry in /etc/portage/profile/package.use.mask with the same entry as package.use.mask (but with the sign of the USE flag inverted, right?). Then when you have successfully re-emerged cat-more/pkg with USE=interesting, send me a new bug report so we can start removing the bitrot from the arch profile and keywording stuff properly. (Several portage configuration explanations and bug hunts later.) (Minor Arch User exits stage left having gained happy happy support for interesting in his pkg.) Minor Arch Dev: O, if only the keyword had been dropped at the time, and two more keywords had been re-added to cat-more/pkg and dev-libs/interesting at the time, none of this would have been needed. Mercy! (Minor Arch Dev drinks the poison and drops to the floor) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jer
Re: [gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/10/13 12:14 PM, Anthony G. Basile wrote: On 10/19/2013 12:10 PM, Panagiotis Christopoulos wrote: On 10:43 Sat 19 Oct , Daniel Campbell wrote: On 10/19/2013 10:32 AM, Pacho Ramos wrote: ... x11-wm/fluxbox I'm not a developer (but have a completed dev test that doesn't know where to go...). I'm interested in nabbing x11-wm/fluxbox (and any related projects that are still alive). I use Fluxbox daily and keep an eye on upstream. It'd be nice to be able to contribute something worthwhile to Gentoo, even if it's just one package (for now). I'll add myself to fluxbox and probably everything related to fluxbox but as u know I'm not so active nowadays so anyone who is willing, should add him/herself too. @Daniel, you can help by proxy-maintaining fluxbox or if you want to become a gentoo developer I can mentor you if you don't find someone else in your timezone. By the way, are you sure, guys, you want to remove the desktop-wm herd at all? I'm worried about removing desktop-wm. I think we need some new developers in that direction. I too am busy, but I think the best use of my time might be mentoring new devs that want to pick up some of the weak areas. --Tony If the herd is essentially empty, I think it probably makes more sense for the packages to get split up across specific developers; at least then they'll be tracked by people that are at least somewhat involved and committed to them rather than hiding the fact that we only have partial coverage of all these packages under a herd. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJlNSEACgkQ2ugaI38ACPD/MgD9Gj4D58F54//hkeyUw3k3uMTS wAGFKLrMqLRgEi/6UlkBAL/nZdAQhwaBQipwbpenhDWfyl7sVTdgB3SeH02X5yBn =KqcC -END PGP SIGNATURE-
[gentoo-dev] Re: official games repository
On 21/10/2013 09:43, Tom Wijsman wrote: An alternative would probably be gerrit which vapier seems to be a fan of. But we don't even have an ebuild. Since I have just noticed this is Java, CC-ed us on the bug and this is on my list; but given its size, I can't make any promises as to when we will have the whole ebuild set made. I hope for it to be maintainable... Gerrit is a nice idea, but infra has previously expressed that they are not interested in touching java stuff.
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
On Mon, 21 Oct 2013 15:50:34 +0200 Jeroen Roovers j...@gentoo.org wrote: On Sun, 20 Oct 2013 14:30:56 +0200 Tom Wijsman tom...@gentoo.org wrote: There is no instead. Why is there no instead? The default policy (did you read the devmanual yet?) Which policy are you referring to? (Did you refer me to anything?) is to DROP KEYWORDS (and let arch teams re-add them) Which is what I exactly did for the USE flags on most of the arches; and a bug was planned to be filed, such that they can decide on it. -unless- that is really cumbersome (when you need to drop more and more keywords as a result). Please do not make additional exceptions, we have enough of them. Since you don't seem to get why this is. Let me give you an example. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Minor Arch User: I want cat-more/pkg with USE=foo but I can't enable it. Why is USE=interesting masked? Minor Arch Dev: I don't know. Let me look it up. Minor Arch Dev: Ah, it's in profiles/default/linux/somearch/package.use.mask: # Some Package Maintainer some@package.maintainer (1 Jan 1970) # dev-libs/interesting not keyworded so disabling, kthxbye cat-more/pkg interesting Minor Arch Dev: Apparently it was put there a long time ago. It has no bug reference and I can't find a ChangeLog entry. Oh wait, it's mentioned in profiles/ChangeLog-1971 but with the same uninformative text. Right; bug reference added, I see no other problem here. Minor Arch User: So what do I need to do? Minor Arch Dev: Er, you write an entry in /etc/portage/profile/package.keywords for the dev-libs/interesting package (make sure to put the ~arch or '**', yeah?), and another entry in /etc/portage/profile/package.use.mask with the same entry as package.use.mask (but with the sign of the USE flag inverted, right?). Whether you change package.keywords twice or change both once; it doesn't result in a difference in effort, I do not see your point here. Then when you have successfully re-emerged cat-more/pkg with USE=interesting, send me a new bug report so we can start removing the bitrot from the arch profile and keywording stuff properly. Why file a duplicate bug? (Several portage configuration explanations and bug hunts later.) For what? (Minor Arch User exits stage left having gained happy happy support for interesting in his pkg.) Minor Arch Dev: O, if only the keyword had been dropped at the time, and two more keywords had been re-added to cat-more/pkg and dev-libs/interesting at the time, none of this would have been needed. Mercy! (Minor Arch Dev drinks the poison and drops to the floor) Two entries will continue to be two entries; so, I do not see where the difference in work comes from. Can you now please explain the exception? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jer -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
On Mon, 21 Oct 2013 15:32:10 +0200 Jeroen Roovers j...@gentoo.org wrote: On Sun, 20 Oct 2013 12:41:02 +0100 Markos Chandras hwoar...@gentoo.org wrote: No I never meant broken depgraphs. Well for broken deps, repoman does not let you commit. If you use --force to workaround broken deps, well, then you get what you deserve. No, apparently tomwij can get not only away with this (and apparently others as well on a regular basis). Not just that: he gets to write a lengthy apology that merely blames others / documentation / common sense, and then proceeds to call me unprofessional for pointing out in public the several mistakes he made. I feel very much that he's not getting it (what he deserves). This is a first time I mask an USE flag on a package for a very small single issue, please do not get upset over it. If I do it perfectly on other achitectures which do not point anything out about it; then there must be a reason as to why this happened *, please assume good faith and do not see my explanation as a way to blame people or words. You or your comment is not the reason to it, rather my misinterpretation of it. My replies are rather intended to make sure apparently others do not experience this again in the future; by introducing consistency, deciding on policy, clarifying documentation and so on... It simply does not work to say to me that you're supposed to when that doesn't reflect what other arches do as well as the docs; I have learned early on to not be convinced by inviduals, but rather to base myself on consensus as to avoid people telling me conflicted matters. To some extent I might be trying to be too professional; but, I'm rather scared of not being professional enough, so I try not to be careless when checking whether there is a consensus on matters. You very well know that this is not intended, that I apologize and that I will not let it happen again; so, the only thing left I ask from Gentoo and you is to bring more consistency in this matter so all of us do not have to go through this again. If there's no consistency, no policy for the HPPA exception and missing documentation; then ask yourself, what alerts and/or prevents the next new developer from making this mistake again once he gets to USE flag dependencies that need to be masked? Nothing, and that concerns me. As for blaming you; it is quite the opposite, I have actually been trying to become friends with you because we share some common concerns (bug wrangling, keeping #gentoo clean, ...) but I find it much harder to do that these days running into these roadblocks (atrocity when making a mistake because of an unexpected comment, changing the patch name in tinyproxy, getting away and getting what I deserve, ...) that are the result of us not communicating in a professional way. I very well respect your position as an arch member, your concerns to keep maintaining the arch easy and more; I'm not bothered by you, even rather admire some of the work you do. I do speak up to improve our maintenance to be more efficient, to improve Gentoo and to increase the general user experience; then if problems or complexity sits in the way of that, I want to explain, discuss and improve it. When that is reasonably possible. Please note that I however do not insist on it; if nobody's interested, then I am okay with that. What I didn't get here is why that comment is in place in the HPPA package.use.mask; my confusion on this should be clear from the other reply I gave on your example. I'm not at all here to convince you; rather, I'm here to try to understand its meaning. If you do not want to clarify that or provide facts or references; then I agree to disagree with your opinion for adding that comment. Regardless of that, the mistake won't happen again. Thank you for the great work, your understanding and have a nice day. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
On Mon, 21 Oct 2013 17:32:03 +0200 Tom Wijsman tom...@gentoo.org wrote: On Mon, 21 Oct 2013 15:50:34 +0200 Jeroen Roovers j...@gentoo.org wrote: On Sun, 20 Oct 2013 14:30:56 +0200 Tom Wijsman tom...@gentoo.org wrote: There is no instead. Why is there no instead? I planned to unkeyword the USE flags instead - this is wrong. The policy (see below for the link - you seem to have trouble finding it every time I point it out) is to drop keywords (that is entries in the KEYWORDS variable, see below for an extra explanation since you seem to be confused as to what it means). The default policy (did you read the devmanual yet?) Which policy are you referring to? (Did you refer me to anything?) http://devmanual.gentoo.org/keywording/index.html Sometimes you may need to remove a keyword because of new unresolved dependencies. If you do this, you *must* file a bug notifying the relevant arch teams. is to DROP KEYWORDS (and let arch teams re-add them) Which is what I exactly did for the USE flags on most of the arches; and a bug was planned to be filed, such that they can decide on it. You are apparently confusing dropping keywords (entries in the KEYWORDS variable in an ebuild) with masking USE flags. Why would you do that? I know you are smarter than this. -unless- that is really cumbersome (when you need to drop more and more keywords as a result). Please do not make additional exceptions, we have enough of them. What do you mean? This common sense policy has been in place for years. If dropping one keyword breaks many (rev-)deps and is therefore not an option, it's quite the norm to either file a keyword request bug well in advance of anything in the tree breaking, or temporarily mask either ebuilds or USE flags, generally or specifically for an arch profile, and inform the arch teams. Right; bug reference added, I see no other problem here. That should also tell you that it helps to inform arch teams by filing a bug report -before- you drop keywords or mess up the profiles. Two entries will continue to be two entries; so, I do not see where the difference in work comes from. Can you now please explain the exception? There is no exception. You've made that bit up. The proper procedure is to ask arch teams to re-keyword the ebuild you had to drop their keyword for. If that is impossible, several other scenarios can be played out, such as use.masking to cover up a deficiency in porting to said arch, dropping keywords for that arch altogether, or whatever might work. The point is that you shouldn't be making that decision - you just maintain the package, not the arch profile, and you ran into a problem which you didn't propose they fix - you just covered it all up. The difference in work would amount to editing two files in the profiles/ subdir per architecture you want to abuse profiles/ for instead of asking their actual opinion, then later both undoing all that work and simply changing the files that matter, the ebuilds and auxiliary files (some 6 files in the example). For an arch developer wanting to test if the new dep should really be masked, or actually works just fine on his arch and should have been keyworded long ago, the improper procedure involves both unmasking the new dep in package.keywords as well as unmasking the USE flag on the test system, and then reversing the profile change and adding the keyword to the new dep. With just the dropped keyword, everything is normally much simpler. I don't see how you count up entries here - from experience re-adding keywords is a lot easier than removing profile masks. jer
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
On Mon, 21 Oct 2013 18:31:43 +0200 Jeroen Roovers j...@gentoo.org wrote: I planned to unkeyword the USE flags instead - this is wrong. The policy (see below for the link - you seem to have trouble finding it every time I point it out) is to drop keywords (that is entries in the KEYWORDS variable, see below for an extra explanation since you seem to be confused as to what it means). The default policy (did you read the devmanual yet?) Which policy are you referring to? (Did you refer me to anything?) http://devmanual.gentoo.org/keywording/index.html Sometimes you may need to remove a keyword because of new unresolved dependencies. If you do this, you *must* file a bug notifying the relevant arch teams. is to DROP KEYWORDS (and let arch teams re-add them) Which is what I exactly did for the USE flags on most of the arches; and a bug was planned to be filed, such that they can decide on it. You are apparently confusing dropping keywords (entries in the KEYWORDS variable in an ebuild) with masking USE flags. Why would you do that? I know you are smarter than this. TL;DR: Clarified my misunderstanding, I agree now that I understand. Because the end result (a change in visibility) is mostly the same. I agree that keywording and masking are not the same; I however have considered that masking is the scope of an arch equals to unkeywording for that particular architecture. The difference in what happens towards the end result here is thus quite small; but now that you point it out, I do now understand that the words can carry quite a different meaning. A meaning that depends on how they are understood. Thanks you for highlighting that. -unless- that is really cumbersome (when you need to drop more and more keywords as a result). Please do not make additional exceptions, we have enough of them. What do you mean? This common sense policy has been in place for years. If dropping one keyword breaks many (rev-)deps and is therefore not an option, it's quite the norm to either file a keyword request bug well in advance of anything in the tree breaking, or temporarily mask either ebuilds or USE flags, generally or specifically for an arch profile, and inform the arch teams. +1 Sorry, I was thinking about an end package as opposed to a library. Right; bug reference added, I see no other problem here. That should also tell you that it helps to inform arch teams by filing a bug report -before- you drop keywords or mess up the profiles. This is what I've almost always have done; but I went wrong here by off sourcing it this time to the proxy maintainer, will not do that again. Two entries will continue to be two entries; so, I do not see where the difference in work comes from. Can you now please explain the exception? There is no exception. You've made that bit up. http://gentoo.2317880.n4.nabble.com/best-way-to-use-profiles-and-package-use-mask-td16465.html From that thread I get that half of the people agree and that half of the people don't; looking at the package.use.mask I have seen non-arch members touch them from time to time, so while it might not necessarily be the exception I'm not so sure if it is the rule. Regardless of that view on it, I find your argument that you give below about the amount of files changed (adding + removing) and the difference between keywording and masking both requiring more work quite convincing; so I totally agree with you on that. The proper procedure is to ask arch teams to re-keyword the ebuild you had to drop their keyword for. If that is impossible, several other scenarios can be played out, such as use.masking to cover up a deficiency in porting to said arch, dropping keywords for that arch altogether, or whatever might work. The point is that you shouldn't be making that decision - you just maintain the package, not the arch profile, and you ran into a problem which you didn't propose they fix - you just covered it all up. The difference in work would amount to editing two files in the profiles/ subdir per architecture you want to abuse profiles/ for instead of asking their actual opinion, then later both undoing all that work and simply changing the files that matter, the ebuilds and auxiliary files (some 6 files in the example). For an arch developer wanting to test if the new dep should really be masked, or actually works just fine on his arch and should have been keyworded long ago, the improper procedure involves both unmasking the new dep in package.keywords as well as unmasking the USE flag on the test system, and then reversing the profile change and adding the keyword to the new dep. With just the dropped keyword, everything is normally much simpler. I don't see how you count up entries here - from experience re-adding keywords is a lot easier than removing profile masks. I was reading your example from an user perspective the first time; in that
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
On 10/21/2013 02:32 PM, Jeroen Roovers wrote: On Sun, 20 Oct 2013 12:41:02 +0100 Markos Chandras hwoar...@gentoo.org wrote: No I never meant broken depgraphs. Well for broken deps, repoman does not let you commit. If you use --force to workaround broken deps, well, then you get what you deserve. No, apparently tomwij can get not only away with this (and apparently others as well on a regular basis). Not just that: he gets to write a lengthy apology that merely blames others / documentation / common sense, and then proceeds to call me unprofessional for pointing out in public the several mistakes he made. I feel very much that he's not getting it (what he deserves). jer Lets calm down a little bit. Our documentation is nowhere near perfect and common sense is not always obvious (we have hundreds of people claiming that the opposite). Instead of arguing in public how about we contribute some patches in devmanual to avoid similar problems in the future? -- Regards, Markos Chandras
RE : Re: [gentoo-dev] News item about Gnome 3.8
Imho we need a statement about systemd being the only supported option in the news item as well (ay least for now). Message d'origine De : Pacho Ramos pa...@gentoo.org Date : A : gentoo-dev@lists.gentoo.org Cc : gn...@gentoo.org Objet : Re: [gentoo-dev] News item about Gnome 3.8 El sáb, 19-10-2013 a las 10:32 +0200, Pacho Ramos escribió: Well, even if the stabilization is still waiting for two blocking bugs: https://bugs.gentoo.org/show_bug.cgi?id=474128 - for Orca 3.8 https://bugs.gentoo.org/show_bug.cgi?id=486278 - for getting a lvm2 version working ok with Systemd finally I think we could start preparing the news item. I attach one based in latest one from the times of 2.32 :D It only points to Gnome 3.8 upgrade guide as that guide is already pointing to Systemd guide for migrating (and explaining the Systemd need) A user replied to me suggesting to reword it to simply: Title: Upgrade to GNOME 3.8 Author: Pacho Ramos pa...@gentoo.org Content-Type: text/plain Posted: 2013-10-19 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: gnome-base/gnome-3.8 Display-If-Installed: gnome-base/gnome-light-3.8 Display-If-Installed: gnome-base/gnome-session-3.8 We are pleased to announce the stabilization of GNOME-3.8. Users are strongly encouraged to read the GNOME 3.8 Upgrade Guide to avoid any possible issues relating to the upgrade. Please read the Gnome 3.8 Upgrade Guide: http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide
Re: [gentoo-dev] official games repository
Markos, Markos Chandras wrote: This is not a great way to invite more users to participate. If you intend to make the game overlay and team a developer-only thing you are doing a great work. Everything in the Gentoo project is per definition strictly developer-only. I suppose that it's a function of having the project centered around a foundation. I understand that it is very easy to get tunnel vision once one is in, but please do remember that Gentoo is quite explicitly exclusionist. In some ways I think this is a really good thing. In other ways it's mind-numbingly restrictive. I do not pretend to have a solution to the problem that would make everyone happy. I don't think that such a solution can be found actually :) because different people require diametrically opposed things in order to be happy. Anyway, don't forget how the project works. Users can make themselves heard on mailing lists and in (most) IRC channels, but that is it. We are absolutely second-class citizens in the Gentoo community and transcending that class divide is anything but quick and easy. //Peter
Re: [gentoo-dev] official games repository
Tom Wijsman wrote: There is an alternative solution here; and that is to bring reviewed versions of them to the Portage tree or official games repository, and honor their contributions. That is a win-win situation for both of you. I'm afraid that's too naive. :\ I have significant experience from contributors in several other projects who aren't interested in higher quality standards than their own. They will infallably find a way to continue their work as they see fit, with the case in point being gamerlay. Someone interested in maintaining higher standards will need to maintain such higher standards on their own, experience shows that zero percent of that effort is absorbed by those contributors who are content with lower standards - they more or less explicitly state that they do not want to learn how to attain higher quality. Unless one has actually been in this position I think it may be difficult to understand how extremely demotivating it is to keep cleaning up after people who do not want to learn. It is neither sustainable for a single person nor for a team. If there's infrastructure to support it I'm strongly in favor of letting everyone do what they like to do, a sort of live and let live. The question is why high quality would matter. If there is a use case then I think it may be quite worthwhile to have an official, high quality, games overlay being worked on. I wouldn't spend a second on it personally, but that's just because I don't play games. :) //Peter
Re: [gentoo-dev] official games repository
On Mon, Oct 21, 2013 at 9:53 PM, Peter Stuge pe...@stuge.se wrote: Markos, Markos Chandras wrote: This is not a great way to invite more users to participate. If you intend to make the game overlay and team a developer-only thing you are doing a great work. Everything in the Gentoo project is per definition strictly developer-only. I suppose that it's a function of having the project centered around a foundation. I can't think of any reason that the Foundation would have anything to do with who can and cannot participate in anything related to Gentoo. Gentoo projects have involved non-developers from time to time. The documentation project even gives commit access to non-developers, and arch testers have elevated privileges in bugzilla. The way our current portage tree is set up basically forces us into an all-or-nothing security model for commit access - we don't have layers of integration testing to protect users from errors or abuses. Proxy maintainership is one way around this. I think there are many here who would love to see more non-developer contribution. Suggestions are always welcome, and those willing to put in effort to make the suggestions happen are probably even more welcome. Moving to git certainly won't hurt, but that won't automatically change anything either. Rich
Re: [gentoo-dev] official games repository
Rich Freeman wrote: This is not a great way to invite more users to participate. If you intend to make the game overlay and team a developer-only thing you are doing a great work. Everything in the Gentoo project is per definition strictly developer-only. I suppose that it's a function of having the project centered around a foundation. I can't think of any reason that the Foundation would have anything to do with who can and cannot participate in anything related to Gentoo. The reason I had in mind is indeed the all-or-nothing security model for the publications (ebuilds is what I had in mind, I should have written Everything I know in the Gentoo project..., sorry about that!) where even Copyright seems to have to be assigned to the foundation. Gentoo projects have involved non-developers from time to time. The documentation project even gives commit access to non-developers, Awesome! I'm really glad that I was wrong about that - but at the same time documentation tends to serve a bootstrapping function, and thus matter less over time. and arch testers have elevated privileges in bugzilla. I should have included bugzilla among mailing lists+IRC, users can indeed also have elevated privileges on IRC, but never equal to developers. It is radical exclusion and I'm reminded of it every time the #gentoo-dev channel mode catches my eye, painfully so if there's a discussion I could perhaps contribute to. Most of the time it is easy enough to say something privately to a relevant developer, but that's still very different from actual participation. The way our current portage tree is set up basically forces us into an all-or-nothing security model for commit access - we don't have layers of integration testing to protect users from errors or abuses. Proxy maintainership is one way around this. I considered mentioning it but I didn't because I think it's clear to everyone that it is indeed a workaround. I think there are many here who would love to see more non-developer contribution. Yes, I am absolutely sure that this is the case! But even though my blanket statement was incorrect, I guess the fact that I was wrong about this even after using Gentoo fairly actively for nearly 10 years means that it is not so clear to users if they can actually contribute in easy ways, and partially hostile documentation of course doesn't help. Suggestions are always welcome, and those willing to put in effort to make the suggestions happen are probably even more welcome. I for one consider the portage tree and the tools around it to be Gentoo's core value so I think writes to it becoming more accessible is the number one suggestion. Moving to git certainly won't hurt, but that won't automatically change anything either. I disagree there - it automatically changes what is effortlessly doable thanks to existence of helpful tooling and it also changes intuitive expectations as far as workflow goes. I do think that a world-writable Gerrit instance in front of a portage git tree will actually suffice to dramatically increase user participation - and of course bring significant developer review workload along with it! :) Everyone knows I'd like to see that happen, and I know that it is being worked on - I'm not in a hurry, but even so you're right that it still does not change the fact that only developers can submit commits from Gerrit into portage. As I already wrote I think there are both significant pros and cons to the developer-only approach, and because of how powerful and flexible Gentoo is there's no easy solution. As a case in point, TomWij made a mistake for an arch he rarely if ever uses. Gentoo is complex and also wonderful, and that means that contributing in the general case is not very easy. Simplifying the common case of x86/amd64 revbump (a world-writable Gerrit) will lead to more contribution, but what about the corner cases - it's impossible to know if I've actually tested my new ebuild on hppa if I just copypaste the old ebuild. I shouldn't need to communicate my testing out-of-band in a bugzilla or whatever and a thought I just had is that KEYWORDS may perhaps need higher temporal resolution than existing once per file.ebuild.. OTOH I don't think it's a good idea to require post-processing of the entire gentoo-x86 worktree to make it usable for portage. Tricky. //Peter
