apt-get install debian-wizard

Is forking NM good?

July 27, 2007 by Raphaël Hertzog

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. 🙂

Some changes concerning DSA

July 26, 2007 by Raphaël Hertzog

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.

Assembling bits of history with git

July 24, 2007 by Raphaël Hertzog

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…

On Debian Maintainers

July 22, 2007 by Raphaël Hertzog

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.

Tags

Recent Posts