unmasking/stabilizing silliness

I don’t understand users that complain when it takes awhile for something to be unmasked/stabilized. Gentoo developers will unmask or stabilize packages when they are ready, not before.

I have seen users ask when something will be unmasked/stabilized and complain when we say “when it’s ready”. When asked why they don’t just use package.unmask, package.keywords to unmask it themselves, they reply “I don’t want to break my system” or “I don’t like the idea of running unstable packages”. The thing that they apparently fail to grasp is that a keywording/unmasking by Gentoo developers isn’t some magical mark that makes a package stable. If we were to unmask or stabilize packages before they are ready just so users don’t have to “destabilize” their systems to run them, we would be destabilizing users’ systems just as much as if they had done it themselves. The only difference would be that everyone’s system is now broken, not just the impatient people’s systems.

If you see a somewhat obscure package sitting in ~arch for ages (not something like Gnome, KDE, X, Openoffice or anything else common) with no open bugs, it is possible that stabilizing it slipped a developers mind. In this case, a slight reminder (a bug or a poke on IRC) would be permissible (unless it’s a package that is at version 0.02 and has a tendency to crash with normal usage), as we do forget about packages sometimes.

Generally, for large or high profile packages, we do not forget about them, and there is a very good reason why they aren’t keyworded or unmasked. Often a search of bugzilla will tell you why something is taking so long. If you really want us to unmask or keyword a package faster, help work out the bugs that are preventing it from happening. Simply sitting on IRC/forums/mailing lists and complaining about it isn’t going to do anything except annoy developers. Filing stabilization bugs for packages that have open bugs waiting for a developer’s time is a good way to frustrate and/or piss off Gentoo developers, possibly making them decide they would rather be doing something else than fixing bugs to get your favorite package stabilized.

Volunteers and XMMS

Being in the sound herd (though not terribly active there as of late) I figured I would comment on the whole XMMS “debate” that seems to be taking up huge amounts of energy and time of one of our most talented and dedicated developers. It seems that the planned removal of XMMS has a lot of users upset. I can understand why they would be upset, though there is no reason they can’t continue to use it from an overlay or just make themselves a local overlay for it.

The point here is that currently there are bugs, and it is not working for some users, there are choices in the current situation. Either we can fix it, which will take an increasing amount of time and effort as time passes, have to explain over and over again in bugs that users file why it doesn’t work and will likely never work for them or we can remove the package. We have picked the latter choice as none of us has the time or interest to fix all the bugs, and continue fixing them as time passes. Don’t forget that Gentoo developers are volunteers, as such we are not obligated to work on any particular parts of Gentoo, we work on what we feel like working on. We also are not obligated to explain over and over again why something is broken (don’t forget the possible bad reputation we may garner by having known broken stuff in the tree).

To the users who like XMMS, please do not flame developers about the planned removal, this only has the effect of demotivating them, and make them less likely to want to work on anything at all. If you really want to keep using XMMS, simply copy all the ebuilds you want to use to a local overlay, and add them to /etc/portage/package.unmask. If you for some reason feel this is not good enough for you, and you absolutely need to have it in portage, you can either become a developer and maintain it yourself (and please actually fix the bugs, even if they don’t affect you personally), or you can pay a current developer to maintain it for you. As I have said before, we are not paid to work on Gentoo, so we are not under any obligation to maintain a package that none of us use or are interested in using.

Once again, please leave flameeyes and other sound devs alone, flaming us isn’t going to get us to keep XMMS in the tree. It’s only going to annoy us, take our time from working on other packages and possibly motivate developers to quit so they won’t have to deal with users demanding we cater to their every personal wish.

Ottawa Linux Symposium

Since I am listed as the contact for OLS on the Gentoo events page I expected to receive at least one email from other Gentoo devs or users that are going to OLS. I am planning to at least have a Gentoo BOFS (birds of a feather session). The one we had last year was fairly successful in my opinion (even though at the time I was there as a user), and I certainly would like to have another this year.

At the moment, the only Gentoo people I know are going to OLS are me, deltacow and gregkh. I am very interested in knowing if there are other devs or users that are going to be there this year.

xorg-x11-7.1 and binary drivers

There has been a lot of noise lately about the fact that xorg-x11-7.1 was put into ~arch before nvidia and ati drivers have versions that work with it.

I don’t think any open source project should be forced to hold back their development simply because some hardware company refuses to release open source drivers or at least specifications.

If you need binary drivers and are running ~arch, simply mask the new xorg until ati and/or nvidia get off their asses and catch up. In case you don’t know how to mask it (though you really should if you are going to be running ~arch) simply put the following in /etc/portage/package.mask

>=x11-base/xorg-server-1.0.99
>=x11-base/xorg-x11-7.1
>=x11-drivers/xf86-video-nsc-2.8.1
>=x11-drivers/xf86-video-s3virge-1.9.1
>=x11-drivers/xf86-video-i128-1.2.0
>=x11-drivers/xf86-video-trident-1.2.1
>=x11-drivers/xf86-video-neomagic-1.1.1
>=x11-drivers/xf86-video-cirrus-1.1.0
>=x11-drivers/xf86-input-evdev-1.1.2-r1
>=x11-drivers/xf86-video-v4l-0.1.1
>=x11-drivers/xf86-video-vesa-1.2.0
>=x11-drivers/xf86-video-tga-1.1.0
>=x11-drivers/xf86-video-s3-0.4.1
>=x11-drivers/xf86-video-tdfx-1.2.1
>=x11-drivers/xf86-video-glint-1.1.1
>=x11-drivers/xf86-input-void-1.1.0
>=x11-drivers/xf86-video-i740-1.1.0
>=x11-drivers/xf86-video-dummy-0.2.0
>=x11-drivers/xf86-input-keyboard-1.1.0
>=x11-drivers/xf86-video-imstt-1.1.0
>=x11-drivers/xf86-video-savage-2.1.1
>=x11-drivers/xf86-video-siliconmotion-1.4.1
>=x11-drivers/xf86-video-ark-0.6.0
>=x11-drivers/xf86-video-ati-6.6.0
>=x11-drivers/xf86-video-mga-1.4.1
>=x11-drivers/xf86-video-sis-0.9.1
>=x11-drivers/xf86-video-tseng-1.1.0
>=x11-drivers/xf86-input-joystick-1.1.0
>=x11-drivers/xf86-video-vga-4.1.0
>=x11-drivers/xf86-video-cyrix-1.1.0
>=x11-drivers/xf86-video-chips-1.1.1
>=x11-drivers/xf86-video-apm-1.1.1
>=x11-drivers/xf86-video-rendition-4.1.0
>=x11-drivers/xf86-input-mouse-1.1.1
>=x11-drivers/xf86-video-i810-1.6.0
>=x11-drivers/xf86-video-via-0.2.1-r1
>=x11-drivers/xf86-video-nv-1.1.2
>=x11-drivers/xf86-video-voodoo-1.1.0
>=media-libs/mesa-6.5
>=x11-apps/mesa-progs-6.5