Making build.xml rewriting way faster

Timing the build.xml rewriting of tomcat-5.5.20-r5


real 0m4.944s
user 0m3.869s
sys 0m0.917s


real 0m1.485s
user 0m1.262s
sys 0m0.178s

So that gives us a nice 70% speed improvement. It could be even faster if it did not have to do the rewriting twice, but this starts to be fast enough not to bother me too much when writing java ebuilds. The improvement was mainly accomplished by rewriting using expat callbacks instead of manipulating DOM, which in python reads the xml file in using expat any way I think.

My thoughts on the current state of Gentoo

While I don’t usually participate in the discussions about lack of direction in Gentoo or flaming on gentoo-dev, I felt I should provide my on view on the current state of Gentoo.

Developers leaving

Nowadays when developers leave they usually write a blog post to gentoo-dev describing the reasons of their retirement. I think previously most people either just disappeared or did this in private on gentoo-core. Alec Warner seems to think that people leaving will become a problem for the project as a whole. Actually I don’t think this will happen as at the moment there are 20 new developer bugs open and I have been steadily approving new developers on a weekly basis for some time now. I have been also very happy with activity of most new people. Most recruits have had a steady flow of commits with an average of under a day between commit messages. Granted the old timers can tell stories about old times and easily answer questions that new people have to ask, but we still have plenty of people to do that and Gentoo developers should be skilled enough to figure most stuff out by themselves any way. The only problem I see with people leaving and new people joining is that we need more active recruiters to make the recruiting process faster.

Flaming on gentoo-dev

I follow gentoo-dev and gentoo-core but don’t post that often to them. I feel that if I have something useful to contribute to the big picture, I should show the code along with the specification. Most people know what needs to be done (EAPI=1, GLEP 42 etc), the only thing missing is the code. It’s much harder to argue against working code than a vague specification.

Gentoo is not progressing

My take is that people who say this just don’t remember how things used to be. I started using Gentoo in 2004 and since then I have seen steady development. For example Portage has come a long way since I started even if it is stilling missing some of the features that people need. The bugs I have filed about Portage have been fixed in a timely manner. Then let’s look the what the Java project has been doing. We basically reimplemented the whole Java setup in a way that is much better for users and developers alike. On a final note I would like to thank Flameeyes on the work on Gentoo/FreeBSD. It has come a long way since it started. So these are just a couple of examples. I am pretty sure that other teams/projects have similar success stories to share with you.

Why I still like working on Gentoo

For me it’s mostly about scratching an itch. I like the power that Gentoo gives me and as I have the knowledge to solve most bugs and do version bumps myself, why not do it? In return I regularly get thanks from the users we help on #gentoo-java and the people I recruit. For me it has always been sufficient to keep me working on Gentoo. The flames etc are of little consequence to me as long as it does not bring down Gentoo as a whole. Remember that you really don’t need to get the approval of others to start new projects. So if you are not having fun and are thinking about leaving because you feel that the developer community is not worth your time, please reconsider based on what I just said. For me the Gentoo experience has always been a positive one, so why can’t it be the same for you?

On breaking QA policies

Alec Warner wrote that there are people who continuously break QA policy and don’t use repoman. This truly is a problem if it exists. Should really look into it, as such people should not be allowed to continue their work in that way. It should be possible to kick those people out if need be. I also feel that there are plenty of things we should do to improve the QA checking tools like repoman. But this is the usual situation of show me the code. As I have been in the army, I luckily have a handy excuse until January.

Lack of direction

Let’s take a look of the business idea of Nokia. I think it’s “Connecting People”. Maybe we have a need for a similar short slogan or not but I think our core business is keeping the ebuilds updated. Then there are support functions for that like installers, releases, etc. The individual projects are usually very focused and as it should be. I don’t believe that we need a global road map saying this is what we should focus on now as things seem to be progressing nicely with the manpower we have. I firmly believe that we will overcome all the technical problems given enough time. Because no-one pays us to meet a deadline, I really can’t expect to have everything immediately. What I am really looking forward to is something like 2010 when most of the building blocks have fallen into place. What could be useful is to extend the project xml files to state current goals and collect these into one page that would be linked from the front page.