Joey, I see a huge difference between voting on the current DM proposal and your virtual (sorry, I can’t remember a better word for it) voting on sponsoring uploads. Debian Developers were always allowed to upload any package they saw as fitting into Debian (though there were no guarantees for these packages to actually being included). Also, NMUs are OK if the maintainer agreed. So all they (seemingly) did was putting a different maintainer address into the control file. However, at least in theory, the sponsors were still responsible for their upload if it turned out fishy.
The DM proposal (don’t get me wrong there, I generally support the idea, I just don’t like the way it is implemented in the proposal) is shifting this responsibility from the sponsor onto the shoulders of the DM, which is a good thing. However I think it doubles some of the work the NM queue already needs done, so my proposal would be not to have it as a completely seperate path for a contributor, but instead see it integrated into the NM process. Wether it would mean adding a new maintainer to the DM keyring after he had an advocate (which is pretty near to the current proposal) or after an AM was assigned and checked some basic things (which I would prefer) doesn’t make a lot of difference to me.
See also The DM GR
Following up to Myon’s post, I also wanted to blog my honest opinion about the GR. Given my current understanding of the GR, I hope to see it fail (and will send my vote shortly after this blog entry I think). The reason is not that I think it shouldn’t be made easier to contribute to Debian (on the contrary). But the GR micro-manages too much and on the other hand doesn’t make the current NM process any easier for DM’s than for any non-DM applicant to the NM process. Also, like some others said before, I seriously doubt that a big part of the current DD-applicants (i.e. those in the NM queue at some level) would prefer DM status over DD status. And the same is true (IMHO) for other people wanting to contribute to Debian. This is a simple thing: If I contribute to something regularly in my spare time (like most contributors in the FL/OSS world do), I also would like to have some influence over its directions. And a DM is missing this influence even more than a DD is.
So what should be done instead in my opinion?
I think that a DM like status is fine as part of a (possibly re-designed) NM process. Given the current NM process, I would like people been given a DM like status after they finished the T&S (tasksIIRC and skills) part if their AM found their skills and knowledge of the policy rules sufficient to give them that status. If that is all they wanted, they can drop from the NM process at that point and stay DMs. If they want to become DDs later on, they can resume the NM process at that very step (or continue right ahead).
This would do several things:
- introduce the DM status as an alternative to full DD status
- integrate the DM status closer with the existing NM process
- take some load of the friendly sponsors who upload non-DD packages now, giving them more time to help more new contributors
- give people waiting for DD status some intermediate level at which they already can do more than before their joining of the NM queue
So I really think “more discussion” is the only valid option for me in this GR. If you want to change my mind: Please leave some feedback in my blog. Or give a precise (but brief) description why the current proposal is better than integration with the current NM process in one way or the other.
- DD = Debian Developer (a full Debian project member, includes voting rights)
- DM = Debian Maintainer (planned to be a somewhat restricted DD, among others without voting rights)
- NM = New Maintainer (should actually be: New Developer)
- GR = General Resolution (a way in Debian to create new rules or to ask the project leader or others in the project to do or refrain from doing something)
The GR even seems to contradict itself a bit. If the upload rules are applied in an AND fashion, one of these rules is superfluous (the first one), at least if I’m not mistaken:
- the Maintainer: field of the uploaded .changes file corresponds with the owner of the key used (ie, non-developer maintainers may not sponsor uploads)
- the most recent version of the package uploaded to unstable or experimental includes the field “DM-Upload-Allowed: yes” in the source section of its control file
- the most recent version of the package uploaded to unstable or experimental lists the uploader in the Maintainer: or Uploaders: fields (ie, non-developer maintainers cannot NMU or hijack packages)
The first rules also means that no DM could ever do an upload for packages team-maintained in the fashion cyrus-imapd-2.2 is maintained (Maintainer address is the teams mailinglist address, all uploading team members are in the Uploaders field). This is IMHO a serious flaw in the proposal. If the first rule was dumped, all would be well for team maintainers.
See also Re: voting on sponsorship
See also Dual boot and full encryption
See also another vote
In Improving simple charts, Dirk Eddelbuettel wrote a nice little summary how to produce “nicer” charts using R. However, in my opinion, the charts he provided as alternate options to the original, purely linear graph are less readable for the average person. If anything, using a logarithmic scale on the original Y axis (number of packages not built after a specific date) would be of use, but the other graphs only hide the original point of the post Dirk replied to (How old are our (Debian’s) packages?). The point was that 94% of all packages had been rebuilt since the release of Sarge or, if you want to put it the other way around, 1264 (6%) were built before Sarge was released. This relationship is hidden from immediate recognition by the reader of the graphs. I admit though, that Dirk’s second graph (Number of packages against age in days with the age being on y logarithmic scale) is also insightful. The other two graphs he presents might make sense in a scientific publication if some point in the “more detailed” areas of the graph needs proving, but for this specific problem, they really don’t make sense to me. Actually, I would question their use even in scientific publications, since they distort the original data a lot. Scientists are pretty much used to logarithmic scales these days, but I couldn’t work out how the scales work on those two graphs. And another note on the second graph (logarithmic age): The way the X axis is labeled (10, 20, 50, 100,..) is also pretty non-intuitive to me. I’m much more used to something like 5, 10, 20, 40, 80, 160 and so on, which gives the same distance between each label and seems a lot more usable to me..
(edit: Fix spelling of Dirk’s surname)
See also Debian and Dunc-Tank
See also Microsoft Windows Vista – They did it all wrong
See also UK going completely crazy on cryptography law.