Unexpected move on the DSA front

One should never loose hope apparently. After my previous posts on the topic, Sam put some more pressure and expressed strongly his disappointment in the lack of progress on the DSA front and warned that he might have to look for more radical solution.

Phil Hands (who was really quiet in the discussions) decided that the situation had lasted long enough already and proposed to add Peter Palfrader (weasel@debian.org) to the team if nobody expressed any opposition in 24 hours. And this morning, Phil added weasel to the “adm” group… which make of Peter a full DSA member! :-)

I really didn’t expect this outcome after so many months of negociations and discussions. But I’m really relieved to see some new blood in the DSA team. I wish him good luck and I’ll hope he will be able to foster cooperation with non-DSA people like I tried since the beginning of the year.

Thank you Phil!

The DSA dilemma

For once, Clint blogged on something that I can understand. :-)

I don’t buy everything he says, but in the case of DSA, the part where he says “you cannot have a functional and respectable subgroup if it maintains autonomy like that” is a real problem.

The leadership problem I mentioned is real. And it can theoretically be solved by undelegating one of the problematic side of this DSA-internal dispute. But which one? Given the unwillingness of Joey to discuss the problems, he makes an easy target… which would leave DSA up to Ryan, James and Phil.

But is that a desirable thing? If DSA is perceived as being an “autonomous” group which is not involved in Debian’s main discussions and which is somewhat disconnected from Debian’s day-to-day life, it’s largely due to the behavior of James and Ryan. E-mail communication with them is very difficult as they’ll respond only if they really care about something. And despite the setup of the request tracker, they have barely been able to make proper usage of it… the idea was to use RT tickets to track everything that DSA does but they don’t use it as such. For example, James setup a “wikiadm” group and he never reported anything to the related ticket (#194) (I did it myself once I found out). Also there’s an internal ticket about the replacement of ftp.debian.org (that I created because ftp.d.o ran out of space regularly) and AFAIK Jeroen has been in touch with James to setup that replacement, but nothing got reported to the tracker. Ryan promised me once to put his DSA TODO list in the tracker so that other people can jump in and help out. He never did.

So while Joey is definitely a pain for DSA, at least he’s a visible participant of the team and he interacts with the community. James and Ryan are not, they interact only through private channels and do not share their opinions or their vision of Debian.
I believe this is a real problem. On the other hand, most of the interesting changes in the last months are the results of James’s work. But he’s also implicitly blocking addition of new members as long as the leadership problem is not solved.

I tried to fill the communication void of the DSA team by various means. I follow everything as closely as I can so that I can report changes on other channels, mailing lists when needed. I made efforts to document stuff on the wiki page, etc. But this is not a long term solution, the communication issue must be fixed within the team.

The path ouf of this mess is still not very clear, but something is going to change soon. Not quite sure what though. What would you suggest? And if you were DPL, what would you do?

Since private discussions and negotiations lead nowhere, it’s tempting to bring the issue in the public area. In theory, they have no way to escape discussions and they’ll have to communicate their grudges against the other side if they want to have some fair judgment between both parties. Unfortunately, given the habits of James and Ryan, they probably won’t participate in any public discussion and either resign or stay where they are waiting for any decision…

Comments welcome.

DSA needs a leader

Seriously. Now that we have been using the request tracker for quite some time, it’s even more obvious that the DSA team is not up to its task.

Use login “guest” and password “readonly” if you want to check the RT tickets linked in this article.

The facts

  • 65 public tickets open (and 5 private tickets)
  • 68 tickets closed. Here are some unscientific and manual stats (I counted one each time that someone was involved for the work or for closing the ticket):
    • 27 for James Troup (elmo)
    • 26 for Phil Hands (fil)
    • 13 for me (buxy)
    • 3 for Martin ‘Joey’ Schulze (those I manually forwarded him)
    • 3 for Ryan Murray (neuro)
    • 3 for Matt Taggart (taggart)
    • 2 for Josip Rodin (he handles tickets concerning the mirrors until they have a dedicated queue in the RT)

Note that myself and Matt do not have the needed rights to fix most of the tickets, so we provided help on a best-effort basis. Otherwise we would have done more.

The communication problem

It’s a multi-level problem. Each of the members has some problems with one or more other members. Joey’s behavior has been part of the recurring problems mentioned: he doesn’t use the RT, doesn’t read the DSA email alias and doesn’t follow the DSA IRC channel but he still does stuff very regularly without reporting anything and obviously problems happen. Ryan and James tried to impose him a rule to document what he does, without success apparently. On the other side, as far as I know, Ryan and James also don’t impose themselves to document everything in a central changelog. Joey has refused to provide me an explanation for his behavior. He just reminded me that he holds grudges against James and Ryan because as ftpmasters they didn’t cooperate well with him while he was stable release manager.

In general, outside of all personal griefs that they might have, the DSA members do not communicate very much (at least not on their own official channels). Some examples have already been given concerning the request tracker, but it’s not much more effective on IRC. Most of the traffic on the channel is made up by local admins fixing the problems themselves without any intervention by any DSA.

I also use the channel to regularly ping some DSA about simple issues and/or stuff that they usually handle. It used to work somewhat but lately fil has been busy (with the kernel summit and other conferences) and I simply got no answer at all… for example I pinged elmo, neuro and fil several times in the last weeks in the hope that they handle the tickets of the security team (#150, #157, #164) without results.

There’s room for improvement.

The leadership problem

The team has no designated leader and every time that there’s a decision to take, they are blocked. Joey wouldn’t communicate and give his opinion, Ryan is extremely requiring and perfectionist, there’s not much room for compromise…

A long time ago in a galaxy far, far away, Joey and elmo were friends. It’s even Joey who gave root rights to elmo. Nowadays, it’s rather James that is sort-of leading the team but he’s fed up of the situation and hasn’t managed to get out of this mess.

He refuses to take drastic measures by himself because he’s not clearly the leader and doesn’t solicit a decision of the Debian leader (or the project) because he believes that the DSA team is not under the scope of the constitution!

This can’t last any further. We’ll have to do something about it. Stay tuned.

Planet Debian for users ?

A few days ago I created a planet for French Debian users, and the interest is slowly growing. In fact, I just received a request to add an English-speaking blog!

So the question is: why not creating (and hosting) an English-speaking planet for Debian users that would allow only Debian-related articles. Developers are also users and if they have a feed dedicated to their Debian posts, they could add it of course. It would be handled like the current planet and a few volunteers could collect and process the requests to add new feeds for non-developers.

This would provide the much-requested alternative of filtering planet Debian… and also encourage some of our users to blog about Debian and how they use it.

What do you think of this idea?

Blogging considerations and updates concerning the French planet

Since the policy of the Debian planet is to not restrict content to Debian-related stuff, I switched the URL of my feed in PlanetDebian to include any English content that I might blog about. Don’t be afraid, I’m not going to overwhelm you with random crap. I’m currently trying to blog more in French instead.

Since I maintain the French Debian planet, I decided to apply the same policy for the French version (and announced it here). At the same time I also created a planet for the French-speaking Debian users who happen to blog… it’s hosted on the same server at http://planet-fr.debian.net/users/ and its policy is a bit more strict as it only allows free-software related content.

For all those reasons, I recategorized my articles so that I can now provide an english-only feed and a french-only feed. The first one is used on planet.debian.org and the second one on planet-fr.debian.net.

Continuing on this blogging frenzy, I upgraded WordPress to the latest version, I installed the subscribe-to-comments plugin and translated it to French. Thus it’s now possible to have a sane discussion in the comments of my blog articles!

Planet debian CVS repo superseded by SVN repository

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.

Deprecating cvs.debian.org in favor of Alioth

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. :-)

Thanks sam!

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.

DM and internal politics

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.

Assembling bits of history with git: take two

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
$ git checkout new
$ git-filter-branch --tag-name-filter=cat --parent-filter \
"sed -e 's/^$/-p 0975870bb1631379f2da798fa78736a4fe32960a/'" \
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