This year I’ve been accepted for Google Summer of Code 2014 with Gentoo Foundation for the Gentoo Keys project and my mentor will be Brian Dolbec (dol-sen). Gentoo Keys is a Python based project that aims to manage the GPG keys used for validation on users and Gentoo’s infrastructure servers. These keys will be any/all of the release keys, developer keys and any other third party keys or keyrings available or needed.
Participating in large communities and being a developer has great responsibilities. Developers have access to commit their new changes to the main repository, however, even an unintended incorrect commit in the main repository would affect the majority of the users. This issue could be addressed easily by the developer that did the mistake instantly. A less innocent case is that if a developer’s box is compromised, then the malicious user could commit malicious changes freely to the main tree. To prevent this kind of incidents, developers are requested to sign their own commits with their GPG key in order to ensure who they claim to be. It’s an extra layer of protection that helps to keep the integrity of the main repository. Gentoo Keys aims to solve that and provides its features in many scenarios like overlays and release engineering management.
Gentoo Keys will be able to verify GPG keys used for Gentoo’s release media, such as installation CD’s, Live DVD’s, packages and other GPG signed documents. In addition, it will be used by Gentoo infrastructure team to achieve GPG signed git commits in the forthcoming git migration of the main CVS tree.
Gentoo Keys is an open source project which has its code available from the very first day in Gentoo’s official repositories. Everyone is welcome to provide patches and request new features.
I had this post in the Drafts for a while, but now it’s time to publish it since the situation does not seem to be improving at all.
As you probably now, if you want to become a Gentoo developer, you need to find yourself a mentor. This used to be easy. I mean, all you had to do was to contact the teams you were interested in contributing as a developer and then one of the team members would step up and help you with your quizzes. However, lately, I find myself in the weird situation of having to become a mentor myself because potential recruits come back to recruiters and say that they could not find someone from the teams to help them. This is sub-optimal for a couple of reasons. First of all, time constrains Mentoring someone can take days, weeks or months. Recruiting someone after being trained (properly or not), can also take days, weeks or months. So somehow, I ended up spending twice as much time as I used to. So we are back to those good old days, where someone needed to wait months before we fully recruit him. Secondly, a mentor and a recruiter should be different persons. This is necessary for recruits to gain a wider and more efficient training as different people will focus on different areas during this training period.
One may wonder, why teams are not willing to spend time to train new developers. I guess, this is because training people takes quite a lot of someone’s time and people tend to prefer fixing bugs and writing code than spending time training people. Another reason could be that teams are short on manpower, so try are mostly busy with other stuff and they just can’t do both at the same time. Others just don’t feel ready to become mentors which is rather weird because every developer was once a mentee. So it’s not like they haven’t done something similar before. Truth is that this seems to be a vicious circle. No manpower to train people -> less people are trained -> Not enough manpower in the teams.
In my opinion, getting more people on board is absolutely crucial for Gentoo. I strongly believe that people must spend time training new people because a) They could offload work to them ;) and b) it’s a bit sad to have quite a few interested and motivated people out there and not spend time to train them properly and get them on board. I sincerely hope this is a temporary situation and things will become better in the future.
ps: I will be in FOSDEM this weekend. If you are there and you would like to discuss about the Gentoo recruitment process or anything else, come and find me ;)
Following my recent recruitment performance post, here comes the second part of my Gentoo Miniconf 2012 presentation. The following two graphs aim to demonstrate the performance of proxy-maintainers aka, how Gentoo users help us improve and push new ebuilds to the portage tree
One can notice the increased number of maintainer-needed@ packages but this is because we “retired” a lot of inactive developers in the last 2 months. I expect this number to not increase further in the near future.
I would like to thank all of you who are actively participating in this team. Keep up the good work!
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.
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
I have a really slow ADSL connection but it’s enough to share some bandwidth. Since I’m a strong supporter of privacy, the least I could do – especially now that I’m leaving the place for the summer - was to setup a TOR Relay server. I would love to see more relay servers all over the place. TOR is considerably faster than a couple of years ago for browsing, IRC and other low-bandwith operations. That’s very encouraging.
Since I run a 3350MX box as a home Gentoo server, I just emerged tor, privoxy and g-cpan in order to be able to access Freenode through a “torified” irssi client.sudo ACCEPT_KEYWORDS=\"perl ipv6\" emerge tor torsocks privoxy irssi g-cpan
Just add this line your torrc, after you do your relay or single tor server configuration:mapaddress 10.40.40.40 p4fsi4ockecnea7l.onion
It’s good to configure also tor-tsocks.conf file in the /etc/tor directory. Then we add the following line to /etc/privoxy/configforward-socks4a / 10.0.0.4:9050 .
Then change the configuration at /etc/torsocks.conf to match your network setup. At this point we must emerge some perl CPAN libraries. These are going to be used by irssi SASL script. In theory this step could be made using directly the CPAN manager like:cpan> install Crypt::Blowfish Crypt::DH Crypt::OpenSSL::Bignum Math::BigInt Math::BigInt::FastCalc Math::BigInt::GMP
However this approach created a myriad of problems to me. It stalled too many times and was not able to compile successfully the Math::FastCalc library. We need this library for faster calculations, since we’re going to encrypt/decrypt packets. Anyway, under Gentoo the approach that worked flawlessly is the following:g-cpan -iv Crypt::Blowfish Crypt::DH Crypt::OpenSSL::Bignum Math::BigInt Math::BigInt::FastCalc Math::BigInt::GMP
Now we need to configure irssi client. First grab the Freenode SASL perl script. Install it under ~/.irssi/scripts/autorun like:mkdir -p ~/.irssi/scripts/autorun && cd ~/.irssi/scripts/autorun && wget http://freenode.net/sasl/cap_sasl.pl
Now we just need to add some configuration to irssi. Start irssi preferably on ‘screen -U’ session and run it like:torify irssi
Now if you see any complaints about ‘cap_sasl.pl’ script then, you need to check the perl installation, make sure that irssi has been compiled with perl support, that the above mentioned libraries are installed etc. If you see no messages then everything is fine. Now let’s configure Freenode and SASL auth:/network add Freenode /server add -auto -network Freenode p4fsi4ockecnea7l.onion 6669 /sasl set Freenode <primary-nick> <password> DH-BLOWFISH /sasl save /save
Now you should be all setup . We don’t need SSL connection because TOR hidden services are encrypted tunnels, so it would be redundant to use SSL upon hidden services.
Enjoy Freenode anonymity!! You might encounter a bit of lag, usually is something like 4-5 seconds. It’s the current cost of cloak-ed host on IRC but pays well
12 Μαρ 2012: στόχος μας ως Ελληνική Κοινότητα Gentoo (gentoo-el) είναι να συνεργαζόμαστε με όλους τους εθελοντές και να συμβάλουμε στην δουλειά που γίνεται από κάθε εθελοντή, θα δούμε το πρόβλημα
της πρόσβασης που αναφέρεις και θα σου απαντήσω άμεσα.
Εξακολουθώ να μην έχω πρόσβαση στο gentoo-el.org μέσω SSH. Ο Θοδωρής Χατζημίχος (gentoo-el) κωλυσιεργεί στην ενεργοποίηση πρόσβασης στο gentoo-el.org.