Since I still have got access to this blog, and since I know that many don't read -dev or -core, I'll spa^Wcopy a message I just sent there. Please answer there if possible.

Hi everyone,

as everyone probably noticed, there is a current atmosphere of sinking ship, with quite a lot of people leaving and many agreeing that gentoo is no fun working on anymore. Before it's too late, I'd like to propose a big reformation that would help solve some of the issues we are currently having and, hopefully, bring back some of the fun we all had developing and using this distribution.

The basic idea is to make gentoo a lot more meta than it already is. Something that is said quite often is that gentoo lacks a direction. Some people want it to be a business-oriented distribution, some want it to be bleeding-edge, some a multimedia, development platform, you name it. Obviously, arbitrarily choosing one of those directions would mean losing a lot of developers, and this is something we can't afford to do. The solution, of course, is to go meta: provide a set of tools that allow people to build the distribution of their dreams.
This is something that we are already trying to do, but my opinion is that we are not going far enough. For one thing, we target users as the one who should build and customize their distribution, while it would be pretty interesting to also target ourselves as the ones who should be doing this "instantiation" work. Stage 4's were going in this direction, but they were too isolated and, as far as I know, they are dead now.

The idea is pretty simple: modularization. There is a core part, with a couple hundred packages that are absolutely necessary to a system. Then we have a hierarchy of overlays with additional ebuilds for people's need. Top-level
projects could look like: desktop, dev, business, embedded, misc. Then we would have subprojects, e.g. multimedia, DE, games for desktop, multimedia being itself subdivided in audio and video, and so on. This would get us a
tree of arbitrary depth, with development happening mostly in leaves. The hierarchy would mostly serve as a classification tool, and projects would not necessarily share resources, including devs, with their subprojects, neither should they have decision power over them.

This structure has many advantages, one of those being that since projects are autonomous, they handle their own recruitment, which helps the dev/user distinction fade away. It concentrates development in small areas where people will know each other well and be able to interact efficiently. By decentralizing, we remove the need for a big authority and give everyone the freedom they want. The current devrel authority is reduced to only the core project, though people could still ask its wisdom whenever conflicts pop up. Basically, the only job involving red tape and a central authority is deciding who gets the nice "gentoo official project" stamp, and the resources infra can then provide. Of course, QA would be the main, if not only, criterion in this choice.

By having everything as modular as possible, we also allow an easy fork of a single project, for whatever reason. So if enough people think that mozilla is being badly maintained by the current project and that people in it don't want or can't apply their fixes, they can easily provide their own overlay with better ebuilds. And if their version is indeed better, over time it will get the official status and have superseeded smoothly the first project. Think of paludis and pkgcore vs portage.

So far, I've come up with two main disadvantages to this reformation. The first is that dependencies between different projects could become a problem if not handled carefully. For one thing, they would require a change to ebuild syntax, along the lines of DEPEND="dev.perl.libs:libfoo", and of course support from package managers. Pulling single ebuilds when required instead of a full overlay would be a nice thing to have as well. Another idea to simplify this would be to have a central DB with every known ebuild in it (including non-official, bad QA ones) and the names of repositories/projects providing it. This would give enough information to package managers for them to make intelligent choices about how they should behave.

The other big problem is that a migration to this structure would require a lot of effort from everyone. The good news is that we could use the opportunity to migrate to a nicer scm (and given what gentoo would look like, a distributed one like mercurial or git would be a natural choice) and also that we would get a good idea of what is maintained and what isn't. Leaving out stuff that no-one wants would then be very easy. Also, I believe that by having a clear goal, everyone should get a huge motivation boost and I believe that things could go quite smoothly, and even quickly.

Of course, many details have been left out that should be discussed and solved before any decision is taken. Among those is the status of arch teams, which is a bit unclear. An idea would be to have the main three or four most-used arches (x86, amd64, ppc would be my guess) in KEYWORDS, as usual, along with a list of repositories that given person is allowed to keyword in, keeping arch teams organized as they currently are. Other arches would be projects of their own, with some kind of meta-overlay that specifies which ebuild from which overlay has been tested, etc. Or we could make no distinction between popular and less popular arches, I don't really have any opinion on the matter. Also, what to do about stuff that isn't specific to any project, even though it wouldn't happen so often? For instance, deciding whether we should participate in SoC, or this kind of things. We could use a council as currently, or ask for representatives of all official projects to punctually decide, or organize a general vote, or maybe even something else.

To end this proposal, let me say that without a doubt, there are many holes and hidden problems in it. I don't claim it's perfect, nor that it will magically solve our problems. But I think it is a better structure than the one we currently have, and that switching would reduce, perhaps even stop, the dev bleeding, bring back freedom as well as fun, and help ease the tensions.

Please criticize this with everything constructive you can think of.

Thanks,
/Alexandre

Here comes the remaining of my photos. It includes the ones from the restaurant and from the after party at an awesome pub (check out the beer bottle on page 2, it has to be the bestest beer I ever drank!).

http://dev.gentoo.org/~nattfodd/fosdem2/

And here's the group photo, thanks a lot to Sejo who shot it (original size version):

This is a quick blogpost to post the url to some photos I've just uploaded. If you want to have a feeling of what FOSDEM looks like, have a look at : http://dev.gentoo.org/~nattfodd/fosdem. I will try to post bigger pictures if internet stays on long enough...

I've been following the Debian vs Mozilla case (aka Iceweasel/Firefox) pretty closely, especially as this happened during the JDLL (if you don't read french, debian people put those posters on their booth which was just in front of the mozilla one, which triggered a blogging skirmish involving quite a lot of bird name calling). See this LWN article for a quick summary of the situation.
I had been thinking of leaving firefox entirely for a long time (I had already traded thunderbird for mutt last year), mainly due to its huge memory print (I like to navigate with more than 20 tabs at the same time), its slowliness and a growing dislike of the mozilla attitude, especially since the creation of the Mozilla Corporation.
As far as I know, there are only a few alternatives: epiphany, which I discarded because it's running gecko, opera, which is very good but unfortunately not free (as in speech) and konqueror. I initially overlooked it because I'm not running KDE, and I was fearing that it would want 90% of the desktop environment to work, but it looked pretty happy with "only" kde-libs (which I already had for k3b, anyway) and some extra stuff.
I have to say it's really good, and in fact much better than what I had thought, even when run on top of FVWM. Navigation/rendering is good and the UI responds without any noticeable delay, which is really a big relief from firefox. I have imported my bookmarks and spent 5 minutes reconfiguring the fonts, and there we go!
So far, there are only two things that I miss, though I may have simply overlooked them: forms staying filled when you press the back button, and tabs being saved from one session to the next one.

I plan to unmerge firefox in the next few days and have, at last, a mozilla-clean machine, which would be a nice gift for its second birthday!

Here we go, less than one day left before the next Journ

So, a month and a half ago, I was selected in the Summer of Code project for the second time. After perl, I'm now working for irssi, and I am to add some high-level curses to make the configuration and general usage easier. Unfortunately, I didn't spend nearly as much time as I would have wanted to, but it's still advancing. I have really good hopes to be able to finish it before the mid-august deadline as things should be more quiet for me during july.
Anyway, I just commited a big revision that shows the first working object. It's a simple form that asks you to change your nick. Fortunately enough, not too many things are hardcoded for this object so it should be pretty easy to add others now. Main issues are now to:

• have a really clean configure.in and dependent code that will compile without cuix enabled
• complete the API on the curses side. Forms and list are pretty much done but menus are still missing
• find a way not to have to say ^L to refresh the terminal once the cuix object has been destroyed
• understand better how signals behave and how to retrieve misc information that I want to obtain or modify
• deal with the cases where the objects are too big to be displayed in the window
• triple check that there are no memory leaks (at the moment, valgrind is totally happy with cuix, which comes as a real good surprise)

Once I am done with those, it will only be a matter of adding many objects and test everything.

On another note, my mother and sister have come to visit me in Sweden. It has been the occasion to head of to K

As you may have seen on -dev, George Shapovalov is currently reorganizing the science project. There are a couple hundreds packages in sci-* but people, like myself, were a bit frightened at the idea of joining this project if only interested in a small subset of them. Well, it seems that "sub-herds" are being created. I jumped on the occasion and will deal with the math-proof herd. For now, it's only sci-mathematics/coq and sci-mathematics/otter, which are both proof assistants. I plan to also add agda soon (my current ebuild has a sandbox violation, I guess I need to tweak the Makefile), as it is quite close to my research interest (Martin-L

Thanks to beandog, I have now a nice blog hosted on planet.gentoo.org. This is a refreshing change from the blogspot one I used last year (it's now dead but you can still find it at nattfodd.blogspot.com in case you desperately want to know about some internals of parrot).

I also seize the occasion to procrastinate, as I am supposed to finish packing and cleaning my appartment in Uppsala. Tomorrow, I'll definitely move out of this great city and go to G