Gentoo Recruitment: How do we perform?

October 25, 2012 · Posted in Gentoo, Linux 

A couple of days ago, Tomas and I, gave a presentation at the Gentoo Miniconf. The subject of the presentation was to give an overview of the current recruitment process, how are we performing compared to the previous years and what other ways there are for users to help us improve our beloved distribution. In this blog post I am gonna get into some details that I did not have the time to address during the presentation regarding our recruitment process.

 

Recruitment Statistics

Recruitment Statistics from 2008 to 2012

Looking at the previous graph, two things are obvious. First of all, every year the number of people who wanted to become developers is constantly decreased. Second, we have a significant number of people who did not manage to become developers. Let me express my personal thoughts on these two things.

For the first one, my opinion is that these numbers are directly related to the Gentoo’s reputation and its “infiltration” to power users. It is not a secret that Gentoo is not as popular as it used to be. Some people think this is because of the quality of our packages, or because of the frequency we cause headaches to our users. Other people think that the “I want to compile every bit of my linux box” trend belongs to the past and people want to spend less time maintaining/updating their boxes and more time doing some actual work nowadays. Either way, for the past few years we are loosing people, or to state it better, we are not “hiring” as many as we used to. Ignoring those who did not manage to become developers, we must admit that the absolute numbers are not in our favor. One may say that, 16 developers for 2011-2012 is not bad at all, but we aim for the best right? What bothers me the most is not the number of the people we recruit, but that this number is constantly falling for the last 5 years…

As for the second observation, we see that, every year, around 4-5 people give up and decide to not become developers after all. Why is that? The answer is obvious. Our long, painful, exhausting recruitment process drives people away. From my experience, it takes about 2 months from the time your mentor opens your bug, until a recruiter picks you up. This obviously kills someone’s motivation, makes him lose interest, get busy with other stuff and he eventually disappears. We tried to improve this process by creating a webapp two years ago, but it did not work out well. So we are now back to square one. We really can’t afford loosing developers because of our recruitment process. It is embarrassing to say at least.

Again, is there anything that can be done? Definitely yes. I’d say, we need an improved or a brand new web application that will focus on two things:

1) make the review process between mentor <-> recruit easier

2) make the final review process between recruit <-> recruiter an enjoyable learning process

Ideas are always welcomed. Volunteers and practical solutions even more ;) In the meantime, I am considering using Google+ hangouts for the face-to-face interview sessions with the upcoming recruits. This should bring some fresh air to this process ;)

The entire presentation can be found here

Comments

50 Responses to “Gentoo Recruitment: How do we perform?”

  1. Betelgeuse on October 25th, 2012 7:43 pm

    Good stuff, let’s deliver.

  2. Judson on October 25th, 2012 7:59 pm

    Speaking as a “gave up” I can say: post filing an original bug, there wasn’t anyone in particular who worked with me, although there were a few people on IRC who were very helpful in short bursts.

    There’s also the issue that the gentoo-dev documentation is both offputting and inconsistent. There are lots of dire warnings about how hard this is going to be, and then the documentation about ebuilds is incomplete, and refers to several generations of how ebuilds work.

    I’m an experienced Gentoo user, systems engineer and software developer, and that much runaround was frankly not worth my time. I’d love to be contributing to Gentoo, but the current process of *development* much less recruitment is really a pain in the neck.

  3. Francois Bissey on October 25th, 2012 10:01 pm

    Hi, I must echo judson somewhat. I am involved in gentoo by the science overlay and I am the main developer for the sage-on-gentoo overlay.
    With my mentor we opened a bug for me in 2010 and yes the initial waiting time killed me a little bit. Plus when the recruiter arrived he collided with about 200-250 script and assignment to mark. And life became very wild for a bit after that.

    I decided to reopen my bug to give more direct help, as bicatali “if you were a dev you could just commit that atuff” he is also eager to hand the scientific python stack. While the recruiter has shown up life and work has picked up and while I am somewhat experienced in ebuild development I am dragging my feet to fill in the quiz again ( I must some stuff are clearer in the new version of the quiz, the clue help you not to misinterpret the intent).

    I understand the need for quality dev recruitment but another way would be nice for people who can demonstrate real field experience.

  4. Judson on October 25th, 2012 11:07 pm

    One thing that strikes me on reflection is that Gentoo is very strange in the way it brings developers onto the project. The rest of the open source world has some variant of “submit patch” -> “patch approved” -> “get commit bit.”

    A DCVS (like git, I suppose) makes that even easier to do, what with pull requests and all the rest.

    I’d forgotten all about the dev quiz – I’ve walked out of job offers when I was presented with a written test. It signals that the position is expecting someone very much junior to me. It’s with great charity that I don’t read amazing disrespect.

  5. Sam on October 26th, 2012 12:17 am

    I’d like to suggest that this is because the idea that “people” need to be trusted instead of what they do. So, you have this lengthy “certification” process that puts people off (at least I was).

    My suggestion is to give up this recruitment altogether. But have anyone contribute ebuids, bug fixes and have their work reviewed. Have some type of reputation mechanism to quickly accept work from those who have produced quality work. Mentoring can then take place to educate those who are eager, but produce work that needs to be improved.

    Sort of like the philosophical difference difference between distributed SCM vs centralized SCM.

    I did write about this a long while ago in Gentoo forums. I’ve been a longtime gentoo user, filed a few bugs, dabbled with some ebuilds. Although I wanted to contribute, I’m not willing to jump through the current set of hoops to do that. I bet I’m not the only one.

  6. nico on October 26th, 2012 1:28 am

    I like the Arch approach. Three official repos and one unofficial. How much access someone has is based on their rank. That way becoming a developer isn’t one big jump.

    Also, the web interface for the AUR is awesome.

  7. mkyral on October 26th, 2012 7:53 am

    Hi,
    I’m using Gentoo for more than five years (I don’t know exactly). I’ve created several ebuild and put them to bugzilla. In past, I though to become a gentoo developer, but everything looked very complicate and time consuming, so I decide to don’t try.

    Currently I have family, another hobbies and not enough time to become a Gentoo developer. From time to time, I’m translating some programs that I’m using, filling a bug when I found some.

    I think, the main issue is that there is not enough new students. They have many “better” possibilities to spent their spare time.

    Even it, thanks all Gentoo devs for their work. Currently Gentoo “just works”. I had no need to fill a bug for several months.
    Thanks

  8. Markos on October 26th, 2012 7:18 pm

    @JUDSON & FRANCOIS BISSEY

    That was the case in the past but now we are able to pick up recruits much faster. The documentation is not ideal but it not as bad as you may think. The devmanual has pretty accurate information

    @SAM

    Yes the idea is to not have a strict recruitment process but to dynamically adjust it for each recruit. This will be based on his knowledge, experience and area of interest

  9. Judson on October 26th, 2012 9:03 pm

    @MARKOS

    This is an opinion re-affirmed in the last 3-6 months, trying to get Rubinus into the portage tree. (I think there’s a simplest-possible ebuild in there now, that at last check didn’t work for me.)

    Ahem: “the documentation isn’t as bad as you might think.” I’m telling you: my experience was that I couldn’t find answers to questions about how ebuild functions worked, including and especially inherit (or anything at all about what ebuild tools you could inherit, or the feature they bring in.)

    And it may be that those answers are out there *somewhere*, but the documentation problem is about finding the answers – I found documents on the Gentoo pages that looked official, and they weren’t helping.

    In the broader context, there’s a lot of Gentoo documentation that is still live but really outdated. There would be a lot of benefit to be had to updating some of it, and taking the rest down in favor of more current versions.

    BUT: all of that would take some serious editorial work… by a Gentoo dev… and recruiting is hard.

  10. Markos on October 26th, 2012 9:22 pm

    Agreed. That is why I say that practical experience with ebuilds is more important that just reading documentation. The more you get involved the more things you learn ;)

  11. Judson on October 26th, 2012 9:33 pm

    So, you started an article on “we’re having trouble recruiting,” and now you’re defending the current practices?

    Here’s a big problem, as I see it: the Gentoo recruitment process as it stands is justified on the basis of wanting only high quality ebuilds in the portage tree. “High quality” includes conformance to a series of style guides.

    But the required style (as well as “how things work” and “the best way too…”) is codified, essentially, through an oral tradition of mentoring. Does everyone who might serve as a mentor remember everything about preferred style and the ebuild system all the time? Because otherwise, those standards are going to drift.

    Frankly, the current system of recruiting developers is pretty outdated, and Gentoo is suffering for it. It’s not just that “it’s too hard” to become a Gentoo dev – it’s *so much easier* to become e.g. a Rails core team member. And certainly to contribute something to most modern OSS projects than it is to contribute to Gentoo.

  12. Markos on October 26th, 2012 9:53 pm

    Indeed the recruitment process is a pain and this is why I wrote this post so I can gather ideas on what needs to be done and what needs to be improved. You said that not all mentors remember the standards and this is exactly why we have the personal face-to-face sessions so we can make sure that everyone knows these standards

  13. Pacho on October 26th, 2012 10:03 pm

    Maybe forums.gentoo.org moderators could help recruiting team to find people willing to become a dev :/

  14. Judson on October 26th, 2012 10:03 pm

    Face-to-face sessions? So if I’m in Los Angeles, is there anyone here to have a f2f with?

  15. Markos on October 26th, 2012 10:07 pm

    I should have used quotes. I mean IRC chat, skype or G+ hangouts.

  16. Francois Bissey on October 27th, 2012 8:01 am

    I am not sure why i was included in the answer about documentation as I haven´t commented on it. I only commented on the quizzes. The latest version I downloaded has clues that make the intent of the question clearer. My own opinion on the documentation is that it is mostly there but the indexing may be lacking. Google is your friend just add ¨gentoo doc¨ to your query.

    I am glad that you don´t want a real life face to face! From New Zealand it would be quite difficult. Although I have contacts with the gentoo devs across the Tasman sea in Australia.

    In my case I have producing, editing, improving ebuilds bug filling patch submitting constantly over the past 2 or 3 years. While I haven´t signed for the proxy maintaining program I am the real person looking after a couple of ebuilds.

    I just cannot get to complete the recruitment process as is, which annoys my peers who have and would rather have me commit stuff directly rather than flagging them with patches.

  17. Markos on October 27th, 2012 8:32 am

    I understand what you say. So please tell me, what the ideal recruitment process would be for you? How can I make sure you know all the required bits and that you wont break the tree two minutes after I five you access? If quizzes are too much pain, then what would you prefer as an alternative?

  18. Judson on October 27th, 2012 8:51 am

    Put the portage tree and the official docs into git.

    If I’m interested enough to build an ebuild, I fork gentoo/portage, add the ebuild and issue a pull request.

    If you’re reviewing my PR and see an issue, you tell me what the issue is. If I don’t understand the issue, by policy you point me to a place in the docs that explains the issue. If you can’t point to it, our IRC conversation gets put into the docs as a starting place for proper documentation.

    If I’ve submitted (enough, significant) PRs, existing devs can grant me commit permissions over the repo, and now I can commit directly or merge PRs.

    The other possibilty is that *no one* directly commits to master – everyone produces PRs, and dev status is about whether you can merge PRs – every PR is reviewed by someone other than it’s committer before being merged.

    Rejected PRs always come with an #anchored link into the ebuild docs that explains the reason for the rejection.

    Possibily, the master/HEAD branch of portage isn’t the production branch, and something like tinderbox is used to confirm the state of master before merging to production, which is what gets pushed to mirrors for rsync.

    This is basically a slight variation on modern DVCS based software dev practices, which work very well for large software projects.

  19. Francois Bissey on October 27th, 2012 8:53 am

    I must say I am not sure. I understand the quality requirement and i wouldn´t pretend to be perfect – no one is really.
    The only thing I can say is that for my current job I have been phone interviewed twice – 30 mn each time [twice was an oddity of the situation I think they would have taken me after the first one] and that felt less painful overall.
    For what its worth I am currently user support/sys admin at a HPC facility and my involvement in Gentoo probably helped getting the job.

  20. Markos on October 27th, 2012 8:58 am

    Yes but pull requests on cvs don’t work as you may expect. It is a real pain to ‘pretend’ it works just as good as git does :)

  21. Markos on October 27th, 2012 9:00 am

    This is similar what I am about to propose to the team. No more quizzes. The mentors will train the recruits the way they want. Then they will hand them over to the recruiters. We will do 1-2 mini review sessions. If everything looks good then we grant access. The mentor will be responsible for your commits for 2 months (currently is 1). If during the sessions we see that you lack some knowledge, we hand you back to the mentor.

  22. Francois Bissey on October 27th, 2012 9:20 am

    Ha… and when do we move the main tree to git? I must say that´s possibly the most frightening thing now that I have some experience with git and hg – having to have to go back to cvs!

    I like the idea of apprenticeship. Which is effectively what you suggest Markos -and what a phd effectively is as well. Overlays help a lot for mentoring, the science overlay is now on github and we got to review stuff of new comers now. That´s interesting and while you may have an official mentor a whole team may get involved in the education.

  23. Judson on October 27th, 2012 9:32 am

    I’d say that’s a stronger argument to move off of CVS than anything else. As if one needed a reason :)

    Several overlays use DVCS’s – I don’t see why main portage couldn’t. (I’d make the pitch for monotone, but that is an entirely different kettle of fish.)

  24. Pacho on October 27th, 2012 9:45 am

    I think we all agree on moving to git, the problem is that there are still some unfixed problems preventing us from migration:
    https://bugs.gentoo.org/show_bug.cgi?id=333531

    Any help with blocking bugs is welcomed of course :)

  25. Judson on October 27th, 2012 11:00 pm

    Do I have to be a dev to help with the git bugs? :)

    Seriously, though, is there a git policy proposal to review? For instance, the “we need a Gentoo git tutorial” is all about “we need to express how *Gentoo* uses git, not the general git use case.”

    I’m not sure I understand the hooks requirements – there’s one to confirm that things are signed properly – is that “the manifest for ebuilds is signed with the key as represented?” – and another for git -> rsync…

  26. Markos on October 28th, 2012 9:18 am

    The git migration is handled in the gentoo-scm mailing list and in the open bugzilla bugs. This presentation
    http://miniconf.gentoo.org/presentations/miniconf-2012-infra-robbat2.pdf

    says exactly what needs to be done to move to git. But, in the meantime, the recruitment process is not (and should not) be related to what DVCS we have so this is a bit offtopic

  27. non-gentoo-user on October 29th, 2012 5:15 am

    Wow, is Gentoo still going?

    Don’t take this the wrong way, but, you’re wasting your time. Unless you want to keep working on a hobbyist distro; that’s way harder than it needs to be; that will never ever be anything other than a tiny niche distro; with an ever deceasing user base.
    To be honest – other distros could probably do with your undoubted expertise. And no, I don’t mean Ubuntu.

    Just a thought.
    (I’ve been using Linux since 2002, just in case you’re wondering…)

  28. non-gentoo-user on October 29th, 2012 5:16 am

    Sorry, that should read “ever decreasing userbase”, not “ever deceasing”.

  29. Markos on October 29th, 2012 8:38 am

    How is this comment related to this discussion? Please refrain from trolling

  30. Josh K on October 29th, 2012 7:26 pm

    I’m glad to see that Gentoo is re-thinking is development recruiting process. I’ve been using Gentoo off and on since the pre 1.0 days, and the one thing that I personally have always felt is that the Gentoo devs (much less the process) had the old (and maybe current?) Debian problem of being somewhat elitist and sometimes flat out jerks.

    I know I have spoken to more than one person throughout the years that refused to go through the process because in addition to the very long process, they were also constantly talked down to.

    That being said, I have not been even remotely active in the community for many years, so hopefully this has changed and is no longer an issue. I wish you guys and Gentoo the best of luck in streamlining the developer recruitment process and continuing to improve the overall distribution.

    I am in no way calling anyone out or implying anything (no lines to read between:) ) but I thought I would bring it up just in case there is an underlying X factor that you guys were missing.

    @Non-Gentoo-User: If you don’t use Gentoo, why would you even care what the developers are doing? If you think it’s harder than it needs to be, then you don’t understand the philosophy behind Gentoo in the first place and you would be better served by another distribution.

  31. David Stanek on October 29th, 2012 11:41 pm

    In my case I felt insulted by the dev running an IRC meeting for the Python maintenance group. He was commenting about the lack of the official team showing up and the fact that the room was filled with “just a bunch of users”. He went on ranting about not getting help from anyone and mentioned the names of people in the chat that he felt were helpful. I submitted several ebuilds before that point and got a lukewarm response. After the comments in chat I decided my time was better spend elsewhere.

  32. Markos on October 30th, 2012 8:43 am

    This kind of behaviour is very common in every big opensource project out there

  33. Josh K on October 30th, 2012 4:58 pm

    While sadly that is a very true statement, there are also quite a few large open source projects that do not have/tolerate this kind of behavior.

    That being said, your statement illustrates exactly what I was talking about. Instead of potentially looking at the problem of some developers acting like children, you accept it. If everyone continues to accept that behavior, it continues to get worse, Gentoo’s reputation drops, and possibly it’s user base. While many people lose in this scenario, the only one that wins is the non-professional person that started the whole mess in the first place.

    My personal reasons for never doing any Gentoo specific work is:
    1. Too many politics
    2. Recruitment process is painful, bureaucratic, and crazy time consuming. It’s a Linux distribution, not a Stonemason’s Lodge.
    3. Too many developers with crap attitudes

    In your article you asked for potential pitfalls that Gentoo recruitment may be running into so I have provided you with items that I know hinder your recruitment process. I have provided you with the information I have, do with it what you like.

    Whether the powers that be within Gentoo decide to do anything about it or not is another story, but either way, thank you for taking the time to read my opinions on the subject. :)

  34. Markos on October 30th, 2012 5:48 pm

    I don’t disagree. I am just saying the certain people behave like that. We can’t force them to be social and this is not a school to teach them manners. The politics and the bureaucratic recruitment process is a problem indeed but unfortunately I can’t change it myself. I can only gather feedback which then I will present it back to the recruiters team for us to decide what to do.

  35. Judson on October 30th, 2012 10:36 pm

    “We can’t force them to be social and this is not a school to teach them manners.”

    Absolutely correct. The grown up version is: you don’t tolerate it, and you eject those members who can’t behave. That’s a hard lesson for geeks to learn, but if Gentoo is going to be a professional distro, it has to behave professionally.

  36. Judson on October 30th, 2012 10:37 pm

    This is turning into an open forum on “how Gentoo policies should work.” Are those of us who are “mere users” just shouting into the wind here? Is there a better place to have this conversation?

  37. Markos on October 31st, 2012 8:28 am

    probably the gentoo-project ML but don’t expect much besides the usual “Yeah yeah this is a problem we must fix” and then silence :)

  38. Alex on November 1st, 2012 7:42 pm

    IMHO, a advise from a good HR Manager from tech area, would be *very* usefull to find the best way to create a process to recruit and maintien Gentoo Devs.

  39. Alon Bar-Lev on November 12th, 2012 7:16 pm

    Hello,

    I was a developer (alonbl@gentoo.org), and left because of people back-then who were uncooperative, and not in favour of the user community. This results in the trend now, as you outlined.

    The many of Gentoo developers must change their mindset to be much more user proactive, fix broken packages in sane timeline, respond to bugs etc…

    Take for example the latest release media that is totally broken, so users cannot install Gentoo for at least 4 months.

    I am mostly help in reporting bugs with patches (search: alon.barlev@gmail.com)

    It is amazing how this culture is kept even when new people joins… I guess the problem is that no enough people join.

    I don’t mind return and help out, but I have less time on my hands…

    Alon

  40. Pacho on November 12th, 2012 9:30 pm

    What does occur with broken release media? (bug?), I don’t know much about how release media is prepared but will try to review the problem if possible.

    Personally, I try to fix things fast enough… but it’s hard to push all developers to do the same and maintain only the amount of packages they are really willing to maintain. We try to fix the situation… but it’s harder than it looks at first :S

  41. Alon Bar-Lev on November 12th, 2012 11:07 pm

    The problem is the attitude… not the load.

    Scan the bugs over 3 months, with patches (solutions), and try to explain why not applied.

    This is just an example of recent:
    https://bugs.gentoo.org/show_bug.cgi?id=437480
    https://bugs.gentoo.org/show_bug.cgi?id=421839
    https://bugs.gentoo.org/show_bug.cgi?id=437320

  42. Alex on November 15th, 2012 1:03 am

    So from “Bleeding Edge” we are basically down to just “Bleeding” ?

    While I’m not an HR Manager – I’m one of many colleagues that might interview you if you applied for a job at Booking.com – and for the past couple of years we are growing ~60% per year in terms of IT staff.

    Due to the way we do work that involves constant rollouts (https://github.com/git-deploy/git-deploy) – it means developers need to be good both technically and from the business side of thinking.

    And actually the biggest struggle is the fact it’s a Perl shop – and for those not aware let’s put the perspective – Perl is about as popular as Gentoo.

    So we actually hire people with any language (well OK – any dynamic language) development experience and at least basic business sense – and they pick up Perl at work.

    But even then – from day one technically you can push stuff to trunk and roll it out the next minute – and I’ve assisted at least one colleague doing a rollout on his first day (ok he didn’t have any commits yet – but he was rolling out other peoples commits) …

    And I often run into “rejected (non-fast forward)” even with “git pull –rebase && git push” due the sheer amount of commits constantly pushed by ~125+ developers – so basically you might be rolling out *anything*…

    Anyway, my point is that a company that’s part (majority actually) of at the moment 30+ Billion $USD publicly traded PCLN Inc. – where every minute of downtime revenue lost makes your head spin – can/does give full trust to anyone who passed the job interview (~30min phone and ~3h face to face process + time investment for paid visit to Amsterdam for F2F) .

    And open source project, that was “the hot thing” 10 years ago and is now struggling with finding contributors … can’t pull it’s shit together and make it almost trivially easy for anyone to fix something and submit a patch that someone (with perhaps a bit more “trust” than the first person) can quickly review and apply – or use some other form of “staging” stuff before they are in real/main portage …

    I don’t know what’s the hold there?

    “Old guys” in fear of loosing grip/control or feeling less unique/3l33t. If there is going to be a person taking your spot – well in most hierarchies it means current folks go to next level…

    Or more likely inertia to change or feeling that it’s a big task (and current status is not “that bad”), or it’s too vague?

    Well IMHO it is worse than “that bad”, and if the task is really too big then you are doing it wrong: What are the smallest things you could do?!? What are the things that would make most difference? Are there any intersections between the two? And only way for it not to be vague is to actually start working on it, not just think/plan…

    I also know how annoying getting same questions over and over from new people can be (I’ve on-boarded more people than I can remember). And maybe that’s the reason for look down on new people …

    Well for those “looking down on others … try to recall how you felt when you were starting … If it still doesn’t help, then probably your on-boarding manual/handbook/process sucks – so write down FAQ containing Q/A that are annoying you the most, simplify the process – or as last resort exempt yourself from on-boarding people.

    And if you are so resentful that you just feel the urge to look down to people – seek professional mental help.

    To people that DO want to change something (and are at a position they perhaps they could) – my advice as a dev working along the lines of people that designed and built most of what you are working on. Step up – take ownership, ask for advice/support, but even without it – just do it!

    Once you have something (ANYTHING) it’s easy to look and compare what’s working and what’s not, and what needs to be improved …

    I’ve waited on people that are better suited to do something compared to me – but once we are at the point where I can’t really wait no more – I just do it to the best of my abilities (and advice from them and others).

    If it works – awesome! If it’s broken – (after git-deploy rollback) you basically push/rush a bit the original person. But either way – at that point there are two persons with quite some knowledge/responsibility on whatever are we talking about.

    As of the Gentoo “hiring” process itself – I’ve took a look and got de-motivated. Looks complicated and vague – and all that for the light at the end of a $x weeks tunnel – that I don’t really know if I’ll have time for, or like for that matter…etc.

    And yes it’s also “Once you go git – you can never go back” – same as once you go Gentoo … never say never.

    How about giving people a dry run, with immediate taste of it – and instant feedback? Say “A quick guide on how be a Gentoo dev”, followed by trying to resolve some of the simpler bug reports.

    And the other one that’s often happening – “But there isn’t anything I (alone/myself) could do!” – ok, but let’s just pretend for a second that you could (had permissions, resources …etc)… What would you do if you “could”? What do you need in order to be able to do it?

    while(1){ release(‘early’); release(‘often’); make_it(‘fun’); think(‘outside of the box’); }

    Kidding aside – this type of stuff seems like bullshit “http://www.gentoo.org/doc/en/cvs-tutorial.xml, A similar tutorial for git is a must.”.

    You can’t really write it until you switched to git, and you can’t switch to git until you wrote that tutorial… So you just infinitely loop there?!?

    How about we just switch to it – and then deal with problems once they arrive? And along the way fill in the docs as well …

  43. Pacho on November 18th, 2012 2:44 pm

    @41, because nobody was able to go ahead and commit the fixes, also, I remember missing /run problem and the main problem was that, at first, was difficult to know the exact culprit.

    I have talked with Markos about creating a team (or reusing maintaine-needed/proxy-maint teams) for commiting bugs with known fixes and tagged with “Inclusion” KEYWORDS by maintainers… the problem, as usual, is that there are not enough people to do that (I would join to that effort, but that would need to be done when I have done maintainance work on gnome stuff, dotnet, retirement and treecleaners, maintainer-needed…)

    What we need is more people willing to do that kind of work (fixing “general” packages). Wouldn’t you be willing to return for doing that kind of work with us? :)

  44. Alon Bar-Lev on November 18th, 2012 9:05 pm

    @43: As I wrote, I have no problem to return and help out.

    I can maintain these package I use, or these that have interest, I have some what less time now.

    However, I do not intend to fight again with maintainers that not fix their bugs. There was several examples in the past in which I fixed issues of unresponsive maintainers and then got devrel talks because I actually fixed the issue.

    Examples of trivial bugs that can be fixed:
    https://bugs.gentoo.org/show_bug.cgi?id=419445
    https://bugs.gentoo.org/show_bug.cgi?id=379583

  45. Markos on November 18th, 2012 9:55 pm

    Hi Alon,

    I am a dev for 4 years and I don’t remember you, so you probably left before I join. I can assure you that nowadays devrel is rarely involved in such cases anyway. proxy-maintainers tend to fix bugs/apply fixes/bump etc if they find something that is unmaintained and a patch for a trivial fix is attached. So if you think this team is suitable for you, you may want to consider helping us either as a dev or as a user by simply ping us (e-mail us) for the packages that you want to maintain through this team :)

  46. Pacho on November 18th, 2012 10:14 pm

    But, if you are familiar with Gentoo and commit work (you should as you are an old developer), I would prefer to see you return as a developer with full rights as, surely, man power is needed :)

    Thanks a lot

  47. Francois Bissey on November 19th, 2012 8:42 am

    Manpower that’s exactly what my peers in the science herd keep telling me. If you had commit right you could just push that yourself.
    Francois who is working hard on his end quiz.

  48. Sobhan Mohammadpour on December 9th, 2012 12:12 pm

    I love to become a devloper but can’t find some one to mentor me the people’s who like to mentor me are too busy :(
    from what i know of 5 month of using gentoo it’s getting better and better and update does not take a wile .

  49. Markos on December 9th, 2012 1:28 pm

    Tell the people who like to mentor you to send me an email and then I can be your mentor :-)

  50. [...] my recent recruitment performance post, here comes the second part of my Gentoo Miniconf 2012 presentation. The following two graphs aim [...]

Leave a Reply




Gentoo Miniconf
Patras Wireless Metropolitan Network
Planet Hellug
iloog
forum hellug

css.php