Re: [gentoo-dev] Making the developer community more open
On Mon, 2006-03-20 at 15:45 -0800, Bret Towe wrote: perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev Taking this idea a bit further, what about proxy maintainers? There seem to be quite a few packages that are being effectively maintained by users on bugzilla, but are not in portage because they don't have a maintainer. A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. There could then be a bug for each such package where all the patches, ebuilds and version bumps could be posted. The developer who accepts the package could just take those ebuilds, maybe corrected if necessary, and commit them. If the ebuild breaks, it's up to the developer to fix it. If the package breaks, however, it would be up to the users on the bug to fix it, although of course the developer would be able to fix it if he or she could. If there doesn't seem to be anyone interested in keeping the package working anymore then it could be masked and subsequently removed as packages are now. If there are security problems and the fix is not trivial, it might be sensible to mask the package until someone can fix it rather than waiting for a fix to become available. If the developer working as the proxy disappeared, or retired, then the packages could be assigned back to maintainer-wanted (not maintainer-needed) but left in the tree until they broke, at which point they could be removed again unless anyone wants to pick them up. Similarly, if the users maintaining the package disappeared and the package broke, it could be masked and removed. This would seem to me to add more flexibility, and allow more ebuilds to get into the tree without breaking the tree or causing security problems. The only difference would be that the developer who took the package would not be responsible for making sure the program worked - that would be the responsibility of the users maintaining it in bugzilla. There should probably be some large, friendly warnings to inform anyone installing it that is the case, as well. What do you think? -- Jonathan Coome [EMAIL PROTECTED] Gentoo Forums Moderator -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
Hi Daniel, On 3/20/06, Daniel Drake [EMAIL PROTECTED] wrote: One of the bigger problems is that we have a huge user community who are keen on contributing, but we have such a high barrier for entry to the developer community. Quite rightly so - we're dealing with a live tree, so we can't give out commit access on the street. At the same time, I feel that we're missing out. Comparing Gentoo with some other large open-source communities that I am personally involved in, I feel that we're too closed. The two big problems are that non-devs don't know where to go to get involved, and if they want to do more than just chat, there isn't anywhere for them to go. I've been very happy with using svn+trac overlays to bridge this gap. They provide a sandbox for contributions to be shared and evaluated. They provide a place where I've been able to give commit access to non-devs, so that they can learn the ropes w/out threatening the Portage tree proper. They provide a place where people who just want to write docs for a single package can contribute. Overlays create a sense of participation that's lacking with Bugzilla patch submissions. Backed up with regular communication (I recommend not recruiting anyone who won't spend time in the IRC channels, but that's a personal preference), they help us get things done quicker. The downside with overlays at the moment is that they're scattered around the net, and if you don't know where to look they can be very hard to find. I've been talking with infra about providing overlays.g.o as a central hosting service for herd and individual developer overlays. Infra have been very supportive of the idea. I just need to free up some time to get the service launched. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
One of the bigger problems is that we have a huge user community who are keen on contributing, but we have such a high barrier for entry to the developer community. There are the arch tester[1] projects (x86, amd64, ppc, alpha (soon), and maybe others). Those lower the barrier a lot while still requiring some level of knowledge (passing the ebuild quiz). A lot of ATs eventually become devs. Maybe the various AT projects could be advertised more, like the x86 AT team was this week in GWN[2]. [1] http://www.gentoo.org/proj/en/base/x86/arch-testers-faq.xml#whoat [2] http://www.gentoo.org/news/en/gwn/20060320-newsletter.xml -Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
Bret Towe wrote: perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev Users can (and do) attach patches to any bug in bugzilla. When applying such patches, the committing dev hopefully checks the patch and makes sure it's clean, so he already is the kind of proxy you are asking for. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
On Tuesday 21 March 2006 07:05, Alin Nastac wrote: Yes, it is hard to find the right people. Yes, a big percentage of recruiting team's time will be lost on useless additions/removals. But the only solution is scaling the recruiting team to gentoo needs. IMO recruiting team is too small to cope with the current size of the project. Probably the biggest reason for the closedness of the project is probably that there are no official ways to become a dev that originate from the candidate. Most if not all new developers are asked whether they would like to become a developer. This method has the advantage of weeding out goldseekers and other people who should not be given access to the tree. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpKs3iSR2f2y.pgp Description: PGP signature
Re: [gentoo-dev] Making the developer community more open
On Mon, Mar 20, 2006 at 11:07:37PM +, Daniel Drake wrote: I'm looking for ideas - preferably big, drastic, shiny ones. Ignore any issues relating to migration away from our current system. What would be the _ideal_ way for Gentoo to handle contributions from anyone? (note that I'm dropping the user/developer community separation in that question, as the boundary between those could change in these ideas) How would an ideal recruitment process work, if there would be one at all? When I was a system administrator working with Gentoo I would've appreciated a way to interact with the other Gentoo system administrators. (ie gentoo-server). I would've liked it even more if I could've communicated with the Gentoo University Department System Administrators. When I say communicated I mean interacted with. Now that I'm an AMD64 laptop Gentoo user I would like a concise way of communicating back to my community the AMD64 users and specifically the laptop users. In fact I'd like to know what other people are using the Compaq Presario V2000Z AMD Turion64. I'd also like to know what software they're running on their laptops and if they consider it stable. What kernel configurations they're using. What functionality is broken and what needs to be fixed. I'd like an easy way to communicate with them, pass them notes about problems with packages. If I trust them a-lot then I'd like to use their binary built packages as well as allow them to use the ones built by me. I guess we'd create a sort of p2p mini-pocket of gentoo users with our relationship built upon trust. I imagined Gentoo on Win32, something like Cygwin. I maintained a computer lab filled with Windows machines. I'd like to install Gentoo Win32 on one machine. Install it on the next machine then tell that machine about the first. I'd like to install it on a third machine then tell it about the first or the second but have that third machine then know about both. I'd like to compile a piece of software on one of the machines then know that any of the other two will automatically get the binary version of the package from the one that compiled it because they trust that machine. The damage to unnamed others from the existence of a system like this would be quite excessive IMO. So I've structured this email as a want-list. However, I'm not oblivious to how this is implemented. I suppose the idea is to restructure Gentoo into a tiered community (as mentioned by other posters). Make it easy for tiers to birth and die (we might like a rhode island gentoo users group for instance, might not last for more than a year.) Maybe one tier is just me and my friends sharing our hacks, customizations, letting each other know about some exciting package, etc... I need my portage/emerge to act as a meta system that pulls from the various communities based upon how much I trust those communities. How do we get there from here? I suppose just start adding functionality to portage to support this. One part could be just expanding upon the portage overlay. It might be nice if portage became better defined so that we could implement it in a variety of programming languages (I'm into LISP programming for fun). Portage as a daemon? Another concrete feature would be to allow by convention a specific directory that could be created and used for applying patches during the build process (without modifying ebuilds). A place where portage will automatically apply that patch during the build of some piece of software. So lets say this feature of portage existed, perhaps I could further put the patch in various community portage overlays and others in that community could learn about that patch. I suppose its those sorts of massive optimizations/conventions/intelligence that I always appreciated about Gentoo and its packaging system. I appreciate that Gentoo is more hacker friendly and less Debian ivory tower. I think some of that is source-built distro versus a binary distro. Some of this is the gentoo-stats project that died. It'd be nice to know about the other people in my version of the Gentoo community. If I'd had statistics that MIT was using Gentoo on 5000 machines with each having an average up-time of 100 days (information gleamed from portage's community functions); then I could've marketed Gentoo better to my bosses. I'm rambling. Enjoy, Brandon Edens pgpxxA3l8ADJh.pgp Description: PGP signature
Re: [gentoo-dev] Making the developer community more open
Hi Brandon, Brandon Edens wrote: When I was a system administrator working with Gentoo I would've appreciated a way to interact with the other Gentoo system administrators. snip You seem to be purely describing interactions with the user community from a user perspective. My post was about the gap between the user community and the developer community, and how the developer community can open up. Thanks for the feedback - it's always interesting to read this kind of thing, but it's not what I'm looking for at this point. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
On Tue, 2006-03-21 at 13:09 +0100, Simon Stelling wrote: Bret Towe wrote: perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev Users can (and do) attach patches to any bug in bugzilla. When applying such patches, the committing dev hopefully checks the patch and makes sure it's clean, so he already is the kind of proxy you are asking for. -- maybe he more means having a working relationship with people rather than sending them to attach patches to bugzilla. make it more personal than clinical circumventing the requirement for an AT position, a casual i give you patches as i come across problems on my box, can you take care of them relationship for people who can and will contribute occasionally, w/o the time to take on a dev position w/o commit access (aka Arch Tester) like the people you hang out with on irc even, the ones that help other users, or the kind you see active on forums, take their occational patch/ebuild like less red tape, more acceptance of the occasional contribution how about that as proxy? Daniel Kind Regards, Simon Stelling Gentoo/AMD64 Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Making the developer community more open
On Mon, 20 Mar 2006 23:07:37 + Daniel Drake [EMAIL PROTECTED] wrote: | One of the bigger problems is that we have a huge user community who | are keen on contributing, but we have such a high barrier for entry | to the developer community. Quite rightly so - we're dealing with a | live tree, so we can't give out commit access on the street. A relatively easy way of lowering that barrier would be to provide good, up to date, example-oriented ebuild writing documentation. There's too much stuff that people need to know to write ebuilds that's not written down anywhere -- this not only makes it harder for users to write good ebuilds, but also leads to some of them being dissuaded when they're told that the only way to know what's policy is by having paid attention on the mailing lists for the past five years. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Making the developer community more open
On 3/21/06, Bret Towe [EMAIL PROTECTED] wrote: perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev That is imo a key feature: Get contributions back to the users easily It doe snot need to be the portage-tree .. but an official user-overlay or contrib-overlay would definitely help to get a lot of people involved. Other projects are providing similar infrastructure with very good results, see the Arch User Repository for example: http://aur.archlinux.org It would be great to have something like that available for gentoo-users. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
I'm not a gentoo dev (just a satisfied user), but I lurk on this list. I was at PyCon last month. I would estimate that about 40% of the people there ran linux on their laptops. The most popular distros were gentoo and ubuntu. (Not this is not a scientific study, just my observations from talking to people there). While I was there the person next to me starting hacking the ebuild classes to handles eggs (so he could emerge turbogears). I talked to at least 3 others who were running gentoo. I asked all of them if they had worked on portage. Most said No, the code is a little scary. (I'll concur with that sentiment, as the code doesn't feel very pythonic). If you want to attract more developers (python people), a few things are needed: * Portage documentation. How the innards work. There is very little docs/comments in the portage code * Unittests - without this how do I know that my change to portage didn't break someone else's corner case * Refactoring into a more pythonic style. Note that this is pretty hard without unittests. Take this as a grain of salt, from an observer, who believes that there are a lot of potential users (who know python), and who could easily contribute, if the bar was lowered a bit. (Or steps were provided to reach a little higher ;)) -matt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
On Tue, 21 Mar 2006 00:58:07 +0100 Stefan Schweizer [EMAIL PROTECTED] wrote: | It doe snot need to be the portage-tree .. but an official | user-overlay or contrib-overlay would definitely help to get a lot of | people involved. The problem is security. It's extremely easy to sneak some very devious code (e.g. that'd grant remote root access and post an IP somewhere) into an ebuild that'd be very hard to spot by anyone who doesn't realy know what they're doing. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Making the developer community more open
Monday, 20. March 2006 23:07, Daniel Drake Ви написали: I'm looking for ideas - preferably big, drastic, shiny ones. Ignore any issues relating to migration away from our current system. What would be the _ideal_ way for Gentoo to handle contributions from anyone? Any ideas? Heh, and that bug almost got closed for the 2nd time recently :). Please take a look at #1523 (note the number ;)), it addresses essentially this issue, or pretty similar. Half of the ideas from there we got done already, but another half is nowhere near. I'd even say they need some drastic redesign first, before they should go anywhere near glep or nearing implementation. For one infra will not be happy at all about more major stuff, but you said don't bother, just give me ideas, so here you go ;). Then some subprojects that are necessary to get that done in full were talked about and restarted a few times, but eventually died every time. I am talking about gentoo-stats and similar.. Frankly, I haven't thought much about this for the last two years or so, being busy with issues of the day mostly (and undergoing big real life transitions :)), but nonetheless kept the bug open, as from my experience this issue resurfaces every year or so. So, please take a look. Hopefully you will find something usefull.. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
A quick update. Please use this link for the proposal instead of the one listed in original post in the bug: http://dev.gentoo.org/~george/epsp/proposal.html The files have been migrated to my gentoo space, as proper. I just added comment to the bug and I'll put up some remonder at the place the original link points to (but I am no longer at that place, so I cannot predict for how long that will work..) Please take a look at #1523 (note the number ;)), it addresses essentially George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
George- Not sure if you have seen this or not. Check out Conary [1] from rPath. Think of it as Rpm+Ebuild+Distributed. It's done by some people who used to be at Redhat and in one of the whitepapers, they specifically mention portage/ebuild. -matt 1 - http://wiki.conary.com/FrontPage On 3/20/06, George Shapovalov [EMAIL PROTECTED] wrote: A quick update. Please use this link for the proposal instead of the one listed in original post in the bug: http://dev.gentoo.org/~george/epsp/proposal.html The files have been migrated to my gentoo space, as proper. I just added comment to the bug and I'll put up some remonder at the place the original link points to (but I am no longer at that place, so I cannot predict for how long that will work..) Please take a look at #1523 (note the number ;)), it addresses essentially George -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
Well, I think a lot of what I've been thinking recently has already been said by Daniel. I'm actually in the middle of being inducted and I'm just concerned that I'm going to get extra responsibility without any real positive aspects for me. I don't really *want* access to check into portage, I don't know what I'm doing (yet) and I'm not certain I can invest the time to learn all the precise policy to ensure I don't make a mistake, or worse put up with the stress of worrying I'll do it wrong and affect the entire gentoo vmware-using userbase. What I tend to do is make ebuilds for things that I want to try out or things that are broken, and I'd really like to just keep on doing that, but have it more accessible to the rest of the userbase. I think the idea of a proxy is a good one. I don't know about a whole user repository though, because as Ciaran pointed out, one bad apple and everybody gets rooted. No one would trust it, so it wouldn't be worth it anyway. * It'd be a good idea to have a larger group of devs not dedicated to a particular project, but who can take user submitted ebuilds, vet them for nastiness, and submit them. They'll be officially contributed ebuilds, they won't get updated until either a dev offers to take them on, or the community offers to fix them. * I think also a larger number of bugzilla scouring devs could push through well tested (lots of positive feedback, no negative feedback) patches that the maintainers for whatever reason (aren't there, forgot about it, don't have the time) just aren't putting through. That would require bending the maintainer etiquette a bit though. * I guess a *quick* concise policy guide would help. Separate from the ebuild guide which is trying to teach you *how* to write ebuilds, this policy guide would tell you what MUST and MUST NOT happen in a good Quality Assured ebuild. For instance, if the various and sundry checks in repoman could be extracted for people to run over their own overlays without all the main portage cvs machinery in there, it would help them get *much* better trained in what makes a good ebuild and what doesn't. If it can already do that, then it needs better documentation. * Finally the mentoring scheme could perhaps be more streamlined. So rather than having an all-or-nothing gentoo developer membership. Those developers being mentored have a repoman-like interface that works almost exactly the same way, but instead of putting directly into0 the tree, it would submit to a holding area where an experienced ebuild writer can either send it back to them with comments, or put a tick next to it and pass it into the main overlay. This then would allow people to work up to becoming a full dev, and take their time over it. It would also offer a kind of buffer area for people who just want to help for a few months, their privilege levels don't have to rise too high. So these are some ideas. Sorry, I was trying to get these out concisely but tripped on my tongue somewhere along the way, hope they help generate some ideas... Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
m h wrote: I'm not a gentoo dev (just a satisfied user), but I lurk on this list. I was at PyCon last month. I would estimate that about 40% of the people there ran linux on their laptops. The most popular distros were gentoo and ubuntu. (Not this is not a scientific study, just my observations from talking to people there). While I was there the person next to me starting hacking the ebuild classes to handles eggs (so he could emerge turbogears). I talked to at least 3 others who were running gentoo. I asked all of them if they had worked on portage. Most said No, the code is a little scary. (I'll concur with that sentiment, as the code doesn't feel very pythonic). If you want to attract more developers (python people), a few things are needed: That depends on how they contribute, I personally don't want random python master bob contributing pieces to portage itself. Portage things are not necessarily as simple as people make them out to be. Even developers who know the code well make mistakes in adding and removing code. As solar once pointed out the only man I trust to touch the resolver is Jstubbs. I realize thats a bit elitest...but at the same time...I am overly cautious ;) However we always accept patches and I think we get most of them critiqued, sometimes it may take an extra prodding mail or two. We usually don't implement your features for you though ;) * Portage documentation. How the innards work. There is very little docs/comments in the portage code Someone has to write them; I have some of it done, it's been a longtime project that I've worked on off and on; I actually had more done last year and I know kutsuya did some as well. However these are not particularly interesting..and no one wants to document the 2.X branch. * Unittests - without this how do I know that my change to portage didn't break someone else's corner case No one is writing unittests for the 2.X branch * Refactoring into a more pythonic style. Note that this is pretty hard without unittests. See above :) Take this as a grain of salt, from an observer, who believes that there are a lot of potential users (who know python), and who could easily contribute, if the bar was lowered a bit. (Or steps were provided to reach a little higher ;)) -matt signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making the developer community more open
On Tuesday 21 March 2006 12:32, Alec Warner wrote: m h wrote: I'm not a gentoo dev (just a satisfied user), but I lurk on this list. I was at PyCon last month. I would estimate that about 40% of the people there ran linux on their laptops. The most popular distros were gentoo and ubuntu. (Not this is not a scientific study, just my observations from talking to people there). While I was there the person next to me starting hacking the ebuild classes to handles eggs (so he could emerge turbogears). I talked to at least 3 others who were running gentoo. I asked all of them if they had worked on portage. Most said No, the code is a little scary. (I'll concur with that sentiment, as the code doesn't feel very pythonic). If you want to attract more developers (python people), a few things are needed: That depends on how they contribute, I personally don't want random python master bob contributing pieces to portage itself. Portage things are not necessarily as simple as people make them out to be. Even developers who know the code well make mistakes in adding and removing code. As solar once pointed out the only man I trust to touch the resolver is Jstubbs. I realize thats a bit elitest...but at the same time...I am overly cautious ;) The resolver as it stands now is not overly difficult. One does really need to know it back to front though. I should really make splitting it out and documenting it my big project for 2.2. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
Daniel Drake wrote: We have a large expense on both sides when adding a developer to the project. I personally have lost developer candidates, undoubtedly more technically experienced than myself, who simply did not have the time to go through a month-long recruitment process which involved studying various documents not even relevant to the small area they would be contributing to. On the other side, it's a fair expense to add a developer to the project due to all of the quizzing/assessing/account-creating/access-elevation/... Technical ability isn't the only requirement for gentoo devs. They also must be motivated individuals and these high barriers you are talking about test this quality of the candidates. If they quit just because recruitment process is long, what makes you think they will stay active long enough to actually worth adding them to dev corpus? Additionally, a significant percentage of developers who have joined recently have gone AWOL after a few months. That hurts us, given the expense we went through recruiting and adding them, and the time needed to reverse that and retire them. Yes, it is hard to find the right people. Yes, a big percentage of recruiting team's time will be lost on useless additions/removals. But the only solution is scaling the recruiting team to gentoo needs. IMO recruiting team is too small to cope with the current size of the project. signature.asc Description: OpenPGP digital signature
