Buxy rêve tout haut

When I discussed the deprecation of cvs.debian.org, I forgot to mention that planet’s CVS repository was also part of the last users of this service.

Thanks to mako, the move to Alioth is underway. The CVS repository has been disabled (crude hack, if you know a proper way to forbid commits to a CVS repository, please leave a comment) and its history has been imported in a new SVN repository

As usual DD have write-access on this repository so that they can add/update their feeds and hackergotchis. Mako will change the live setup from CVS to SVN somewhat later today.

Please start updating any documentation that refers to the CVS repository.

It’s very difficult to discuss with DSA and make things evolve if none of the DSA member express an interest in something related to your goal: here comes an example of a story like another in my desperate quest to try to help the DSA team.

Last time gluck ran out of space, a few non-DSA people (me, taggart, Ganneff, and others I might have forgotten) contacted people to ask them to clean their home directories. Following that discussion we discussed a bit about the opportunity to move some services from gluck on another host. Among the services on gluck, there’s cvs.debian.org. As an Alioth administrator, it struck me that cvs.debian.org is the only VCS service that’s handled by the DSA team. It seems logical to not duplicate the administrative work and have all the VCS repositories handled by the same team.

The logical conclusion is that cvs.debian.org should be deprecated in favor of Alioth. So I made the suggestion in RT ticket #146 (login with guest/readonly). I got exactly zero response from DSA. No support and no opposition. So I went ahead and contacted the last users of cvs.debian.org:

• webwml: the website team
• debian-doc: the Debian documentation project
• debian-admin: the DSA team (this was already suggested in April this year in ticket #44, no response of course… except elmo saying me that he’s in favor. On IRC I also discovered that neuro doesn’t like bzr and is thus not in favor of such a move. Furthermore he visibly wants to keep control on userdir-ldap, thus he probably has not much interest in moving to a distributed system.)
• buildd: the Packages-arch-specific file is maintained in the dak cvs…

All in all, the debian-doc and debian-www folks are rather supportive of the move, but it requires adjustment to the build infrastructure, in particular to keep track of the status of translations. I have no answer from DSA and the buildd guys however.

The web team started a wiki page to evaluate the VCS that they would switch to. Volunteers would be welcome to organize the conversion of the repositories and to fix the build infrastructure accordingly. This a nice little project for new contributors that want to learn.

I really appreciated your last Bits of the DPL.

I discover a DPL taking position on hot topics of the moment. I’m glad to have a DPL who is trying to fulfill his duty of leading discussions amongst developers. He gave his opinion on the current vote about “endorsing the concept of Debian Maintainers” (he’s in favor because it dilutes power) and also about Apt’s change to install Recommends by default. I’m glad to hear the encouraging news concerning volunteers for ftpmasters.

By the way, if you have voted for Sam, and if Sam’s opinion bears any importance for you, you still have until saturday midnight (UTC) to change your vote if you wish so (like Russ did). Right now, only 289 DD have voted.

If you don’t follow debian-vote, you have missed this.

It’s really worth a read before casting your final vote on this issue. As I explained in my reply to Russ, this vote is not about details but whether we want to have an intermediate level between DD and nothing, or not.

If you don’t give an initial policy, then people against DM will use that “hole” to block it because “it’s not how DM must be done” (and then you’ll need another GR to define a correct implementation and overrule those who are blocking). Yet people keep mixing issues when discussing DM. For some, DM is okay if we had a working NM system. For some, DM would be okay if the responsibility to give upload rights didn’t rely on DD but on a sort of QA committee. For some, DM would be okay if it were integrated in NM. There are also people who are opposed to this second class of contributors but I don’t think they are a majority. Still we might loose a nice opportunity because people want to solve too many things at once instead of doing a first step in a new direction.

Following my previous article, I had some interesting comments introducing me to git-filter-branch (which is a new function coming from cogito’s cg-admin-rewritehist). This command is really designed to rewrite the history and you can do much more changes… it enabled me to fix the dates/authors/committers/logs of all the commits that were created with git_load_dirs. It can also be used to add one or more “parent commits” to any commit.

In parallel I discovered some problems with the git repository that I created: the tags were no more pointing to my master branch. This is because git rebase won’t convert them while rewriting history.

This lead me to redo everything from scratch. This time I used git-filter-branch instead. The man page even gives an example of how to link two branches together as if one was the predecessor of the other. Here’s how you can do it: let’s bind together “old” and “new”… the resulting branch will be “new-rewritten”.

$ git rev-parse old
0975870bb1631379f2da798fa78736a4fe32960a
$ git checkout new
$ git-filter-branch --tag-name-filter=cat --parent-filter \
"sed -e 's/^$/-p 0975870bb1631379f2da798fa78736a4fe32960a/'" \
new-rewritten
[...]
Rewritten history saved to the new-rewritten branch

Short explanation: the only commit without a parent commit (thus matching the empty regex “^$”) is the root commit and this one is changed to have a parent (-p) which is the last commit of the branch “old”.

At the end, you remove all the temporary branches, keep only what’s needed and repack everything to save space:


$ git branch -D old new
$ git prune
$ git repack -a -d


In a discussion with Bdale, he suggested that DM is seen as forking NM. And some people do not like forks. They are not opposed to DM in principle but do not want it outside of the current NM team.

Obviously DM tries to respond to cases that NM is not prepared to handle. Furthermore, the DM discussion has been active for quite some time and the various members of the NM team (Frontdesk, DAM) have not participated much in the public discussion. Only when it comes to a vote do we hear some more (negative) opinions. I don’t see that as a sign of willingness to integrate DM or something similar in the current NM structure.

So people who are requesting DM to be integrated in NM, please take it up with the frontdesk/DAM… and don’t oppose the principle just because of organizational matters.

Internal organization always change and adapt themselves to the situation. Joey is right when he compares this to the introduction of the sponsorship process. I was one of the main actor in that process. I introduced the concept without the consent of the NM team (James Troup, Martin “Joey” Schulze) at that time.

It was a fork, a new way to proceed and it became mainstream with the creation of the current NM process. It’s the natural way of doing things in a free software project.

That said, I’m not opposed to improving our NM process. It really needs to be reworked in a “Membership Process” and be open to various kinds of contributors. That’s why I created a dedicated wiki page: http://wiki.debian.org/Projects/ReformedMembershipProcess

Let’s see if we’re ready to really fix that! I hope to have comments from all the people who look to be so eager to fix the NM process.

Since march the DSA team uses a request tracker to handle all the requests that they get.

Therefore you should no more use the debian-admin@debian.org alias (DSA members only). The debian-admin@lists.debian.org mailing list (DSA + local admins) is also scheduled for removal. Instead you should mail admin@rt.debian.org making sure to put “Debian RT” somewhere in the subject (crude but working spam prevention). By default, your ticket ends up in a private incoming queue. Up to now only DSA members had access to those queues. They moved most tickets in the public queue but it happened several times that this simple administrative burden took several weeks.

Since a few days, Matt Taggart and myself have been granted RT accounts with required privileges to handle tickets and move them between the various queues. So from now on, all tickets will be quickly moved in the public queue (when they don’t contain sensitive information of course). We’ll be able to do some triage and ping DSA members for urgent requests.

Matt and me have been trying to help out the DSA team for quite some time now, and while we’re not DSA with root rights, we’re in regular contact with the members (except Martin “Joey” Schulze who refuses to join the DSA IRC channel, who doesn’t use the request tracker and who doesn’t read the DSA mails either) and with several local admins. So if you have some troubles interacting with the DSA team, you can try to get in touch with us and we’ll see if we can help you.

In too many cases people contact directly individual DSA members (Joey in particular). Please refrain from doing so, other volunteers (who might help you) won’t notice your request. Furthermore systematic request tracker usage helps us identifying what is well handled and what’s not. And it’s not more complicated than a simple email for you.

Update: currently local admins are not subscribed to the request tracker. The RT setup will need some further adjustment for that, so the debian-admin@lists.debian.org list can still be useful if you want to reach them.

The dpkg team has a nice history of changing VCS over time. At the beginning, Ian Jackson simply uploaded new tarballs, then CVS was used during a few years, then Arch got used and up to now Subversion was used. When the subversion repository got created, the arch history has not been integrated as somehow the conversion tools didn’t work.

Now we’re likely to move over git for various reasons and we wanted to get back the various bits of history stored in the different VCS. Unfortunately we lost the arch repository. So we have disjoints bits of history and we want to put them all in a single nice git branch… git comes with git-cvsimport, git-archimport and git-svnimport, so converting CVS/SVN/Arch repositories is relatively easy. But you end up with several repositories and several branches.

Git comes with a nice feature called “git rebase” which is able to replay history over another branch, but for this to work you need to have a common ancestor in the branch used for the rebase. That’s not the case… so let’s try to create that common ancestor! Extracting the first tree from the newest branch and committing it on top on the oldest branch will give that common ancestor because two identical trees will have the same identifier. Using git_load_dirs you can easily load a tree in your git repository, and “git archive” will let you extract the first tree too.

In short, let’s see how I attach the “master” branch of my “git-svn” repository to the “master” branch of my “git-cvs” repository:

$ cd git-svn
$ git-rev-list --all | tail -1
0d6ec86c5d05f7e60a484c68d37fb5fc31146c40
$ git-archive --prefix=dpkg-1.13.11/ 0d6ec86c5d05f7e60a484c68d37fb5fc31146c40 | (cd /tmp && tar xf -)
$ cd ../git-cvs
$ git checkout master
$ git_load_dirs -L"Fake commit to link SVN to older CVS history" /tmp/dpkg-1.13.11
[...]
$ git fetch ../git-svn master:svn
$ git checkout svn
$ git rebase master

That’s it, your svn branch now contains the old cvs history. Repeat as many times as necessary…

I won’t re-explain in great length why I think it’s good to endorse the concept of Debian Maintainers. I have been enough involved in the debian-vote discussions (and the previous debian-project discussions).

I would just like to remind everybody that we elected sam to see changes and progress on many areas. We haven’t seen many results yet, but I know that sam has been working hard and I’ve been helping him as much as I can on the problem of our DSA team (one day I might blog about it or even start a GR if the situation continues to not improve despite the numerous efforts that we’ve put into it).

Here we have a concrete proposal for a change, and I believe a change for the better. But just like for every change, people have fears: they fear people who only care about technical excellence and not too much about philosophy, they fear that the quality level will drop, they fear that nobody will care about NM afterwards, etc.

It’s legitimate to have concerns, to express them and to discuss them. But we should not let them take us over or we’ll end up abandoning all initiatives that are required to evolve and adjust to our moving environment.

We need to encourage people who are ready to try out new things. In cases where it’s not entirely clear how the situation will evolve, it’s better to try out and react accordingly instead of doing nothing and hoping that people will wait us. When we do things while hoping for the best, the worst won’t come up true so easily.

Have faith in our future.

Sam is our new DPL. The margin with the second (Steve McIntyre again!) is very slim, 8 votes. And Steve only has 25 votes more than me. That’s not much either.

What we can learn from this election:

• the principle of a DPL board makes its way, I have been ranked well above NOTA and I have been mainly advocating this proposal (and this despite some votes anti-dunc-tank that I probably suffered from)
• my selection of board members was pretty good, the 4 candidates that I selected for the board are the top-4 of the election
• Debian developers are fed up by the various problems in some core teams (overwhelmed, not recruiting new members, not communicating enough, etc.). I’ll try to help Sam fix those issues, but it’s going to be a big challenge for us.

In the end, I really hope that sam is going to find a way to cooperate closely with the various candidates that are still highly motivated to work on improving Debian. I doubt that he will choose a board structure (although I would be glad to be proven wrong!), but I really hope that he will expand the 2IC principle (or something similar).

I once told sam that he would have my full support if he got elected, and I intend to stand up to this promise. I said that because I share many of his ideas. The few fears that I have are mainly on how he is going to try to address these issues. But I have no reason to believe that he’s not going to listen to what we (and I) have to say. That’s why he got ranked just after me on my ballot.

Good luck Sam, do not disappoint us!