Posts Tagged ‘development’
I’m running for the Gentoo council this year, and I wanted to post my “platform” here: who I am, why I’m running, how I see the council, and how I see Gentoo.
For anyone newer, I’d like to first introduce myself and my history with Gentoo. Over the past 8 years, I’ve spent time doing pretty much everything in Gentoo, from maintaining ebuilds to writing documentation and leading teams and projects. I’ve been a recruiter in devrel, served as desktop manager (back when we had top-level project managers, before GLEP 39), and later chaired the council. I also started the clustering team, led X11 maintenance for about 5 years (when I designed the modular X eclass and wrote all 400+ new modular packages as we transitioned from the old XFree86), spent a term as a foundation trustee, and acted as project manager for our ever-controversial GUI installer.
One of my primary roles at the moment is running our participation in the Google Summer of Code, one of our major sources of both income and new developers. Since I took over 3 years ago, we’ve more than doubled the size of our program (we have 15 students this year!) and greatly increased the proportion of students who eventually become Gentoo devs to roughly 67%.
At this point, I’m convinced I can make the biggest difference to Gentoo in two ways: focusing on specific projects like the git transition and improved eclass testing rather than ebuild maintenance (which we have tons of people doing), and leading Gentoo to greatness as a council member, where I’m in the best position to accomplish that goal.
On my last two terms as a council member, I was extremely active in council-related issues both on mailing lists and at meetings, rather than just showing up at meetings to vote and then disappearing into the sunset. I strongly believe that through preparation and accountability, we can have a more productive council, but this requires a true commitment on the part of every member.
Creating a great community
I see this as an area where the council can set direction for all of Gentoo, both through the positive examples of its members and by taking a stand against anything we won’t stand for in our community. The council should be providing guidance to devrel and userrel on what kinds of behaviors should be encouraged and what kinds shouldn’t be tolerated.
Additionally, we should begin collecting metrics on our community so we know where we’re going. Many other projects (and even distributions) do this already, to give them clues of when things are going wrong, what things are going right, etc.
Making progress now instead of waiting years for perfection
There’s a lot of ongoing projects and GLEPs that have been dragging on for years because people want a “perfect” solution. One personal example is the git transition, where I’ve already made this mistake in spending quite a bit of time trying to get a perfect repository layout working when we could have just done a simple conversion of the whole tree and put it in one repo (the current plan, with some changes).
GLEP 55 is another one. There are some times when any decision is better than no decision.
Removing bureaucracy in favor of more agile development & meritocracy
We all know that GLEP 39 needs some changes. I think that most devs just want to Get Stuff Done without fighting with policies, waiting around forever for votes, not getting majorities without any clear direction, and so forth. I believe that our devs vote in the council because they want those people in charge and trust the council members to do what they think is right, including deciding on changes to GLEP 39 to improve how we run things.
I favor a switch to a smaller group more along the lines of the Linux kernel, with a very small leadership core and more of a hierarchy than a huge committee.
Along the same lines, I favor a switch to a more meritocratic approach such as the lead appointments we’ve been discussing recently. Gentoo isn’t a country government that needs to provide for every sick and needy person in its geography; it’s a nonprofit with specific goals it needs to accomplish and should be run as such. In general, companies, including nonprofits, don’t have checks and balances or long, drawn-out votes. What they do have is a board of trustees at the top, which can replace the leadership when it deems necessary.
Another major problem is the lack of continuity in our leadership, mainly because the whole group is re-elected en masse every year. At a minimum, even if we can’t do the above changes, we should switch to a 2-year term and have half the council up for election each year so new councils can start out quickly.
Promoting innovation from individual developers instead of expecting it to all come from the top
As I mentioned above, one of my focuses now is working on interesting standalone projects. I hope that every developer does the same; in addition, or besides whatever you do every day (maintain ebuilds, write/translate docs, etc.), consider starting a new project that has a clear end in sight and that will help Gentoo get better. It doesn’t have to be anything big; and the great thing about projects with a finite length is that you actually finish them at some point.
Getting rid of policies that were created for a single incident, because they should only exist for patterns of repeated problems
A common problem in Gentoo is feeling like a one-time problem can’t be fixed without making a big policy about it, why it can’t be done, what will happen if it’s done again, etc. If you’ve been around Gentoo for a while and start reading through our developer docs, you’ll be able to connect a specific name and instance with pretty much every line that says something like “Don’t do stupid thing X” and “Don’t do ridiculous thing Y.”
I think part of this is rooted in a fear, for lack of a better word, to take personal responsibility for an action; instead, people want a rulebook to point at and say “That’s wrong” so the rulebook is the bad guy.
But rulebooks should only be for the common cases, the patterns, the problems that keep coming up over and over. One-time problems only deserve one-time solutions.
One of the most powerful aspects of popular high-level languages is the existence of a comprehensive standard library. Unfortunately, the most popular Linux shell, bash, lacks a full-featured library bundled with it. A number of people have written libraries to compensate for this lack, which can make your life infinitely easier if you need to write complex bash scripts. Here are links to all the bash/shell-scripting libraries and collections I’m aware of:
- Marco’s Bash Functions Library (mbfl)
- Bash Shell Function Library (bsfl)
- Bashinator: Bash Shell Script Framework (by our own wschlich)
- shesfw: shell script framework tool
- Wicked Cool Shell Scripts library (from the book)
- UNIX Power Tools library (from the book)
- Portable Shell Programming (from the book)
- Learning the bash shell (from the book)
- Bash Cookbook (from the book)
- Classic Shell Scripting (from the book)
- shunit2: A unit-test framework
- log4sh: A flexible logging framework
- libbash: Enables creation of dynamic-like shared libraries
- bashworks: Framework depending on bash-4 or newer
- bfw: Bash FrameWork (Harvard Neuroinformatics)
- rerun: Turns loose shell scripts into modular automation
It was a real pain to come up with this whole list, so hopefully it’s useful to some of you. In future posts, I’m thinking of reviewing these libraries in more depth and comparing them to equivalent functionality in Python, my other language of choice. My goal is not to have functionality re-implemented in shell script to replace basic tools like head/tail, but instead to discover or create (if necessary) a library using the full suite of standard UNIX tools to provide a fun and convenient experience for shell scripters.
Update (2013/07/08): Added rerun.
Update: Fixed a couple of broken links (bashworks and Portable Shell).
Similarly, you need to quickly build the same level of trust with our community. Do you have the tools it takes to hack into the code? and do you know how to use them? When a contributor uploads a patch to our mailing list or to our tracker (preferred, but to make sure you get noticed please post a link on the mailing list too) he builds instantaneously the same level of trust that the unknown cab driver builds with every new customer: he implicitly shows that he has the tools (hardware, operating system, internet connection, coding environment, repository access) and that he can use them for basic operations.
A post I made on the Gentoo development list last night deserves your attention because it illustrates a key aspect of Gentoo. I want to make sure it’s preserved instead of lost in mailing-list archives. This is in reply to a proposal to move a significant portion into a series of variables instead of being written as scripted functions:
I think the idea of ebuilds as scripts showing directly how to build software is a core part of the Gentoo build-system philosophy. This proposal pushes ebuilds toward a formatted file that is not a script. Instead, it is more like an Ant XML file that more abstractly describes a build. I think this is the wrong direction for ebuilds because they should directly resemble how software is built by hand.
One of the key reasons people use Gentoo is that ebuilds are so easy to “get” for anyone who has ever built software by hand. I will continue to vehemently defend anything that I think retains this key advantage of Gentoo over other distributions.
Gentoo is a distribution for advanced Linux users, or those who want to become advanced. Having packaging scripts that are easy to learn lowers the barrier to entry to editing them, which vastly increases our number of potential developers. It additionally comprises a key part of Gentoo’s ease of customization by allowing people to easily write their own packages or modify existing ones for their purposes. When users do this, it creates a natural pathway from building software by hand to editing ebuilds to becoming a Gentoo developer. The more difficult it is to learn how to write packaging scripts, the more of your potential developer base you repel.
“What many people don’t realize is that the bikeshed effect is, in fact, a form of procrastination. And it can suck in highly technical developers, along with everyone else.”
This year, let’s try something different! I posted a rough draft of our organization application on the Gentoo wiki, in hopes that we can all work together to improve it over the next week. Applications are due starting March 9, and earlier is better. Here’s a list of questions that you can help answer:
- Why is your group applying to participate? What do you hope to gain by participating?
- What criteria do you use to select the members of your group? Please be as specific as possible.
- Has your group participated previously? If so, please summarize your involvement and any past successes and failures.
- What questions/requests do we want in our application template for students, in addition to the GSoC application?
- What is your plan for dealing with disappearing students?
- What is your plan for dealing with disappearing mentors?
- What steps will you take to encourage contributors to interact with your community before, during, and after the program?
- What will you do to ensure that your accepted contributors stick with the project after the program concludes?
Go to the wiki, and help Gentoo’s application rock!
To compete with Remi’s post about getting xorg-server 1.5.3 stable in Gentoo, here’s one about getting xorg-server 1.6, which was released today, into testing in the main tree. We’ve been maintaining the 1.6 release candidates in the x11 overlay for a while now. Tonight I added the final release to the overlay. (Update for Google users) What’s new in 1.6, you ask?
- RandR 1.3: Panning, transforms (fixing projector keystones, etc.), primary outputs
- Xinput 1.5, including input device properties
- Predictable pointer acceleration
What’s left before it can move to the main tree? Here’s what I can think of, offhand:
- The new XRandR stuff needs to get released upstream (randrproto, libXrandr, xrandr). Right now we’ve got the xrandr userland tool depending on live git of libXrandr, which won’t work for the main tree. (Update: randrproto and libXrandr 1.3 are out, just waiting on the userland tool xrandr)
- We need to sort out the issue with XCB’s Xlib library renaming forcing recompiles of practically everything. This is becoming more and more of a blocker because now libXext 7.0.5 requires a new libX11. I think giving ourselves a hard blocker on 1.6 from this will help us get it fixed. See bug #248743 to track progress on this. (Update: solution in x11 overlay for testing)
- The server now has a fix to keep looking for HAL if it’s not running when started. Should we change /etc/init.d/xdm to compensate for this change by no longer depending on hald, thus allowing gdm/kdm/etc to start earlier? This will give us one of the steps taken by the fastboot work seen lately in Moblin and elsewhere.
- I think Remi’s going to add xf86-video-intel 2.6.2. (Update: done)
- Our xinit is crazy stale, mainly because we patch it like crazy and I don’t like porting those. I’d like to get it updated to a current release for 1.6. In the longer term, we need to merge distro-neutral parts of our work upstream, but that’s not a 1.6 blocker.
To sum up, you can try xorg-server 1.6 now by adding the x11 overlay with layman, or you can wait for the above issues to get solved, and it will show up soon in testing in your main tree.