Tuesday, May 6. 2008
We are currently having the fun of a perl update in unstable - most packages have been rebuilt and work just fine, now cleaning up the mess starts. Please don't expect perl to enter lenny in the next few days. Also, hold back on the uploads of perl packages or SONAME bumps, thanks. For the moment, I'm keeping my todo list in my hint file. If you would like to help out, just pick one of the bugs listed there and do the work, thanks :)
Posted by Marc Brockschmidt at 22:51 | Comments (0) | Trackbacks (0)
Friday, March 21. 2008
Some people expressed some concerns about the fact that we currently have about ~440 bugs in testing, but still hold to our plan of releasing in september 2008. The development of the RC bug graph as seen on bugs.debian.org is in fact not very promising - but using the information the BTS now keeps through version tracking, a more detailed graph can be created. This one in fact shows how nicely we are progressing: The number of long-standing RC bugs is steadily shrinking, while the number of fixed bugs just waiting for transition is increasing. The latter is due to several complex transitions that are stuck (such as the ghc upgrade to 6.8, the suitesparse upgrade or X.org). Anyway, lenny's overall situation is a lot better than the simple RC bug count shows, so try to be positive and start bug-fixing now, for the first Debian release on time!
In other positive news, the first bits of Gnome 2.22 have reached testing, we will switch the default gcc version to 4.3 on this weekend and will start using python2.5 as default python version in the next week. Interesting times!
Posted by Marc Brockschmidt in Debian at 19:45 | Comments (0) | Trackbacks (0)
Sunday, November 4. 2007
Still not campaigning for DPL
In my first post about my current problems with Debian, I noticed that there doesn't seem to be a common vision of Debian's future. My last post was about Debian's current state of moving from stable release to stable release without actual aims.
Today I would like to rant about our lack of enthusiasm. Could you name the biggest new feature of Debian Etch? I think the graphical installer is very cool, it made the installation look a lot friendlier and made translations to languages not based on the Latin alphabet easier. But what else happened in Etch? We added SecureApt, which might be cool if you are a hardcore hacker, but leaves most people bored. The same is true for using UTF8 for new installations and the addition of udev to the default install. If you don't know where I got this impressive list of thing - look at the Debian Wiki.
Most of the things listed on that page miss the bling we see in other distributions. Ubuntu 7.10 introduced Compiz bling while Fedora 7 had full NetworkManager support and tried to "just work" [tm]. Yeah, Debian isn't that far away from such things, whenever we release, such things are also picked up. But somehow it doesn't look like people would get out and party because we include the newest and coolest feature - no, Debian Developers prefer to discuss such things as the default MTA.
Of course, we need to discuss the default MTA - and exim4 might not be perfect for the job - but we should also start to think about advertising the features that impress non-geeks, so that we can go out and say "Hey, lenny came out and now we have a full dependency based init system and a smaller MTA and our kernel is now completely free of binary blobs" to our geek friends, while our non-geek friends can hear about the new easy-to-use and beautiful desktop environments and configuration applications that allow them to just install and use their Debian, without moving to a command line once.
We are half-way there. Debian is cool. Debian becomes better every day (*cough* please look away from the RC bug graph, thanks). We should start telling people about it and have fun doing so.
Posted by Marc Brockschmidt at 20:49 | Comments (2)
Tuesday, October 30. 2007
No DPL campaigning to see, please move along
Even though Adrian von Bidder suggests that I'm starting a bit early with the DPL campaigning, I thought I could add a few more thoughts to the blagosphere.
Adrian suggested to make the discussion of our of "vision of Debian" a regular event on debconf - I think it's a nice idea, but that doesn't mean we should keep silent about that topic the rest of the year. I think one of the problems we see in Debian is that we are missing an aim to strive for. We are currently just moving from release to release, while more and more developers have actually lost interest in stable releases. The impression that a common ground like Debian 4.0 is irrelevant seems to prevail, because the people most vocal in our user base usually want to see the newest and shiniest software on their desktop. We have been spending more and more effort to cater to their wishes and have ignored the fact that a majority of Debian-based installations are not run by such people, but by system administrators who do mass roll-outs and neither want nor need the newest X.org with more *bling*.
Ubuntu, the biggest Debian-based distribution, has found its users by packing up new software behind a nice installer, adding some branding elements and then shipping it. Stability is an issue for Ubuntu, but they don't spend as much time as we do on eliminating the last seemingly important bug in some esoteric software package before actually releasing. That observation is the ground for one of my ideas: Our current metric to determine how far testing is away from a release is counting the number of rc bugs - it doesn't matter if the rc bug is X.org crashing for all people or if it is a policy violation in a package with 12 users. Perhaps we should start thinking about a new metric, keeping in mind that for a majority of users, some bugs matter a lot and some matter not at all. With the release of etch, the number of installations of popcon has risen a lot, so for the first time, we have actual usage data that could help us with such a metric. There are a few problems with that approach, though:
I don't have more time right now, so the rest of my ideas will follow in the next few days, so stay tuned or add me to your killfile.
Posted by Marc Brockschmidt at 11:53 | Comment (1) | Trackback (1)
Sunday, October 28. 2007
Why THEY don't want me to collect all left socks
Yoe seems to believe I see a cabal in Debian. Let me assure you: I don't - and if there would be a cabal, I would be part of it. I've seen most of Debian, played around with NM, the release team, have seen how our buildd network works (or, in the specific case of today: mostly works) and have close contact to people in all other core teams of the project. I still haven't seen a sign of a Cabal.
I believe that there are "clusters" of people who work better with each other, simply because they have known each other for years and developed trust, but that's nothing I would actually mark as problem. I do the same. Many of our core people have too much work to do, mostly because getting a job well done is usually reason to give you more tasks until your performance becomes abysmal. That doesn't mean that they are bad people or do bad things intentionally, but often, they don't allow people to help them - the usual reasoning is "new people need training, training needs time, time is what I don't have => no new people". Obviously, that argumentation is flawed in the long run.
Anyway, on to the more technical details:
And, FWIW: I do hate conspiracy theories too. They come to life because people usually want to see the "bigger picture" - even if there is none and all of the weirdness in their environment can be explained by chance, human error and unknown social problems. And as I said - I don't believe there is a group of people making decisions that seem bad for Debian. I just believe a lot of people try to do their best for Debian - but they fail on a regular basis.
Posted by Marc Brockschmidt at 08:45 | Comment (1)
Saturday, October 27. 2007
"What to do when I've collected all left socks" or "what I want to change in Debian"
It's this time of the year again: The one where I look back at my involvement in the project and decide that I've been a member long enough, so I should probably get out. For Debian, there are two ways to do it: Either become MIA or become DPL. As I have too many real life connections to other DDs, I guess I can't really do the MIA thing, so I should probably get elected as DPL. Whenever I consider this way out, I think about all the issues that make me unhappy about Debian. This time, I've written them down. So, here's a list of things I would like to see and would work on if I had the power to do so:
Besides those things that I really miss in Debian, there are also a few things I would simply like to see done in the near future:
So, what do you think? Are all of those ideas crap or should we perhaps try to implement them? Have I missed something important?
Posted by Marc Brockschmidt at 20:47 | Comments (6) | Trackback (1)
Friday, August 17. 2007
The german cabal ...
So we had one of our german cabal meetings a few weeks ago. They happen seldom enough, seeing how we already control most of Debian. Anyway, I think you would be surprised how formal these meetings are:
Posted by Marc Brockschmidt at 09:52 | Comment (1)
Saturday, January 6. 2007
Debian's BTS still sucks
In response to my rant about Debian's BTS, I got some mails about other project's handling of bug tracking system - I'm still looking through those.
More interestingly, Joey Hess blogged about it and defended keeping old bug reports - which I also think. I explicitly talked about bug reports with no activity and no maintainer reaction. I took the time to look at some of the bugs Joey submitted and found some good examples for bugs and packages that obviously need help.
230485 is now in the ripe age of nearly three years. Almost three years is also the age of the last mail to that bug report, which was one maintainer setting the severity to important, without a comment. Since then, there has been no note if this bug is going to be fixed, how, when, why and who is going to do it. A user might get the impression that the maintainer simply doesn't care about this (or other) bugs. That's not a good thing, I believe.
271752 is also a good example. The bug seemed to be unreproducible, now someone found a way to reproduce it and ... nothing happened.
206605 is also weird - a patch is there (and we're talking about little grammar change here!), but no upload actually included it. Without a comment why it is not happening...
Keeping old bug reports to inform users of existing problems is OK. But not fixing bugs (or even trying to fix them) is a problem!
Posted by Marc Brockschmidt at 14:09
Debian's BTS sucks
Blogging is hard, isn't it? Finding a topic that's not better placed on specific mailing list or somewhere else is not easy. One of the classical subjects for bloggers is ranting. And that's what I would love to do now :-)
I have had discussions with people who are turning away from Debian in the past few months, mostly to Debian derivatives like Ubuntu. Mostly, the reason for that is some sort of software that is newer/better supported/blabla in some other distribution, which I think is OK. Debian has a policy of a long, painful release cycle, but the stable releases that come out of it tend to be useful for a long time and relatively bug-free. That is good and shouldn't be changed without good reason.
Most of the people I spoke too revealed a far more disturbing thing: The long release cycle isn't the only argument against using Debian. Most of these people had other reasons, and a good number of those are things that Debian as a whole can - and should - address. Mostly, the Debian BTS comes up as a topic. Not because we don't use the Industry Standard [tm] bugzilla (which I personally hate so much I can't even describe), but because the BTS contains a lot of old bugs nobody cares about. Look at most of our packages: Bugs filed 7 years ago, with the last activity from that time, without a hint how (and if) they are ever closed are not uncommon; they are what you actually expect if you look at a bug list.
Naturally, processing, forwarding and closing bugs is the task of the maintainer. This doesn't work out in all cases, we have more than one cases where maintainers are overwhelmed by the sheer number of bugs flowing in against their packages. Also, and that is probably accepted everywhere: Bug processing is uncool. It is so much more fun to rewrite your code, add features, get new packages in the archive and doing new, blingy stuff, that the boring maintenance work of existing packages moves to a place far down on the todo lists. But hey, this maintenance. That's what maintainers are for. Most Debian Developers are Package Maintainers. They should do it, not adding new stuff.
We need to discuss how to work around these issues. We are not the only project which an overfilled bug tracking system. Look at the Gnome and KDE projects, the number of bugs filed against Mozilla products each day. Can we learn something from them? I would be happy to get a bit of feedback about this, so whoever is involved in other projects which have found better days to deal with bugs, please send a mail.
Apart from the fact that I would love to get more input on this, I want to start something new for lenny, the stable release planned after etch. I want to get the bug count down. Not the release critical bug count (which is eagerly watched all the time), but the small issues that bug users every day. For that, I have planned to look at 5 random important and normal bugs each day (starting with software I use) starting the day etch is released. I may begin to do this earlier, but I'm currently really not swimming in free time.
I don't plan on fixing all these issues (well, I may, if I can easily reproduce them), but more on forwarding them to the appropriate place, upstream, and noting so in the BTS. I want to poke maintainers long enough to invest some more time in fixing bugs. This will also help with the MIA efforts of the QA team, I guess...
Oh, what I almost forget: I expect help from all of you!
Posted by Marc Brockschmidt at 01:46 | Comment (1) | Trackback (1)
Wednesday, October 4. 2006
Why I keep working on Debian
I haven't blogged in a long time, so I probably should drop some thoughts here to show that I'm still around.
In the past few months, I have been able to dump some of my work on other people by orphaning some packages and getting Christoph Berg (Myon) to do Debian Front Desk work.
To compensate this loss of tasks, I became a member of the release team, so the recent discussions about funding release managers should probably interest me, but I fear the threads on debian-private, -project and -vote have only made me sick. The number of people who have been childish, unjust and simply weird is enormous and would be a good reason to leave Debian altogether, something which I considered a few times over the last weeks. I would surely quit a job where co-workers hate each other that much, so why should I do this to myself in my free time?
Interestingly enough, actual work for money has shown me why Debian is something that should be supported, even if the mailing lists are full of posts from idiots. I had (and have) to work on OpenBSD for a customer, porting the recent release of Gnome 2.16... Well, let me tell you, Debian is better. A lot.
I think this may help you if you're doubting that working on Debian is sane: Remember that we work together to create the best possible, universal operating system. And even if we're not there yet (and there's a lot of work left), we have succeeded in creating an useable, useful operating system, which is easy to administrate and allows you to have a lot of fun with it. And we did that together, in the occasional moments when fighting with each other wasn't that important.
I have to admit that I haven't invested a lot of time to work on Debian in the last few weeks, but this was due to personal and work reasons. In two weeks, I'll have to return to my usual university schedule, so I'll spend a lot of time on Debian ignoring the exercises I'm supposed to work on.
Also, I have been working on a new server I've rented together with Andreas Barth, playing around with Xen and starting to bootstrap the actual systems we will need. This will mean that I'll have to move my mail and web services in the next few days. I think I'll also move my blog to the new box, but I need to check out how to do this without flooding the planet...
Posted by Marc Brockschmidt at 18:16
(Page 1 of 4, totaling 34 entries) » next page
Other placesixs' Vodkamelone
Syndicate This Blog