Archives for 2011

My Debian activities in April 2011

May 3, 2011 by Raphaël Hertzog

This is my monthly summary of my Debian related activities. If you’re among the people who support my work, then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.

GNOME 3 packaging

Right after the GNOME 3 release, I was eager to try it out so I helped the pkg-gnome team to update some of the packages. I did some uploads of totem, totem-pl-parser, gvfs, mutter, gnome-shell, gnome-screensaver. I also kept people informed via my blog and prepared a pinning file for adventurous users who wanted to try it out from experimental (like me).

One month later, I’m still using GNOME 3. There are rough edges still, but not so many. And I’m starting to get used to it.

Debian Rolling planning

Debian Rolling is a project on my TODO list for quite some time. I decided it was time to do something about it and started a series of articles to help clarify my ideas while getting some early feedback. My goal was to prepare a somewhat polished proposal before posting it to a Debian mailing list.

But as usual with Murphy’s law, my plan did not work out as expected. Almost immediately after my first post the discussion started on debian-devel:

At this point it’s a discussion thread of several hundreds of messages (there are several screens of messages like the one above). Many of the sub-threads have been interesting, but the general discussions mixed too many different things so that there’s no clear outcome yet. Lucas Nussbaum tried to make a summary.

Obviously I must adjust my plan, there’s lots of feedback to process. I accepted to drive a DEP together with Sean Finney to help structure the part of the discussion that focuses on allowing development to continue during freezes. But I’m also eager to fix the marketing problem of testing and have the project recognize that testing is a product in itself and that end-users should be encouraged to use it.

Package Tracking System maintenance

The Package Tracking System is an important tool for Debian developers, and it has been broken by some change on the Bug Tracking System. I worked around it quite quickly so that few people noticed the problem but Cron kept reminding me that I had to properly fix it.

I ended up doing it last week-end. While working on the PTS, I took the opportunity to merge a patch from Jan Dittberner to enhance the news RSS feed that the PTS provides. And I also integrated information from backports.debian.org (thanks to Mehdi Dogguy for reminding me #549115).

Multiarch update

Not much new this month. I fixed two bugs in the multiarch dpkg branch thanks to bug reports from Ubuntu users (LP 767634, LP 756381). I’m still waiting on Guillem Jover finishing his review of the multiarch branch. I’m pinging him from time to time but it looks like multi-arch is no longer in his short term priority list. 🙁

I’ve been running this code for more than 2 months and it works fine. I want to see it merged. I’m ready to update my code should anything need to be changed to please Guillem. But without any feedback we’re in a deadlock.

Misc dpkg work

While fixing a bug in update-alternatives (found in one of the valid reports on launchpad), I noticed that there was room for improvements in the error messages output by update-alternatives. I changed them to reuse the same strings that were already used in other parts of dpkg. The result is that there are a few strings less to translate (always a nice thing for the poor translators who have to deal with the thousands of strings that dpkg contains).

I also tried to fix some of the most cryptic error messages in dpkg (see #621763) but that work is stalled at the request of Guillem.

Book update

We (me and Roland Mas) are almost done with the update of our French book for Debian Squeeze. It will hit the shelves in July or September. I’m starting to prepare the fundraising campaign to make an English translation of it. We’ll use ulule.com for this.

On my blog

I have been pleased to interview Meike Reichle, it’s the first women that I have interviewed in the series but it’s certainly not the last one. I also interviewed Adam D. Barratt, one of our tireless release managers.

Thanks

Many thanks to the people who gave me 180.35 € in March and 235.37 € in April. That represents 1.5 and 2 days of work for those months.

See you next month for a new summary of my activities.

Discover New Free Software to Flattr

May 1, 2011 by Raphaël Hertzog

You’re getting used to it by now, a new month comes with a new set of free software projects that are using Flattr.

By the way, the number of free software projects accepting donations via Flattr might quickly increase now that Flattr dropped the requirement to put money in the system to be able to receive donations (see the announce here).

Remuco (Flattr link) lets you control your Linux Media Player remotely from your mobile phone (via Bluetooth or Wifi). It supports a wide range of media players. It can run on any mobile phone supporting Java (J2ME) but there’s also a dedicated Android client.
GNU SASL (Flattr link) is an implementation of the Simple Authentication and Security Layer framework that is used by many network services (e.g., IMAP, SMTP) to request authentication from clients, and also to respond to those authentication requests.
Bley (Flattr link) is an intelligent greylisting daemon for Postfix. It triggers the greylisting only on suspicious clients listed on common black lists (RBL) thus avoiding the delay for most legitimate mails. I like this setup but I have been using whitelister to achieve this.
OpenStreetGame (Flattr link) is a little educative game that you can play in your browser. It gives you a city (a capital of a country) and you have to click on its location on the map. If you’re too far, you won’t be able to complete the levels of increasing difficulty. It’s a simple way to learn some geography…
Debian Administration (Flattr link) is a website with lots of articles about the administration of Debian systems. It’s run by Steve Kemp (a former Debian developer) but the articles are contributed by many volunteers. Free software gives its best when it comes with good free documentation.

This article is part of the Flattr FOSS project.

Do we need project-wide support for Debian rolling?

April 29, 2011 by Raphaël Hertzog

The discussion about Debian rolling started sooner than expected on debian-devel (see the thread here). I initially wanted to iron out the biggest problems through discussions on my blog and try to submit a somewhat polished proposal… instead we ended up discussing the same things both on -devel and on my blog.

That said it’s not that bad (except for the time I lost to have similar conversations in both places) because the debian-devel discussions included members of the release team and it looks like they are not fundamentally opposed to the idea.

Despite this, the introduction of a “frozen” suite branched off from “testing/rolling” is not really consensual (yet?). But the idea of officially supporting testing on a best-effort basis appears to have almost no opposition.

While some will undoubtedly believe that this is a useless exercise, I believe it would help if the project stated this in a somewhat official manner. My answer to the question in the title is thus:

YES

I am thus considering to submit a general resolution to that effect. My current draft is below.

Title: Debian endorses usage of testing by end-users, and renames it to rolling

The Debian project recognizes that the Debian testing distribution—initially created to make it easier to prepare and test the next stable release—has become a useful product of its own. It satisfies the needs of users who are looking for the latest stable versions of software and who can cope (or even appreciate) a system that’s constantly evolving.

The Debian project decides to endorse this usage and will strive to provide a good experience to users of “testing”. To better communicate this policy change to our users, “testing” will be renamed “rolling”.

While we believe that this is a good move, we would like to remind our users that Debian is a volunteer project and that our resources are not infinite. Package maintainers are contributing to Debian on a best-effort basis. This means that they might not be able to properly support their package(s) in all distributions. In that case, the project recommends that maintainers apply the following priorities:

Support in stable (security updates, release critical bugs)

Preparation of the next stable release

Support in rolling

Note that this general resolution could have amendments with s/rolling/current/ and that would solve the bikeshedding over the name that started several times already.

I deliberately separated “Preparation of the next stable release” and “Support in rolling” so that priorities are clear even if we decide to not freeze “rolling” and to introduce a “frozen” distribution to finalize the next stable release.

I also did not go into too much details on the implications that it might have, it’s best to leave that up to each contributor/team/etc.

I hesitated to add a paragraph stating that we want to try to gradually improve the usability of testing but in the end I think it would be somewhat redundant. We’re always trying to do our best when we decide to take on something.

All comments welcome (even if you just agree and would be willing to second such a GR).

Update: I will tweak the draft included in this article when I get good suggestions. Thanks to Lucas Nussbaum for the first one.

No freeze of Debian’s development, what does it entail?

April 28, 2011 by Raphaël Hertzog

The main feature of rolling is that it would never freeze. This is not without consequences.

Possible consequences

It can divert developers from working on the release

No freeze means developers are free to continue their work as usual in unstable. Will it be more difficult to release because some people will spend their time working on a new upstream version instead of fixing RC bugs in the version that is frozen? Would we lose the work of the people who do lots of NMU to help with the release?

It makes it more difficult to cherry-pick updates from unstable

No freeze also means that unstable is going to diverge sooner from testing and it will be more difficult to cherry-pick updates from unstable into testing. And the release team likes to cherry-pick updates that have been tested in unstable because updates that comes through testing-proposed-updates have often not been tested and need thus a more careful review.

Frozen earth

My responses to the objections

Those are the two major objections that we’ll have to respond to. Let’s try to analyze them a bit more.

It’s not testing vs rolling

On the first objection I would like to respond that we must not put “testing” and “rolling/unstable” in opposition. The fact that a contributor can’t do its work as usual in unstable does not mean that he will instead choose to work on fixing RC bugs in testing. Probably that some do, but in my experience we simply spend our time differently, either working more on non-Debian stuff or doing mostly hidden work that is then released in big batches at the start of the next cycle (which tends to create problems of its own).

I would also like to argue that by giving more exposure to rolling and encouraging developers to properly support their packages in rolling, it probably means that the overall state of rolling should become gradually better compared to what we’re currently used to with testing.

The objection that rolling would divert resources from getting testing in a releasable shape is difficult to prove and/or disprove. The best way to have some objective data would be to setup a questionnaire and to ask all maintainers. Any volunteer for that?

Unstable as a test-bed for RC bugfixes?

It’s true that unstable will quickly diverge from testing and that it will be more difficult to cherry-pick updates from unstable into testing. This cannot be refuted, it’s a downside given the current workflow of the release team.

But I wonder if the importance of this workflow is not overdone. The reason why they like to cherry-pick from unstable is because it gives them some confidence that the update has not caused other regressions and ensures that testing is improving.

But if they’re considering to cherry-pick an update, it’s because the current package in testing is plagued by an RC bug. Supposing that the updated package has introduced a regression, is it really better to keep the current RC bug compared to trading it for a new regression? It sure depends on the precise bugs involved so that’s why they prefer to know up-front about the regression instead of making a blind bet.

Given this, I think we should use testing-proposed-updates (tpu) as a test-bed for RC bug fixes. We should ask beta-testers to activate this repository and to file RC bugs for any regression. And instead of requiring a full review by a release manager for all uploads to testing-proposed-updates, uploads should be auto-accepted provided that they do not change the upstream version and that they do not add/remove binary packages. Other uploads would still need manual approval by the release managers.

On top of this, we can also add an infrastructure to encourage peer-reviews of t-p-u uploads so that reviews become more opportunistic instead of systematic. Positive reviews would help reduce the aging required in t-p-u before being accepted into testing.

This changes the balance by giving a bit more freedom to maintainers but still keeps the safety net that release managers need to have. It should also reduce the overall amount of work that the release team has to do.

Comments welcome

Do you see other important objections beside the two that I mentioned?

Do you have other ideas to overcome those objections?

What do you think of my responses? Does your experience infirm or confirm my point of view?