Good morning, and welcome to another day of archive damage, i mean hackery. Well, at least at the time of this writing it is morning and we are starting off into another day of work. As we promised to try to have at least a once-a-day-installation run I am currently processing the queue of uploaded packages, around 4gigabytes from 431 changes files. After that a dinstall will follow to push that all out. Lets see how often we can do this again today, yesterday we managed multiple times. Yesterday my work consisted of getting the ries sync into something nice and acceptable, starting to think of the change to only use the suite codenames in future (long term making lots of code issues easier, but short term a good headache) and doing the groundwork so we can upgrade the security and backports archive to squeeze/pg9 too. Mark finished of the Built-Using flag and then moved on to think about database file tracking changes related to multiple archives/locations. Which sounds simple in so few words but is definitely not simple at all. Torsten started to work on source contents and also on generating the packages/sources files out of our database. Both together is taking a good amount of time, so he continues to work on those today. In the evening we had a meeting with the Debian Hurd porters about the future of their port within the Debian archive. The perceived Hurd situation until then was that every port has to follow certain rules or gets thrown out but Hurd doesn t seem to ever get into a releasable state . Well, we did get a clean view on both sides standpoint and in the end emerged with a solution which works for both sides: The Hurd port stays on FTPMaster until Wheezy is released. Should they have managed to get the port into a state that it is released together with all the others (probably as a technology preview), it is kept in the archive. Should they not manage this, the port will be removed from the main archive and move fully to debian-ports.org. It may then reenter the main archive whenever it is ready to get released with the next release. For today we are all continuing in our parts, Mark is yelling at the insanity of the multi-location thing (something we DO need when we want to merge multiple archives, which we do want), Torsten curses the code for Packages/Sources and while I hope that DSA can find time today to upgrade our security- and backports-archive machines to Squeeze, I try to wrap my head around the code we kindly got provided by Serafeim Zanikolas - the dinstall programming fun task I asked a while ago. Im not sure yet I will succeed. :) And then we will get more arrivals this evening, so more people doing stuff tomorrow.

and the newbies are ... A long time ago, in a couple of blog posts far far away, we have introduced the DebConf Newbies initiative. I'm hereby happy to announce the actual DebConf newbies and I'm looking forward to meet them at the forthcoming DebConf10 in New York City:

• Jonathan Wiltshire
• Jon Bernard
• Arnaud Fontaine
• Ben Armstrong
• Arthur Loiret
• Serafeim Zanikolas
• Andreas B. Mundt

Now, folks, please be kind with them, they (still) don't know how crazy we can be(come) during DebConf. Above all: do not harm them (too much) at Mao. In exchange, they have already promised that they will fix all RC bugs that will still be open at the beginning of DebConf10 (or maybe I've just read that in their minds, I don't quite remember ...). Does that mean that DebConf10 travel sponsoring is completely OK as of now? No, not really. This initiative was specifically targeting DebConf newbies, but several DebConf "regulars" are planning to attend too. For some of them the amazing DebConf sponsoring team has already found enough resources to secure their travel sponsorship, for quite some others it is not the case yet. This is a pity, because we know from the past that having more Debian folks at DebConf means more hacking, a better distribution, and a better community, ultimately it means a better Debian. Some of the readers of this blog post will be in the condition to improve the situation: it is as simple as donating to Debian or, better, becoming a DebConf10 sponsor by simply mailing the sponsoring team.

The following developers got their Debian accounts in the last month:

• Scott Kitterman (kitterman)
• Dominique Belhachemi (domibel)
• Sylvain Beucler (beuc)
• Alessio Treglia (alessio)
• Giovanni Mascellani (gio)
• Ulises Vitulli (dererk)
• Tommi Vainikainen (tvainika)
• Serafeim Zanikolas (sez)
• Hideki Yamane (henrich)
• Obey Arthur Liu (arthurliu)
• Thierry Soloniaina Randrianiriana (thierry)
• Thomas Weber (tweber)
• Mikhail Gusarov (dottedmag)
• Ritesh Sarraf (rrs)
• Kanru Chen (koster)

Congratulations!

Serafeim Zanikolas:

With respect to attracting new contributors, please ponder the idea of a formal one-on-one mentoring scheme (as opposed to one-off interactions via d-mentors).

I see nothing particularly objectionable about this. A long time ago people were talking about replacing NM with a saner mentoring process, and I am certain that mentoring occurs unofficially. I see no reason that you could not set up a formal one-on-one mentoring infrastructure with or without the Project's blessing. Charles Plessy:

So my question to other candidates is simple: what is your opinion and program about membership?

I think that we have enough inequality in the project as it is. That is why I consider DM to be a bad thing, even though it has practical benefits. I think that NM is probably fundamentally broken, and I get a bit nervous when people are talking about increasing the amount of NM indoctrination or bureaucracy. I would be in favor of exploring the replacement of NM with some kind of mentorship-type process, though I would worry it would not scale. I would be in favor of exploring the replacement of NM with something like Lars's proposal a while back, though I would worry that it would encourage popularity contests and cliques and cabals. Raphael Hertzog:

1/ Do you believe that it's a good move to standardize our packaging tools? (example: debhelper is almost standard, quilt is gaining status of the standard patch system thanks to the new source format) 3/ Do you have any preference on the tools that we should try to standardize on (which source format/patch system, dh7/CDBS/yada/etc., VCS helper, etc.)? 4/ Organizing changes that have an impact on (a large part of all) the archive is very difficult: How can we change our processes so that doing/organizing such changes is less of a burden? 5/ I have the feeling that Debian is innovating less than it used to do. We are more often followers rather than leaders. Do you share that feeling? What shall we do to make that change?

1/ I think that we should standardize on dpkg-dev. If there are features which absolutely every package needs, it would seem the logical place to add them. 3/ Right now I wish everyone were using git, but I do not believe in forcing them. Of the available source formats, I like 3.0 (quilt) with no additional patch system, and no package helpers at all. I am not quite sure what a VCS helper is so I have no known preference to express. 4/ I am not sure whether or not what you are talking about should, in fact, be less of a burden, and why it should or should not, so I do not have a valid opinion on how to change the process. 5/ I do share that feeling. I think that sometimes we get bullied by Ubuntu when there are things we would do for our own benefit which would make their lives difficult. I think that people are generally resistant to change, even when it would be of little cost to them and great benefit to someone else. These problems are social and might be correctable with a better spirit of teamwork and cooperation. However, I do not think we should be innovating just for innovation's sake or to be known as the most innovative kid on the block. We should be making my favorite operating system.