Re: Developer Status
On Fri, Oct 24, 2008 at 03:16:54PM +0200, Giacomo A. Catenazzi wrote: Sorry for being late in discussion, but I was quite busy... To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. Erm, well, it's one thing that I might be able to pass packaging tests as well as I fiddle with debian/control and such from time to time, but that's nothing I want to do at all (packaging). The other thing is: why test packaging in the first place when asking ftp-admin later to remove upload rights? That doesn't make much sense to me... ;) I think most of our experienced users will have enough capabilities for a simple test, and anyway, I would not put him in an other category. Let giving him other tests, but let him to be a normal Debian Developer. This giving him other tests seems to be the problem. When I applied as NM back then, there were apparently no other tests than packaging tests. At least nothing knew how to deal with my I don't want to package application so I wasn't assigned an AM for a whole year. who is not interested on upload packages. No need for new categories. I'm in favour with Martins proposal to change the whole to role based permissions, not categories. Voting people should be trusting people, so without constitutional limits. He would decide to have restricted rights. Trust was one of my major reasons to apply as NM back then, because I felt that it would be better to have a strong trust relationship between the Project and myself, because m68k is being built on approx. 5 machines (out of 20) of mine. Another reason was/is that I'm often already seen as part of the Debian project by others. I then need to explain that I'm not a DD, but just a random contributor, although the perception ot other peoples is different. Doing some advocacy for Debian on fairs and meetings is another point. I'm not comfortable with saying we in Debian when I'm not really a member of it. Well, 'nuff said... when there's a decision about a change in NM/becoming a member I might re-apply happily and I believe Debian would benefit from other peoples skills (i.e. not packaging) as well. -- Ciao...// Fon: 0381-2744150 Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Sun, Oct 26, 2008 at 04:24:24PM -0300, Felipe Sateler wrote: The Debian Contributor class is a class of people that the Debian project doesn't give any tool/resource to do their work. Which is untrue: - you can dig in this thread and you will find members of DSA stating that DC can be given shell access to project machines if they need it - examples of well respected porters which nowadays are nothing for Debian (in term of how we recognize them, not in term of how useful they are for us!) can be given access to buildds / port machines - as per my proposal in a separate thread they can be given @debian.org mail addresses - on the same lines, they can be given commit access rights to the repository of some of our infrastructure (e.g., the PTS, whose committers nowadays need to be DDs, for no evident reason) Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
Stefano Zacchiroli wrote: On Sun, Oct 26, 2008 at 04:24:24PM -0300, Felipe Sateler wrote: The Debian Contributor class is a class of people that the Debian project doesn't give any tool/resource to do their work. Which is untrue: - you can dig in this thread and you will find members of DSA stating that DC can be given shell access to project machines if they need it - examples of well respected porters which nowadays are nothing for Debian (in term of how we recognize them, not in term of how useful they are for us!) can be given access to buildds / port machines - as per my proposal in a separate thread they can be given @debian.org mail addresses None of which were in the original proposal/announcement. These kind of stuff would indeed make it much better (although I still have my doubts on the design, which is why I haven't proposed any similar fixes). - on the same lines, they can be given commit access rights to the repository of some of our infrastructure (e.g., the PTS, whose committers nowadays need to be DDs, for no evident reason) That is a separate problem that just happens to be possibly solved by this. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Stefano Zacchiroli wrote: On Sat, Oct 25, 2008 at 04:56:36PM -0300, Felipe Sateler wrote: My name is on the Maintainer field of 2 packages in main, and I think we can consider the Maintainer fields as a list of contributors (evidently, not all of them). I haven't (formally) agreed to any document, my key is not signed by anyone in the project, I haven't been advocated by anyone and certainly have not answered any set of predefined questions. Why should the bar for non-developing contributors should be different than mine (ie, they have to do more than just the work they are contributing)? Nobody is saying that to contribute in general you will need something more than at present. For example, nobody is proposing to get rid of sponsors (which are now, and will be also in the future, to sponsor anybody's work), or to inhibit people submit patches to the BTS (they are contributors too!). Still (part of) the proposal is to introduce a particular class of contributors which is also able to vote on choices of the Debian project (elections and GR). In the initial proposal that class happens to be called Debian Contributors, but that's just a matter of naming, and you can argue that it is an inappropriate one. The Debian Contributor class is a class of people that can't do anything. Debian Members can vote. I think that the Debian Contributor class (which in the end is a mere ACK that their work is appreciated) should have a particularly low bar. Perhaps one advocation or two. Still, I hope you see the reason for adding some checks before letting people to vote upon choices which are bounding for the Debian project. After all sponsored uploads and patches are subject to review, why voting rights shouldn't? And note that the bar would basically be ID+PP, which boils down to checking that you have an identity and that you share the ideals of the Debian project. Of course. I have to note that I'm arguing against parts of the proposal that I think aren't OK, not the whole thing. I think that the general idea of the proposal is good, but it is not correctly implemented. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Sun, Oct 26, 2008 at 12:30:02PM -0300, Felipe Sateler wrote: The Debian Contributor class is a class of people that can't do anything. Sure, it really sounds good… -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Yves-Alexis Perez wrote: On Sun, Oct 26, 2008 at 12:30:02PM -0300, Felipe Sateler wrote: The Debian Contributor class is a class of people that can't do anything. Sure, it really sounds good… I'm not sure what you wanted to say with that, but I'll clarify my statement. The Debian Contributor class is a class of people that the Debian project doesn't give any tool/resource to do their work. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Wouter Verhelst wrote: On Fri, Oct 24, 2008 at 04:30:31PM +0200, Giacomo A. Catenazzi wrote: Joey Schulze wrote: Giacomo A. Catenazzi wrote: To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. Why should he do a packaging test? Why should translators of the website? They do not intend to do packaging. It should be not mandatory, but I think it is interesting to him to know the very basic packaging. Regardless, at the time, Ingo felt that there was no way for him to be able to get through NM without knowing stuff about packaging. That is not a good thing (I've known Ingo for quite some time now, and he's a very knowledgeable person, on Debian as a whole and the m68k port specifically) Ok, So a modified proposal: - no DME: we should trust our voters. - A recommendation to the people/teams responsible to choose the test structure and to validate candidates: The tests should be on various tasks/areas, Some areas are possibly mandatory (ID check, social contract, BTS, legal) Note: ev. targeted tests on BTS and legal (e.g. about copying, trivial changes, etc, instead of software compliance, but remember the most of last votes was about licenses and non-free) Some area are targeted: packing, using i18n system, vcs and web scripts (for web-translators, etc.), basic security (for shell accounts). Who pass the mandatory test and is a developer i.e. an active contributor to Debian could became DD and thus voter. Based on the targeted tests (but free to have also other ways), the ftp-masters, i18n-team, web-team, debian-admin, could grant permissions for uploads, ssh, etc. In this manner we have no formal differences between DD, but restricted access based about capabilities. Changing permission is thus done in less formal way by various teams. In short: Debian cares about active contributors which agree on social contract etc. and who help Debian to advances. The ftp-masters care about packages (NEW packages, NEW uploades), etc. Note: so in this proposal there is only one formal change: the debian contributors. The other things could be done informally. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Giacomo A. Catenazzi wrote: Do you think a Debian voter would not be interested on other areas? Not to be an expert, but a very simple tests could be useful, and not the test for usual packers. If somebody is *interested* in something they will teach themselves. The Debian project does not need to assume somebody could be interested in something and force them to learn it. Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Bas Wijnen wrote: On Thu, Oct 23, 2008 at 05:40:32PM -0300, Felipe Sateler wrote: Basically, they need to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions similar to the ones used in the current first PP step, to keep doing the same thing they have been doing all this time. No. Current Debian Maintainers also need an ID check, agree to SC/DFSG/DMUP and be advocated. The only thing that is added (and that was made clear by Joerg), is that they need to answer a very limited set of questions. I am talking about the DNDCs here. DNDCs have no priviledge whatsoever besides getting included in a list. Yes, and possibly getting a @contributor.debian.org e-mail, appearantly. So what does Debian want to do? We want to show those people we appreciate their work, and we want them to be able to tell others that they do work for Debian. We also want this to be worth something, so we shouldn't add just anyone to the list, but only people who agree with our philosophy. In order to be able to say anything, we need e-mail most of the time, and in order to identify someone as the person I'm talking about, we need a signed key. So the ID check is going to stay. For the philosophy thing, we need agreement with our foundational documents (which isn't any problem, of course). The need to be advocated seems reasonable to me as well, to maintain the status of that list. So there's only answering the questions, and I think that was only the case for DDC, not DNDC. My name is on the Maintainer field of 2 packages in main, and I think we can consider the Maintainer fields as a list of contributors (evidently, not all of them). I haven't (formally) agreed to any document, my key is not signed by anyone in the project, I haven't been advocated by anyone and certainly have not answered any set of predefined questions. Why should the bar for non-developing contributors should be different than mine (ie, they have to do more than just the work they are contributing)? Becoming a Debian Maintainer is supposed to be a light-weight version of the New Maintainer process. It's not a I'll skip the New Maintainer process entirely-version. If the current Debian Maintainer process is failing for some reason, please elaborate. If it's not, then I don't see why adding more checks is useful. I don't think it's failing, but I also don't see where the more checks would be. You're talking about the very limited TS questions? Jörg made it clear that this wouldn't be much trouble, and that people should be able to finish the checks in a very short time. You may be right that there's no reason for them, and in that case it would be better to remove them. But it's also not a big issue IMO. Maybe. But then, big issues are IME created usually by small incremental issues. I think the burden of proof is on the proposer's side, not the other way around. But I think that for general upload rights the bar is way lower. As I said in another message, 1 year is enough to do a lot of work, but spending half of that year waiting is not useful, I think. If a person needs to learn about Debian packaging at the start of the year, then I don't think it's reasonable to expect much work on more than a few packages, at least in the first 6 months. And for a few packages, there's no need to get full upload rights. Just becoming a DC is enough for that, and that needs no waiting. Only if this person applies for DC status at the start of said year, which may or may not be what people are actually doing: my first package was uploaded in 2006 and I still haven't applied for DD or DM. Others may do it differently. You seem to want to rush total outsiders into the most priviledged positions of the project. Why would that be a good thing? What is the problem of letting people work 6 months with slightly fewer rights? I don't want to rush people into privileged positions. I object arbitrary limits, specially when I think the limit will miss many important cases. I don't see the many cases you are talking about. One effect of this proposal is that people should apply for DC when they are getting started. If people don't do that, but instead are active but not in any keyring, then 6 months is a long time to wait before being able to apply for DM. Apparently I was thinking mostly in the latter case than the former. I consider it nonsense to apply for official status while doing my first contributions to a project. I don't usually go to a project and say hey, I want to contribute, please give me (restricted) access to your VCS. I think it would also cause more work for the people administering the Dx queues, which I hear are already overworked. It could be good to allow skipping of the delay for one month per advocate, which means you need to get seven advocations (one to start, plus one for each month) to start
Re: Developer Status
On Fri, Oct 24, 2008 at 04:56:09PM +0200, Wouter Verhelst wrote: If you insist. Note that I'll vote against it -- I've never liked procedures whose sole purpose is to change procedures. This is not much of an argument. DEPs were indeed intended to change procedures, but to reach specific goals, for example knowing in which state a proposal was left, and who is responsible for it. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
On Fri, Oct 24, 2008 at 09:51:01AM +0200, Bas Wijnen wrote: Hence, I still don't by your argument. I admit that that wasn't the strongest point. The main reason is the part you didn't quote, though: I understand, but remember that my objection was about dismissing DD, I did not comment at all on the other parts of your proposal. [ Still, I found quite telling that I can't remember your acronyms without looking again at your mail, while I still remember the names proposed in Joerg's mail. But I admin that this a brand new argument, maybe it's unfair to put it here :-P ] Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
On Sat, Oct 25, 2008 at 04:56:36PM -0300, Felipe Sateler wrote: My name is on the Maintainer field of 2 packages in main, and I think we can consider the Maintainer fields as a list of contributors (evidently, not all of them). I haven't (formally) agreed to any document, my key is not signed by anyone in the project, I haven't been advocated by anyone and certainly have not answered any set of predefined questions. Why should the bar for non-developing contributors should be different than mine (ie, they have to do more than just the work they are contributing)? Nobody is saying that to contribute in general you will need something more than at present. For example, nobody is proposing to get rid of sponsors (which are now, and will be also in the future, to sponsor anybody's work), or to inhibit people submit patches to the BTS (they are contributors too!). Still (part of) the proposal is to introduce a particular class of contributors which is also able to vote on choices of the Debian project (elections and GR). In the initial proposal that class happens to be called Debian Contributors, but that's just a matter of naming, and you can argue that it is an inappropriate one. Still, I hope you see the reason for adding some checks before letting people to vote upon choices which are bounding for the Debian project. After all sponsored uploads and patches are subject to review, why voting rights shouldn't? And note that the bar would basically be ID+PP, which boils down to checking that you have an identity and that you share the ideals of the Debian project. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
On Sun, 26 Oct 2008 00:24:06 +0200, Stefano Zacchiroli wrote:
[ Still, I found quite telling that I can't remember your acronyms
without looking again at your mail, while I still remember the
names proposed in Joerg's mail.
For me it's exactly the other way round, but I guess referring to our
memories doesn't prove more than that preferences for naming schemes
are a bit subjective :)
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-BOFH excuse #56: Electricians made popcorn in the power supply
signature.asc
Description: Digital signature
Re: Developer Status
On Fri, Oct 24, 2008 at 12:02:57AM +0200, Stefano Zacchiroli wrote: On Thu, Oct 23, 2008 at 10:55:55PM +0200, Bas Wijnen wrote: Given how rooted is the acronym DD in the Debian community, I doubt it is a good idea to change it or even to get rid of it. True, but the proposal splits the current DD in two types, namely DDM and DNDM. No, it does not split (to be precise, it does not partition) the current DD class. rather then splitting adds a new class of people able to vote. Hence, I still don't by your argument. I admit that that wasn't the strongest point. The main reason is the part you didn't quote, though: On Thu, Oct 23, 2008 at 10:55:55PM +0200, Bas Wijnen wrote: It would be very nice to have a naming where DDM (or perhaps just DM) would still be DD, but I couldn't think of a scheme where that was possible while still showing the logic of the roles. Calling every member a developer just doesn't make sense. To be more clear, I am trying to accomplish: 1 - a naming scheme which makes sense, instead of the current scheme, where more confusion is added with each new name. 2 - a scheme where DNDM and DDM are not normally separated, so when we talk about DDs, we aren't leaving an important group out. 3 - not too much confusion due to name changes. 1 and 2 have equal priority; 3 has lower priority, IMO. I agree with you that my proposal doesn't do well on that point. The reason I accept this, is that this confusion is not permanent; it will be gone once people are used to the new names. The confusion of 1 on the other hand will exist until the naming scheme is replaced. You're saying that 3 should have a higher priority (right?). In the short term, I can see that this avoids problems. But in the long term, ignoring the proposal, it leaves problem 1. And with the proposal, it makes problem 1 even bigger, and more importantly, it introduces problem 2. That is, with the naming Jörg proposed, DNDM and DDM don't have a common name, so when talking about all DDs, we're missing the DNDMs. As was remarked elsewhere, this will result in them being looked upon as second class. Since Jörg's proposal is exactly meant to show them that we value their contributions, I think it is actually very important to do this Right. And that means A - that they aren't called developers. B - that they are full members, and that their title (DM) is used when talking about them. Calling every member a DD (as it is now) would need a new meaning for DD, because as I wrote, not every member is a developer. If you have a suggestion for a better name, I'm open for suggestions. I couldn't come up with anything better than member, because that's what it's really about. By the way, do you agree to renaming DM/DC/DME to more logical names, or do you dislike that as well? My main problem with the naming is with DM/DME. Do you share my concern about this? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Re: Developer Status
On Thursday 2008-10-23, Pierre Habouzit wrote: I hate in Ganneff proposal the fact that it just standardize the 6 months delay to be a DD. It's acknowledging that we suck, and trying nothing to fix the problem. It's unacceptable to me. I read that as requiring a long-term involvement in Debian before getting vote rights (i.e. 6 months of Debian work, not 6 months of waiting). Which I think is a perfectly sensible requirement. -- Cheers, Cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Re: Developer Status
On Friday 2008-10-24, Bas Wijnen wrote: Calling every member a DD (as it is now) would need a new meaning for DD, because as I wrote, not every member is a developer. If you have a suggestion for a better name, I'm open for suggestions. I couldn't come up with anything better than member, because that's what it's really about. 5 minutes of thought on possible backronyms gives: DD = Distinguished Debianite? Dashing Debianite? Debian Do-ocrat? I don't think coming up with a cool sounding backronym would be an impossible problem to solve (and hey, ultimate bikeshedding event, getting suggestions is not likely to be a problem :) -- Cheers, Cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Re: Developer Status
Hi Ganeff, Just a note to register my endorsement that I believe you have great ideas here. Cheers, Andrew McMillan On Wed, 2008-10-22 at 23:33 +0200, Joerg Jaspert wrote: Developer Status Summary of this post Discussions in the past have made it clear that the current definition of Debian Developer (AKA someone who is a member of the Debian project) should be modified and made more flexible. There have been attempts in the past to do something similar, notably Debian Maintainers (DM) [GR-DM], and to some extent debian-community.org [D-C], but these have only addressed parts of the whole issue. We plan to integrate DM more closely into the NM process/system while keeping the spirit of easing entry into Debian for newcomers. At the same time we add a separate track for less-technical contributors. If you are an existing Debian Developer or Debian Maintainer, don't be afraid, we are not going to take anything away from you. Currently becoming a Debian Developer means passing through all of the New Maintainer process. People that passed this get the @debian.org mail-forwarding, an account on all (developer-accessible) Debian machines, voting and upload rights. It is a process that requires work from prospective Developers, and depending on their available time and the effort put into it, it can take a bit of time. Some time ago a few Developers thus went and pushed forward the Debian Maintainer status. DM allows newcomers to upload their packages relatively early, without having to go through the full NM process. So far it has worked quite well for the people involved, but the way it was instantiated outside of most existing structures has always made other groups in Debian uncomfortable. The ftp-masters have to deal with the technical implementation that does not fit well with the rest of the archive, and the account and keyring managers would like to remain the authoritative source for who is in Debian. Debian is about developing a free operating system, but there's more in an operating system than just software and packages. If we want translators, documentation writers, artists, free software advocates, et al. to get endorsed by the project and feel proud for it, we need some way to acknowledge that. This is where our proposal comes in. Now let us describe the way the account status is meant to be handled in future. A new user can start out in two ways depending on their personal preference. The first is the non-technical way: Debian Contributor -- A DC is someone that has a strong relation with Debian through the work they are doing for/around Debian. Possible examples are translators and documentation writers. DC have to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions[DCDMQ] similar to the ones used in the current first PP step.[TEMPL] The second way is the technical one: Debian Maintainer - A DM has the same strong relation with Debian a DC has, but additionally wants to maintain a limited set of packages without the help of a sponsor. A DM has to pass the same checks a DC has and very few questions from the TS part[DCDMQ]. A (very) small TS basically, the most important TS questions for them. They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. In contrast to current DM this is based on source packages and allows uploads of new binary components, which have to pass NEW, too. While, strictly speaking, this increases the barrier to get DM compared to the current implementation of DM, we do not think it is an unreasonable or too high level. Anyone who is able to get a package put together in a lintian clean way will be able to get DM without much effort or time used. Those two classes are the initial set in which every NM will end up. After six months as DC or DM one might chose to become a Debian Member or Debian Developer. This - ensures that the interest in Debian isn't short-term. - enables them to learn more about the workings in Debian and generally helps them for the next step. - leaves everyone the option to stay DC or DM, if they do not want/need more rights. After the 6 months time in Debian Contributor/Maintainer are passed, applicants can apply to get Debian Developer status. There are now 2 different classes of DD status available, one with and one without upload rights. To not add confusion we selected to name them Debian member (no upload rights) and Debian Developer (upload rights). Both are project members, i.e. with voting and all other constitutional rights, the term classes
bureaucracy (Re: Developer Status)
Manoj Srivastava wrote: On Thu, Oct 23 2008, Giacomo A. Catenazzi wrote: Joerg nominated teams, not persons. My and the people involved should be read as and the number of teams involved. I don't think nominated is the correct term here. Joerg did not nominate the secretary for anything, as far as I can tell. ;-) You are right. First meaning of nominate: To mention or specify by name. In this case was roles not names. Thus I would better s/nominated/listed/. (I'm lucky to speak a Latin derived language: most of times my guesses are still correct, but maybe archaic) The number of teams increment the bureaucracy (changing the proposal, coordination), and doesn't fit the Debian structure (role [proposers] vs. hierarchical [proposal]). Huh? The people Joerg talked to were people who would be affected by the proposal. For example, the secretary was called in to comment since this proposal would require changes in the coting pmechnism, and I was invited to give feedback on how big a change that would be. Also, he watned to ask about the constitutionality of the proposal. I don't see how this solicitation of early feedback in any way adds to the bureaucratic angle. Could you write it in a simpler manner. I think I understand your use of solicitation, but Wikipedia writes (first sentence): In the United States, solicitation is a crime. I don't think you mean that crime. Not the plain solicitation, but the need to solicitate so many people. All these people are affected by the proposal, and I was predicting how these people will handle the proposal? how they will interact each other? How many policies will have from every groups? (e.g. names/loginname, expirations, checks,...) How to pass new contributor between teams? Who will care that applications are not forgot in some internal (thus bureaucratic) step? (Remember the problem with NM waiting account) We had problem with busy key people, this proposal will give further burden to such the key people. So probably they will nominate (delegate) powers to new people, possibly with new role (helper, assistant), with rules and bureaucracy. We will have problems with some people, so how to deal with such problem? The roles listed by Joerg need to agree how to handle such cases (sign, i.e. bureaucracy), hoping they are not to much busy or temporary MIA. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joerg Jaspert wrote: Developer Status I start loving more this proposal. Debian is about developing a free operating system, but there's more in an operating system than just software and packages. If we want translators, documentation writers, artists, free software advocates, et al. to get endorsed by the project and feel proud for it, we need some way to acknowledge that. This is where our proposal comes in. Debian is mainly software and package, so a full (voting) member should have some knowledge to our package system. I have some fear about free software advocates. We use we are technical people to downgrade flames. In facts we are technical people. I want more technology and less politics in Debian. Let other organizations to do the most advocating and political discussion. I don't want that we do task of EFF, and I don't hope that OSI will not do distributions. Nobody forbid us to be member of other organizations. I think this is a major point to improve Debian: let give Debian a small and more definite scope, and let do the other works in upstream and/or activists organization. Second point. I don't like changes only to acknowledge other people. Personally I trust some Debian contributors not because they are DD, but because they are visible contributors (in facts time to time I see that some of them was not DD). We want these changes to acknowledge some contributors, or to speed up they contributions of such people? I think that with such proposal we will not increase contributors, but a better working structure for these people. A new user can start out in two ways depending on their personal preference. The first is the non-technical way: Debian Contributor -- A DC is someone that has a strong relation with Debian through the work they are doing for/around Debian. Possible examples are translators and documentation writers. DC have to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions[DCDMQ] similar to the ones used in the current first PP step.[TEMPL] I think this is the step one for all contributors: having a know key would simplify also sponsoring and mentoring (which is the first step also for DM). Instead of a set of questions, I prefer some advocates to relevant people (e.g. from i18n expert, from sponsoree, from team,...) The second way is the technical one: Debian Maintainer - They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. In contrast to current DM this is based on source packages and allows uploads of new binary components, which have to pass NEW, too. I agree in general, but I think the power should be defined by ftp-master (type of uploads, NEW uploads, delayed queue, ...). The NMC will give a packager license and eventually further checks at request of ftp-master for other packagers. After the 6 months time in Debian Contributor/Maintainer are passed, applicants can apply to get Debian Developer status. There are now 2 different classes of DD status available, one with and one without upload rights. To not add confusion we selected to name them Debian member (no upload rights) and Debian Developer (upload rights). Both are project members, i.e. with voting and all other constitutional rights, the term classes does not indicate any kind of first or second level membership. Debian Member - A DME is someone that previously had DC or DM for at least 6 months but additionally want to have voting rights or needs a login on a debian.org machine for their work. A DME can nominate themself as DPL, can be delegated rights from the DPL and can start any GR, basically do everything our foundation documents allow project members to do. DME are not able to freely upload any package, but DME can have the same upload rights a DM can have, ie. own packages, if they follow(ed) the DM rules for this. Following our Constitution §8.1.2, DAM declares that Debian Members are to be treated as Developers who do not maintain packages wherever the term Developer is used in one of our documents. I think we don't need DME. I requires a minimum of packaging skills (with debhelper it could be very easy, and IMO bugs handling skills are necessary). We can do simplified tests: at this level we trust that a person which is not comfortable with programming will not do complex uploads. Why do we want to forbid a trusted person to do trivial uploads, binNMU and helping other DD (e.g. without temporary a working key) to upload packages? I thyink that voting people must be trusted and responsible, so no need to distinguish. We could expel the DD which do frequently completely wrongs uploads. contributor.debian.org mail --- We are considering to implement
Re: Developer Status
Giacomo A. Catenazzi wrote: Joerg Jaspert wrote: Developer Status I start loving more this proposal. Debian is about developing a free operating system, but there's more in an operating system than just software and packages. If we want translators, documentation writers, artists, free software advocates, et al. to get endorsed by the project and feel proud for it, we need some way to acknowledge that. This is where our proposal comes in. Debian is mainly software and package, so a full (voting) member should have some knowledge to our package system. Documentation, Translation, User support, Events and stuff have nothing to do with packaging. Debian community members mainly being active in these areas should be granted voting privileges as well. They wouldn't need package upload privileges, though. To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joey Schulze wrote: Giacomo A. Catenazzi wrote: Joerg Jaspert wrote: Developer Status I start loving more this proposal. Debian is about developing a free operating system, but there's more in an operating system than just software and packages. If we want translators, documentation writers, artists, free software advocates, et al. to get endorsed by the project and feel proud for it, we need some way to acknowledge that. This is where our proposal comes in. Debian is mainly software and package, so a full (voting) member should have some knowledge to our package system. Documentation, Translation, User support, Events and stuff have nothing to do with packaging. Debian community members mainly being active in these areas should be granted voting privileges as well. They wouldn't need package upload privileges, though. To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. I think most of our experienced users will have enough capabilities for a simple test, and anyway, I would not put him in an other category. Let giving him other tests, but let him to be a normal Debian Developer. who is not interested on upload packages. No need for new categories. Voting people should be trusting people, so without constitutional limits. He would decide to have restricted rights. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 10:32:34AM +0200, Josselin Mouette wrote: Le jeudi 23 octobre 2008 à 10:20 +0200, Joerg Jaspert a écrit : It is - a start of the discussion, using d-d-a on purpose to reach everyone in something that more or less touches all of us, and - a new policy to get implemented some time soon, with whatever sensible changes might come out of this thread We have a process for this kind of changes, it’s call DEPs. Why didn’t you start this discussion as a DEP instead? Because Debian is not Python? AFAIK there's no *requirement* to make proposals in any particular way. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Le vendredi 24 octobre 2008 à 15:17 +0200, Wouter Verhelst a écrit : On Thu, Oct 23, 2008 at 10:32:34AM +0200, Josselin Mouette wrote: We have a process for this kind of changes, it’s call DEPs. Why didn’t you start this discussion as a DEP instead? Because Debian is not Python? AFAIK there's no *requirement* to make proposals in any particular way. I thought the project was mature enough to use appropriate processes even when they are not written in stone, but if you really want to, I can write a constitutional amendment formalizing DEPs. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Developer Status
Giacomo A. Catenazzi wrote: To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. Why should he do a packaging test? Why should translators of the website? They do not intend to do packaging. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 08:33:12PM +0200, Aurelien Jarno wrote: How long has it been discussed? From: Joerg Jaspert [EMAIL PROTECTED] Subject: Developer status Date: Thu, 09 Oct 2008 22:50:36 +0200 -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joey Schulze wrote: Giacomo A. Catenazzi wrote: To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. Why should he do a packaging test? Why should translators of the website? They do not intend to do packaging. It should be not mandatory, but I think it is interesting to him to know the very basic packaging. Managing web site translation I think it means also using some scripts, so very basic of debhelper and packaging is not so complicated. I'm DD and I passed the following tests (in 2000 or 2001): ID, philosophy of Debian, legal (license check), packaging, handling bts, basic English, etc. The tests was supposed to see if the person know various aspects of Debian, not only to see if he can pack. Do you think a Debian voter would not be interested on other areas? Not to be an expert, but a very simple tests could be useful, and not the test for usual packers. Eventually we can make it DD without test, and up to ftp-master to see if upload rights should be granted. We should trust our voters! Without distinction of uploaders and others. In future maybe he could do simple language packing or NMU upload of new translations. Let decide the NM about what kind of test would be necessary for various interest. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Fri, Oct 24, 2008 at 03:25:57PM +0200, Josselin Mouette wrote: Le vendredi 24 octobre 2008 à 15:17 +0200, Wouter Verhelst a écrit : On Thu, Oct 23, 2008 at 10:32:34AM +0200, Josselin Mouette wrote: We have a process for this kind of changes, it’s call DEPs. Why didn’t you start this discussion as a DEP instead? Because Debian is not Python? AFAIK there's no *requirement* to make proposals in any particular way. I thought the project was mature enough to use appropriate processes even when they are not written in stone, but if you really want to, I can write a constitutional amendment formalizing DEPs. If you insist. Note that I'll vote against it -- I've never liked procedures whose sole purpose is to change procedures. You can be unhappy about this particular proposal, but that has nothing to do with whether or not it is a DEP. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Fri, Oct 24, 2008 at 04:30:31PM +0200, Giacomo A. Catenazzi wrote: Joey Schulze wrote: Giacomo A. Catenazzi wrote: To cite an extreme example, Ingo Juergensman doesn't do packaging nor anything of the above. Nevertheless, he's an active member of the Debian community for many years (even despite severe problems) by supporting the m68k port with hosts and maintenance. He should be able to vote on general Debian issues such as the project leader. This is an interesting point. Do you thing Ingo Juergensman could not pass a simple test on packaging or on BTS? He could anyway ask ftp-master to have upload right removed. Why should he do a packaging test? Why should translators of the website? They do not intend to do packaging. It should be not mandatory, but I think it is interesting to him to know the very basic packaging. Regardless, at the time, Ingo felt that there was no way for him to be able to get through NM without knowing stuff about packaging. That is not a good thing (I've known Ingo for quite some time now, and he's a very knowledgeable person, on Debian as a whole and the m68k port specifically) -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Fri,24.Oct.08, 14:31:42, Giacomo A. Catenazzi wrote: contributor.debian.org mail --- We are considering to implement an @contributor.debian.org mail forwarding setup which would be open for DC/DM too. Such addresses would continue to be valid even after a person becomes a DD/DME. If sufficient support for the idea is found then this will probably be implemented once the new debian.org mail setup is in place. I don't like contributor. we need a short term. +1 Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Developer Status
Andrei Popescu wrote: On Fri,24.Oct.08, 14:31:42, Giacomo A. Catenazzi wrote: contributor.debian.org mail --- We are considering to implement an @contributor.debian.org mail forwarding setup which would be open for DC/DM too. Such addresses would continue to be valid even after a person becomes a DD/DME. If sufficient support for the idea is found then this will probably be implemented once the new debian.org mail setup is in place. I don't like contributor. we need a short term. +1 Regards, Andrei Why not @people.debian.org ? It represents pretty good what thoses eventual contributors would: the _people_ who make Debian. Or @not-yet-a-dd.debian.org, but it seems someway agressive ;) Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 07:36:02PM +0200, Stefano Zacchiroli wrote: On Thu, Oct 23, 2008 at 01:20:32PM +0100, Mark Brown wrote: Non-packaging contributors were always supported in the current NM process - this issue was discussed at the time the process was created Sorry, but that's not support, or at least not *complete* support. I think what you mean to say is... Still, I won't be at ease with upload rights to the archive given by default to non-technical contributors. The status quo did not support inhibiting upload rights to voting developers (OK, it could have been enforced via dak, but that's not an answer). ...that you feel that such people would get too many rights, which isn't the same thing at all. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Steve Langasek wrote: On Thu, Oct 23, 2008 at 01:43:31PM -0500, Raphael Geissert wrote: Luk Claes wrote: Raphael Geissert wrote: What about getting every maintainer's key in a keyring and LDAP? it would finally allow for a better management system to take place The problem is that not all maintainers have keys in the first place. Which in theory is not good. Even packages that later get uploaded by a DD should be signed. That shouldn't be relevant if the sponsor is doing their job of reviewing the package before upload. IMHO it *is* relevant, as it helps enforce/teach the reasons why packages are signed when uploaded to the archive. I've even seen some people continuously creating new keys because they either forget the key password, or they accidentally deleted the secret key, or because of similar reasons. IMHO knowing they why of signed files/packages is one of the most important points, together with DFSG, SC, policy, and such. PS. I've seen people not knowing that even uploads by buildds are signed. Although it is not something unforgivable it clearly demonstrates that there are some basic points not being covered properly; specially in NM. Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Hi Luk, 2008/10/23 Luk Claes [EMAIL PROTECTED]: Raphael Geissert wrote: Right, but do the members of the NMC cover the wide variety of programming languages? or what kind of review are they going to do? just packaging stuff? if it is just the latter it would be much easier and faster to send a RFC to -mentors and let people scream out loud. And please note that I said QA side, with which I didn't mean to refer to the QA group, but to a variety of people who know what to look at and how to do it; not a random AM who happens to have already completed doing a review process successfully (which actually doesn't guarantee that the AM is competent enough, as the usual NM process consists on sending the templates and later reviewing the responses). First of all I would like to apologise as it was not my intention to * offend/criticise anyone's work, * mean that NM is all about questions, as it of course isn't. I believe that impression was caused by my oversimplification of the NM process. You're very wrong here. The AM's job is to review if someone would be capable of being a good Debian Developer. Reviewing responses to the templates is *not* the main job. Have the prospective DD learn things; get the prospective DD think and search before answering; and reviewing actual tasks and skills by reviewing the prospective DD's packages next to possible other 'tasks' takes most of the time. It's not at all about a questionaire where you only have to tick the right answers because that would defeat the spirit of the process. For many applicants it takes a long time because they think it's just a questionaire... Getting a little bit back on my point: what I wanted to mean with my explanation of QA side is that: * nobody is perfect, * not always packages are checked as rigorous as they, at times, are at -mentors So, my proposal is more or less like this: 1.- Keep everything in public MLs 2.- Assign a member of the NMC to the case[1] who will of course be willing to work on it 3.- Publicly request[2] people to review the package[3], although the NMC member will also do it on her own. 4.- Every review should be handled[4] by the NMC member and a decision be made (also refer to [1]). And as an extra note: any NMC member should be able to take over the request at any time in cases such as when the review/process is not objective (i.e. there are personal feelings). [1] This member will take care of the case/request and will write a brief, but explanatory, report when making a decision. [2] Teams, co-maintainers, etc should probably be CCed. [3] No review should be disregarded, no matter whether it comes from a Dsomething or from a Dnothing as any input should be considered valuable. [4] Any extra investigation needed originated by a contributed review should be made before any decision is made. Does that sound better? comments? suggestions? positive criticism? Although I'm not still very convinced I at least want to propose something that, if approved, would make me happier than the originally-proposed process. Cheers Luk Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net Quentin Crisp - If at first you don't succeed, failure may be your style. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bureaucracy (Re: Developer Status)
On Fri, Oct 24 2008, Giacomo A. Catenazzi wrote: Manoj Srivastava wrote: On Thu, Oct 23 2008, Giacomo A. Catenazzi wrote: The number of teams increment the bureaucracy (changing the proposal, coordination), and doesn't fit the Debian structure (role [proposers] vs. hierarchical [proposal]). Huh? The people Joerg talked to were people who would be affected by the proposal. For example, the secretary was called in to comment since this proposal would require changes in the coting pmechnism, and I was invited to give feedback on how big a change that would be. Also, he watned to ask about the constitutionality of the proposal. I don't see how this solicitation of early feedback in any way adds to the bureaucratic angle. Could you write it in a simpler manner. I think I understand your use of solicitation, but Wikipedia writes (first sentence): In the United States, solicitation is a crime. I don't think you mean that crime. I do not think that asking for early feedback to make a proposal better has any bearing on how bureaucratic the actual process being proposed is. maanoj Nothing is but what is not. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
pe, 2008-10-24 kello 16:56 +0200, Wouter Verhelst kirjoitti: If you insist. Note that I'll vote against it -- I've never liked procedures whose sole purpose is to change procedures. For what it's worth, as one of the three people who suggested DEP in the first place, I would be unhappy to see it made mandatory, and would vote against a GR suggesting it. As far as I care, DEP should be a tool, for those who wish to use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On 22/10/08 at 22:51 +, Clint Adams wrote: On Thu, Oct 23, 2008 at 12:10:29AM +0200, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. I am disappointed in all of these people. He wrote discussed, this doesn't mean that all of them agreed fully on this proposal^Hdecision. It would be interesting to have the point of view of each of those groups. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 08:59:54AM +0200, Lucas Nussbaum wrote: Debian is about developing a free operating system, but there's more in an operating system than just software and packages. If we want translators, documentation writers, artists, free software advocates, et al. to get endorsed by the project and feel proud for it, we need some way to acknowledge that. This is where our proposal comes in. Could you point to some non-programmers contributors that would be interested into that process? Have you talked to them about it? *raisesHand* When I applied as NM back then[TM] I expressed explicitly that I doesn't maintain any packages nor wanting to maintain a package in the future. Because there was no procedure how to deal with that situation during NM, I wasn't applied an AM for over a whole year. Therefore I withdraw my application after that year. Now I could re-apply, in theory... -- Ciao...// Fon: 0381-2744150 Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
First of all, a suggestion from me. I would like to change names a bit, so there are names for some groups as well. Here's my proposal: - Debian Developing Contributor (DDC) = what's currently called DM - Debian Non-Developing Contributor (DNDC) = what's called DC in the proposal. - Debian Contributor (DC) = DDC + DNDC. - Debian Developing Member (DDM) = what's called DD in the proposal. - Debian Non-Developing Member (DNDM) = what's called DME in the proposal. - Debian Member (DM) = DDM + DNDM. - Debian Key-owner (DK) = DM + DC I'll be using these abreviations below, and to limit confusion I changed quotes so they use it as well. When really talking about current things, I use them unabreviated. I suggest others to do the same. (This is my view of Debian-style consensus-building: just do things how you consider them right, and hope others will follow your lead.) To avoid confusion about DM (which has a meaning in both naming schemes, which is not the same), I recommend everyone to explicitly say which naming scheme they're using. If you don't mention this, I'll assume you'll be using the same scheme as the post you reply to (if any). On Wed, Oct 22, 2008 at 10:23:24PM -0200, Margarita Manterola wrote: I'm quite disappointed on this being informed as a done thing, without the project as a whole being asked for an opinion. The mail talks about a proposal. I took that as something which is open for discussion. On Wed, Oct 22, 2008 at 11:29:53PM -0300, Felipe Sateler wrote: Debian Contributor -- Basically, they need to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions similar to the ones used in the current first PP step, to keep doing the same thing they have been doing all this time. No. Current Debian Maintainers also need an ID check, agree to SC/DFSG/DMUP and be advocated. The only thing that is added (and that was made clear by Joerg), is that they need to answer a very limited set of questions. Also, I don't think this is supposed to change anything to the sponsoring system, so people who use sponsors can continue to do so as well, without the questions (or the other checks). I do have one question: the current Debian Maintainer process has some features which the New Maintainer process does not have. I'm mostly thinking of the fact that advocation mails must include reasons why the prospective DC is a good candidate. Another post mentioned the yearly ping. I would like to keep those things (and thus add them to the DC process). So this basically requires Debian Maintainers to do the (somewhat reduced) PP and TS questions, and I don't see the real reason for this. The idea behind Debian Maintainers is to maintain a package one knows how to maintain. Those people are getting upload rights to the archive. Don't you think it's reasonable that the project wants people to show that they won't mess things up before giving such a priviledge to them? Becoming a Debian Maintainer is supposed to be a light-weight version of the New Maintainer process. It's not a I'll skip the New Maintainer process entirely-version. The only reason I can see here is that DDs are not being trusted in their advocations, which is a far worse problem that won't get solved by this. We have over 1000 members. That's way too much to use the if you have 1 invitation, you're in-system. Looking at the recent flamewar, I'm pretty sure almost every DM has at least one other DM whose advocation they don't trust. So I don't think one advocation is not enough is a problem at all. It's just a result of having many members. Don't forget that this is a quick thing. People who don't care enough to answer some quick questions (or show in some other way that they can handle the responsibility) aren't interested enough to get the priveledge we're talking about, IMO. - ensures that the interest in Debian isn't short-term. Why do people keep thinking this is a good thing? If people only have short-term interest, that's not a bad thing in itself. But in this case we're talking about giving them long-term priviledges (upload any package; vote; become DPL, that sort of thing). We want members of our project to have a long-term interest, don't you agree? - enables them to learn more about the workings in Debian and generally helps them for the next step. They should be doing this on their own, and not force an arbitrary limit on them. What if they did this _before_ applying for DC/DM status? In the proposal, there is no help during these 6 months. So basically, if people want to do this on their own, the project will ask them to say so before doing that (in the proposal). Saying so means applying for DC status. Applying for DM is not possible before those 6 months are over. You seem to want to rush total outsiders into the most priviledged positions of the project. Why would that be a good thing? What is
Re: Developer Status
Joerg Jaspert wrote: Developer Status This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. Reading the proposal and the people involved, I think the proposal is to complex and bureaucratic and it doesn't fit to the Debian structure. As example of Debian structure, how to you will answer to: Why do you have the power to do this? I hope you don't answer with I've the supercow power, but you will answer with roles. So why don't move the proposal with roles instead of the naerly concentric power structure? So I propose: - Debian contributor as in your proposal (ID check, agree to the social contract, ..) and then we define roles: - Esperanto debconf translator - Chinese website uploader/maintainer - uploader/maintainer to package X - uploader/maintainer of package of team Y - testing security (IIRC the search also for non DD members) - DPL - etc. Every team or team master choose who as power and what kind of power. DD would become a label of people with debian constitutional rights (vote etc) and some standard powers, and I think we could eventually restrict the rights (i.e. to have a non packager DD, or for a sabbatical DD) ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
while keeping the spirit of easing entry into Debian for newcomers. At the same time we add a separate track for less-technical contributors. Is it a start of a discussion? A new policy? Both. :) It is - a start of the discussion, using d-d-a on purpose to reach everyone in something that more or less touches all of us, and - a new policy to get implemented some time soon, with whatever sensible changes might come out of this thread On 11547 March 1977, Margarita Manterola wrote: I have been wanting this for a long time, I totally agree with what's in the mail, and I'm really happy that this has been thought about and written about, however, I'm quite disappointed on this being informed as a done thing, without the project as a whole being asked for an opinion. None of this is implemented yet, all of this requires work in multiple places (changing nm.d.o, changing dak are two examples) I know that DAM's and Front Desk and the like and in charge of accounts, but creating 2 new categories for people to participate in is quite a change, and I think the whole project should be involved in such a decision, as we were involved in the decision regarding Debian Maintainers. While this is a long text (to properly explain the thing), it doesn't change as much as people seem to think. On 11547 March 1977, Raphael Geissert wrote: Debian Maintainer - They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. I believe everything is ok up to this point: why does the NMC need to review the packages? I mean: has there been any problem with the current way DMs are allowed to upload? can't the project trust in DDs as to what packages can DMs upload? We do trust DDs - everyone can become a member of the NM Committee, you just have to do a little AM work. By adding this extra step it makes the process more complex and turns something useful into something more like a process with lots of paper-work: It would require to: 1. first: find a sponsor to upload a package, 2. then become trusted, 3. get advocated, 4. ID check (btw, will it still require keys to be signed by DDs? or are DCs or Dwhatever more than enough?), 5. TS check, 6. SOC agreement, 7. NMC approval, 8. keyring-maints stuff, 9. NMC approval of packages. Umm, well: 1. no change to now 2. no change to now 3. no change to now, only the destination of the approval mail for DMs changes 4. Yes, this is a change, you need a DD or DME to sign your key. One might adjust it so that DC/DM can sign for other DC/DM (or maybe make that 2 of them sign one). 5. I hope you read the footnote? It can easily be adjusted to fit whatever the current situation is. Which means that they can make it a full TS plus must fix 1000 RC bugs - or just nothing. 6. no change to now 7. is DM-Team approval now 8. is DM-Team keyring foo stuff now 9. this can easily be in 7., and only get invoked if you want to add more packages to your list later [DCDMQ] The intention is that the NM-Committee will select the actual set of questions used, not this mail. It can easily be adjusted to fit whatever the current situation may want to have. For DM we imagine it would be a very limited TS set, like making sure someone can deal with the BTS and knows the basic tools (lintian, dput/dupload, debsign). It is not meant as a full (first part) of NM and lots of boring tasks before one get DM, but as a basic check for a minimum knowledge. In contrast to current DM this is based on source packages and allows uploads of new binary components, which have to pass NEW, too. That's great, but what is it going to happen to cases like #502943? That is an interesting corner case. (Note that for todays code I'm happy to accept patches/git trees to merge to fix any of such errors). Im currently not 100% sure what the best is in this case. On 11547 March 1977, Felipe Sateler wrote: Now let us describe the way the account status is meant to be handled in future. This mail has mixed future and present tense. Have these changes already been implemented, or are planned? Those changes do require some work in multiple places. So its not implemented yet, no. While, strictly speaking, this increases the barrier to get DM compared to the current implementation of DM, we do not think it is an unreasonable or too high level. Anyone who is able to get a package put together in a lintian clean way will be able to get DM without much effort or time used. So this basically requires DMs to do the (somewhat reduced) PP and TS questions, and I don't see the real reason for this. The idea behind DMs is to maintain a package one knows how to maintain. The only reason I can see here is that DDs are
Forget classes, think privileges (was: Developer Status)
also sprach Joerg Jaspert [EMAIL PROTECTED] [2008.10.22.2333 +0200]: Now let us describe the way the account status is meant to be handled in future. Finally! http://lists.debian.org/debian-project/2005/02/msg00079.html It's the latest message I could find. I am sure I have been harping on about this before. One thing that occurs to me reading about what Clint has to say[0] is that we have a set of privileges, such as voting and uploading and the access to the various different machines, one punishment (debian-private access), and Jörg wants to map different combinations of those to classes. 0. http://xana.scru.org/xana2/ranticore/debknights/ Why don't we just take each and every of those privileges and define criteria for how to obtain the privilege, and then simply give people privileges according to what they need, rather than having a defined set of rigid classes? Obviously, one could still group privileges (e.g. to be able to vote, you have to endure debian-private). And yes, I agree that this ought to be a GR or at least that Jörg's email should not have been of the this is what we'll most likely do nature, but rather in the this is what I've been thinking about and would like to propose for discussion department. Cheers, -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems once ... in the wilds of afghanistan, i lost my corkscrew, and we were forced to live on nothing but food and water for days. -- w. c. fields, my little chickadee digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Developer Status
Le jeudi 23 octobre 2008 à 10:20 +0200, Joerg Jaspert a écrit : It is - a start of the discussion, using d-d-a on purpose to reach everyone in something that more or less touches all of us, and - a new policy to get implemented some time soon, with whatever sensible changes might come out of this thread We have a process for this kind of changes, it’s call DEPs. Why didn’t you start this discussion as a DEP instead? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Developer Status
Le Thu, Oct 23, 2008 at 10:20:55AM +0200, Joerg Jaspert a écrit : - a new policy to get implemented some time soon, with whatever sensible changes might come out of this thread Joerg, this means that if we want to have a word to say about how the Debian project defines its members, we have to participate to this discussion *now*, or block it. There is not even a timeframe for us to know when it is too late to influence your decisions, that for the moment seem completely unilateral: I have seen position acronyms, (DAM, DPL,…), put for the person names, there is only yours. This is a situation that will not help to get the best out of the discussion. Won't you accept to postpone it to after the release? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 07:47:10AM +, Josselin Mouette wrote: Le jeudi 23 octobre 2008 à 08:59 +0200, Lucas Nussbaum a écrit : Debian Contributor -- Debian Maintainer - Debian Member - Debian Developer I really liked the fact that it was possible to explain Debian's different developers status in 30 seconds. Couldn't we find a way to adapt the current architecture to fit in the additional statuses? This is the thing that makes me the most uneasy with the decision (apart from the way it was done). We need less complexity and bureaucracy, not more. I'd put it even more bluntly. The current problem is that NM is too slow, too sluggish, too boring. Being a DD requires a motivation that I wouldn't even dare to ask from the best employees in my company, and god knows I'm an elitist when it comes to code quality and technical interest. No, instead of attacking the big fat problem that being a DD is not a single phone call with Elmo anymore, we tackle the issue by adding even more sub-roles, so that people that get lost en route, have cookies along the path. “ - Come to the dark side - No - We have cookies ! - \o/ ” If I recall right, Jörg was really against DM at the time. I thought it was because of that, I see now that it's because the project wasn't his. Debian has always had a flat hierarchy, with a few delegates for key roles, infrastructure handling and stuff like that, where it's not really practical to have every DD have the position (1000 DSA isn't really a good thing, I speak from experience). So when the *constitution* gives him the right to do what he just did (yeah, sadly he can and we have to be 2:1 to overrule that yeah), it's completely against the nature of Debian, and the spirit of the constitution. I'm blatantly disappointed in both the form and the ground of this edict. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpig0dPSZ53e.pgp Description: PGP signature
Re: Developer Status
Le jeudi 23 octobre 2008 à 10:37 +0200, Pierre Habouzit a écrit : So when the *constitution* gives him the right to do what he just did (yeah, sadly he can and we have to be 2:1 to overrule that yeah), it's completely against the nature of Debian, and the spirit of the constitution. Only overriding the TC needs a 2:1 majority. For delegate decisions, that’s only a standard majority. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Developer Status
On Thu, Oct 23, 2008 at 08:48:51AM +, Josselin Mouette wrote: Le jeudi 23 octobre 2008 à 10:37 +0200, Pierre Habouzit a écrit : So when the *constitution* gives him the right to do what he just did (yeah, sadly he can and we have to be 2:1 to overrule that yeah), it's completely against the nature of Debian, and the spirit of the constitution. Only overriding the TC needs a 2:1 majority. For delegate decisions, that’s only a standard majority. Yeah, I've been corrected already, I don't know why I thought it was so. But still, technically we have to override it, since he's a delegate, and that was my point :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp2hPrxr67CB.pgp Description: PGP signature
Re: Developer Status
On Wed, Oct 22, 2008 at 10:10:29PM +, Joerg Jaspert wrote: Developer Status And I should probably have written this inside the mail itself, but the most obvious things are those you forget. This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. Could those poeple please comment on their motivations and why they think this proposal is a good idea please ? All of them CC-ed. Also, why hasn't the nm-committee involved, and the DEP process completely ignored ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgptpXGfmouzr.pgp Description: PGP signature
Re: Developer Status
IANADD. On Thu, Oct 23, 2008 at 10:37:23AM +0200, Pierre Habouzit wrote: I'd put it even more bluntly. The current problem is that NM is too slow, too sluggish, too boring. Being a DD requires a motivation that I wouldn't even dare to ask from the best employees in my company, and god knows I'm an elitist when it comes to code quality and technical interest. You might be right. No, instead of attacking the big fat problem that being a DD is not a single phone call with Elmo anymore, we tackle the issue by adding even more sub-roles, so that people that get lost en route, have cookies along the path. I don't think so. We now have the DDs and we have some sort of DMs who are allowed to do some stuff once only DDs were allowed to, and they can only do that when following different rules. Now, the proposal tries to put this DM status in the NM process. You can become a DM and have some DM rights (as it is now) and then you can become a DD more easily because you're already some steps forward to it. But the more important part is IMO that the proposal *finally* respects the non-packaging contributors (and there are many, I guess). For them we can now have similar steps which in the end means DD rights without the need of learning technical stuff they won't ever use. This is not adding sub-roles on the way to become a DD. We already have the DM status which means nearly nothing on your way to become a DD -- you have to go through the entire NM process, too. The proposal tries to stop that by putting the DM status in the NM process. The new sub-roles for contributors don't really affect becoming a DD since the prospective DD can go either way but he's never got to go both of them. This is adding possibilities for non-technical contributors to get the very same rights they should have (IMO). If I recall right, Jörg was really against DM at the time. I thought it was because of that, I see now that it's because the project wasn't his. [...] I'm blatantly disappointed in both the form and the ground of this edict. And I'm very disappointed in project members who always feel the need to insult (see the DFSG thread on d-devel or this one). This is about the project and I'd appreciate if DDs could move their personal fights to d-private or private mails. MAYBE Joerg was against DM back then, and MAYBE he now sees that the DM status turns out to work much better than he could ever imagine, and MAYBE he learned from it and tries to give it another shot to move the DM status in a better position in the project. Is this impossible? Hauke -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joerg Jaspert [EMAIL PROTECTED] wrote: Hi, I'm pretty unhappy with the very non-Debian way you have when it comes to making decisions and announcing them. If you are an existing Debian Developer or Debian Maintainer, don't be afraid, we are not going to take anything away from you. And also that feeling you seem to have that you are above the lot of mere mortals that we, DDs without delegations, are. the way it was instantiated outside of most existing structures has always made other groups in Debian uncomfortable. The ftp-masters Pretty much the only thing in your proposal I agree with is the bit about getting DM under proper controls. Now about the new status you are proposing, my general feeling is: more bureaucracy \o/ What you are proposing is way too complicated for the outside world to understand. I think adding a Debian Contributor status (no upload, no vote) with labels (translator, writer, ...) is a simple solution that fits the current issue pretty well. On the contrary, what you are proposing seems like solutions looking for problems to me. Now on to specifics: Debian Maintainer - A DM has to pass the same checks a DC has and very few questions from the TS part[DCDMQ]. A (very) small TS basically, the most important TS questions for them. I'm afraid you're going to need more than very few questions from TS. I think it's important that DMs know their stuff, for we have quite some crappy packages in the archive already and we don't really need more of them. They don't have to answer the more painful questions of the TS template (amazing what AMs can come up with, really), but very few seems like not enough to me. unreasonable or too high level. Anyone who is able to get a package put together in a lintian clean way will be able to get DM without much effort or time used. And that I totally disagree with. Being lintian-clean doesn't tell much about the quality of the package, and tells exactly nothing about the quality of the packager. I think we've had some examples of clueless DMs and even clueless new DDs in recent times (proving that even a full TS might not be enough). Do you want more of that, or less of that? I like the idea of progressing from DM to DD during NM, as it provides some kind of an observation period. As applicants are required to have some packages already when they apply, they could be granted DM after the basic checks, then complete NM and start an observation period as DM. To me, that's giving them full responsibility for their packages early on so we can see how they handle them on their own. Debian Member - A DME can nominate themself as DPL, can be delegated rights from the DPL and can start any GR, basically do everything our foundation documents allow project members to do. I have a problem with non-technical persons voting on technical issues, or issues having technical implications for the developer body. I have even more of a problem with non-technical persons leading a technical project. I am against this part of your proposal. Voting rights should be coupled with proper understanding of the Project at large, including the technical stuff, which is, after all, the base of this Project. This whole status is useless. If you want to vote, go to DD status. You'll get upload rights too, that doesn't mean you have to make use of them. I expect going to DD status to be something doable for any contributor after a period of time. Changes to the DM Keyring - Keyring management will be moved to the control of keyring-maint. The NM committee will decide who will be added or removed, similiar to the way keyring-maint and DAM currently work together. No matter what happens with everything else in your mail, go forward with that. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Forget classes, think privileges (was: Developer Status)
On Thu Oct 23 10:25, martin f krafft wrote: Why don't we just take each and every of those privileges and define criteria for how to obtain the privilege, and then simply give people privileges according to what they need, rather than having a defined set of rigid classes? Obviously, one could still group privileges (e.g. to be able to vote, you have to endure debian-private). This is what I was trying to propose last year[0,1] Matt 0. http://wiki.debian.org/Projects/AltReformedMembershipProcess 1. http://lists.debian.org/debian-newmaint/2007/12/msg00013.html -- Matthew Johnson signature.asc Description: Digital signature
Re: Developer Status
On Thursday 2008-10-23, Julien BLACHE wrote: Now about the new status you are proposing, my general feeling is: more bureaucracy \o/ What you are proposing is way too complicated for the outside world to understand. It's less bureaucracy for a non-packaging contributor: right now if a translator want's to be an official procect member he has to go through DM. I know I haven't bothered despite being actively involved with debian for 5+ years now (voting alone simply isn't worth the pain). It's less bureaucrcy for the project as you don't have to go through the whole NM rigmarole for each contributor -packager or no-, you can now limit it to just the relevant bits. As to the outside world, no need to go into nuances, you just go 'official project member' or not. If they wanna know more about a particular contributor just say that he is/is not involved with whatever area being asked about. I think adding a Debian Contributor status (no upload, no vote) with labels (translator, writer, ...) is a simple solution that fits the current issue pretty well. Why no vote? Long term contributors to the project should have a voice IMHO. Wether they are packagers/translators/doc writers/... really should have no bearing on it. I have a problem with non-technical persons voting on technical issues, or issues having technical implications for the developer body. I have even more of a problem with non-technical persons leading a technical project. First Actual techical issues are supposed to go the TC, not a GR (and looking at the list on http://www.debian.org/vote/ I have a hard time finding votes about purely technical issues) Second Debian isn't a pure technical project: packaging, translating, documentation, bug fixing, QA, ... are all things that are part of Debian, that have long-term contributors working on them. Each of those have their own specialised bits of knowledge, sometimes they overlap partly. I am against this part of your proposal. Voting rights should be coupled with proper understanding of the Project at large, including the technical stuff, which is, after all, the base of this Project. Does that also work the other way around with packagers having to understand translation/documentation/... stuff? Didn't think so. This whole status is useless. If you want to vote, go to DD status. You'll get upload rights too, that doesn't mean you have to make use of them. There's this principle in security called 'least access', it's why we don't log in as root for everyday use. Is there any particular reason you don't feel it should apply to something as potentially critical as upload rights? I expect going to DD status to be something doable for any contributor after a period of time. IIRC the last time this came up people could name 1 or 2 non-packagers who had ever bothered with NM - while it is theoretically possible for non-packagers to go through NM, quite obviously it's currently not worth the pain in the opinion of the vast majority of non-packagers. It doesn't stop us from contributing, but that doesn't mean we don't consider this a flaw in the process. -- Cheers, Cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Re: Developer Status
On Thu, Oct 23, 2008 at 12:03:13PM +0200, Gerfried Fuchs wrote: * Bas Wijnen [EMAIL PROTECTED] [2008-10-23 09:59:09 CEST]: First of all, a suggestion from me. I would like to change names a bit, so there are names for some groups as well. Here's my proposal: This is misleading because a DME is (also) an enhanced version of a DM, i.e. a DME is allowed to upload their own packages and can be a developing contributor. Not according to my reading of Joerg's proposal. People go from DC to DME. It is possible to also do DM, which means that person has two roles (DM and DME). Your distinction doesn't make it clear between DDs that can upload any package and those that can only upload a specific set of packages. In my terms, it would mean someone is DNDM and DDC at the same time. If it is expected that this would happen a lot, it can get a name by itself, but I thought I was using enough new names already. :-) Where Joerg's proposal (which I wholeheartly support) made the clear distinction between the full DD state that isn't limited in any sense and the limited upload allowance (even as limited as no package at all) you draw the line between no-upload right and any upload right, even limited. I don't think I changed anything in the roles, I only changed the names: DC = DNDC DM = DDC DME = DNDM DD = DDM And I add names for groups, so you don't have to say DC and DM or DME and DD. At least I did not intend to change the meaning, I am just worried that DC/DM/DME/DD are not very logical names, while the underlying structure is in fact two orthogonal elements: - Is this person a member? - D*C / D*M - Does this person do package development? - DND[CM] / DD[CM] And because that last question is often irrelevant, I propose to use standard names for people depending on their member-status only (DC/DM). Finally, I think it is useful to have a name for all people in Debian, which is why I added DK. I'm not sure if it's useful, and I'm not happy with the name, nor with the fact that it completely ignores sponsored maintainers. So perhaps that last one should be removed. It'd probably never be used anyway. :-) Personally I am not sure if your distinction is the better one, personally I prefer the one that Joerg proposed. I didn't intend to change his proposal; I'm happy with the roles he describes, I just want to give them different names. About the naming, I'm not sure if we really should change everything everywhere completely, I don't see the real gain, The gain is that we're finally done with the confusion about people in Debian. Currently we have new maintainers who are debian developers, and debian maintainers who are not. Now we'll add debian members, who are not debian developers, even though all developers are members of the project (but not considered debian member as in DME). Also, people who hear the full names will be confused by debian member/DM which are two totally different things. rather the drawback that we will be faced with endlessly outdated documentations that won't get noticed about using the old terms. Yes, I agree that this is a drawback, and we should not lightly do this. However, given the current confusion about the naming already, this seems to be the perfect moment to solve it: new names are added, the whole thing will be changing anyway. The current proposal is to make things even less clear. My proposal is to accept the extra work of getting old documents up to date (or accepting the this is an old document, it uses the old naming excuse for not-so-important documents). So just to be clear: I am, like you, totally in favour of the proposal. I just see the opportunity to fix an other problem along the way. If people disagree that the names should be changed, I'm still in favour of the proposal. :-) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Re: Developer Status
On Thu, Oct 23, 2008 at 12:18:01PM +, cobaco wrote: IIRC the last time this came up people could name 1 or 2 non-packagers who had ever bothered with NM - while it is theoretically possible for non-packagers to go through NM, quite obviously it's currently not worth the pain in the opinion of the vast majority of non-packagers. That's because NM is inherently broken, and we should not make people being able to circumvent NM to the price of being lesser folks. Being a DD is harder every day, whereas we should make it more accessible. Creating casts is going to solve nothing. Except give titles to some people who right now have none, whereas they should be DD. Not that long ago (given how many current DD have passed through that process), being a DD required a phone call with James Troup, and a google search about the guy. I don't say it was ideal, probably not (And I'm not thinking phone bills when I say that ;p), but nowadays, being a DD is hard. Not _that_ hard technically, it's hard on the nerves of the AM, the NM, it's slow as hell, it's horrid. And each time one speaks about fixing it, it adds a new layer of questions, templates, silly stuff. The more steps you add, the sooner people will stop. IOW less and less people will become full DDs, and instead of bringing new blood to the project, you bring new blood to the lesser contributors and deplete the core contributors (sorry to make such distinctions between full DDs, lesser or core contributors, it's what people try to make it about, not what I think of it). Instead, we should just have a world split in three: Users, Contributors (User that reports bugs and does occasionnal patches or similar stuff), Developers. Translators, people helping with the website and so on, any people that does _regular_ help to the project just deserves to be the latter. The fact that it requires NM for all of them is pure nonsense. As of the sacred upload rights, FWIW, I think we shouldn't give DD status to any people that is going to abuse his uploads rights when he should not. It's 10x less likely that a translator will NMU a package out from the blue, than a clueless DD will NMU a package and screws it badly. I've never heard of the former[0], I've seen the latter a couple of times. [0] Yes there are no pure translators atm in Debian, though there are quite a few DDs that work in l10n efforts, I've seen *none* of them do NMUs because they felt like it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpjZnmTyWXqo.pgp Description: PGP signature
Re: Developer Status
On Thu, Oct 23, 2008 at 11:36:42AM +0200, Jan Hauke Rahm wrote: But the more important part is IMO that the proposal *finally* respects the non-packaging contributors (and there are many, I guess). For them we can now have similar steps which in the end means DD rights without the need of learning technical stuff they won't ever use. Non-packaging contributors were always supported in the current NM process - this issue was discussed at the time the process was created and the intention was that the TS part of the process would reflect the specific contributions the person was making to Debian. I understand there are NMs who've made it through like this. That said, with the creation of the standardised question bank for TS I understand that a lot of AMs aren't comfortable with variations in the process and would want to go through the question bank with all applicants. I'd also note that while it is true that all DDs have been able to upload a large portion of the process comes down to trying to check that we get people who won't do anything too daft. One would therefore hope that people wouldn't end up using that ability if they weren't able to. Of course, people may want to restrict things for themselves (for example, some DDs avoid having access to Debian machines for security reasons). -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23 2008, Lucas Nussbaum wrote: On 22/10/08 at 22:51 +, Clint Adams wrote: On Thu, Oct 23, 2008 at 12:10:29AM +0200, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. I am disappointed in all of these people. He wrote discussed, this doesn't mean that all of them agreed fully on this proposal^Hdecision. It would be interesting to have the point of view of each of those groups. Why should my view be any more important than any other developer? Why ar you more concerned about it than the 1000-odd other developers' opinions? manoj -- The reward for working hard is more hard work. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23 2008, Pierre Habouzit wrote: On Wed, Oct 22, 2008 at 10:10:29PM +, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. Could those poeple please comment on their motivations and why they think this proposal is a good idea please ? Can you comment on your motivations, please? manoj -- All power corrupts, but we need electricity. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 01:28:44PM +, Manoj Srivastava wrote: On Thu, Oct 23 2008, Pierre Habouzit wrote: On Wed, Oct 22, 2008 at 10:10:29PM +, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. Could those poeple please comment on their motivations and why they think this proposal is a good idea please ? Can you comment on your motivations, please? Huh, I'd like to understand why all these people in Cc: have thought such a policy was so important it couldn't go through the usual Debian way of consensus, and was it looks like it's imposed to us without prior discussion. I assume it's because there is a very good reason to that, and I'm seeking it, so that I can judge the proposal on its (hidden to me right now) merits. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpozxxgdwuDa.pgp Description: PGP signature
Re: Developer Status
On Wed, Oct 22 2008, Clint Adams wrote: On Thu, Oct 23, 2008 at 12:10:29AM +0200, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. I am disappointed in all of these people. I am not sure why. A debconf, I was involved in any number of discussions at breakfast, or late at night over a beer, with various people where we proposed how to solve all kinds of issues plaguing Debian. (Like, getting Debian to be more inclusive or less flamey). Are you disappointed about the participants in those discussions as well? Before I proposed implementing user tags in the policy BTS, I had discussed it in private with people who knew more about user tagging than I did, and who correct my proposal, since what I had initially planned on doing did not work. Are you disappointed about those discussions too? I have talked to several people about voting methods and the path to improve devotee, some of which have been already coded. Are you disappointed there as well? As for this new developers proposals, I was called upon as a consultant; to see whether the proposal met constitutional requirements (I think it does), and how it would impact the secretaries vote taking efforts (I appreciate being asked if the proposal would impact my job, and being allowed to provide feedback early if it did). This way, the proposal submitted to y'all became more robust and more likely to work. (No different from user tagging policy BTS). This is, in my view, a Debian contributor (who also happens to be a delegate) trying to figure out a way of improving Debian, and making it more inclusive (with all the vaunted, oh, you do not have to package stuff, there are few non-packages in Debian), and performing his role tasks better, in a manner meant to improve Debian. This is not an evil, destroy Debian effort. Frankly, I think people are getting their panties in a twist over nothing but a sense of injured pride that they are not important enough to be asked a priori. As to the proposal itself, I have not made up my mind. I gave feedback wearing the hat of the secretary. Personally, I think I am mostly indifferent. Allowing more non-developers in, and providing a path for translators to have a say in Debian does not seem to be all that wrong. manoj -- TRANSACTION CANCELLED - FARECARD RETURNED Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23 2008, Giacomo A. Catenazzi wrote: Reading the proposal and the people involved, I think the proposal is to complex and bureaucratic and it doesn't fit to the Debian structure. If you are not looking at the proposal on its merits, but you are basing your decisions o the person(s) involved in its creation, then you are falling into a logical fallacy called argumentum ad hominem. Logical fallacies detract from the merits of your counter proposals, unfortunately. manoj -- How to make a million dollars: First, get a million dollars. Steve Martin Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thursday 2008-10-23, Pierre Habouzit wrote: On Thu, Oct 23, 2008 at 12:18:01PM +, cobaco wrote: IIRC the last time this came up people could name 1 or 2 non-packagers who had ever bothered with NM - while it is theoretically possible for non-packagers to go through NM, quite obviously it's currently not worth the pain in the opinion of the vast majority of non-packagers. That's because NM is inherently broken, and we should not make people being able to circumvent NM to the price of being lesser folks. Being a DD is harder every day, whereas we should make it more accessible. Creating casts is going to solve nothing. Except give titles to some people who right now have none, whereas they should be DD. If random Joe Developer has no commit rights to dpkg, it doesn't make him a 'lesser folk', it just makes him not involved in that aspect of Debian. The same goes for upload rights, or any other role-specific privilige. Now there's priviliges like voting or access to debian-private (or maybe that's a punishment as reffered earlier :) that should IMO be granted to all long-term contributors, regardless of exactly what role they fill within the project. Other priviliges should only be granted to those who need them, commit, upload and admin rights on debian servers all seem to fall in that category. So we have the current proposal. It makes becoming an official member of Debian more accessible - that's a good thing. It also names a number of standard roles with associated priviliges. That has absolutely nothing to do with castes and more/lesser folks. It's just a way to differ between the general and various role-specific priviliges. So how about we just drop the boatload of titles for various roles and just rephrase the whole proposal as: - if you want to be able to get privilege you need to do list of things (- with currently 3 sets of priviliges defined: - general member priviliges: vote/debian-private/@debian.org adress - upload priviliges to specific package - general upload priviliges) - everybody with general member rights is a Debian Member (or whatever other title we want to hang on 'official project member) That clears up the whole communication thing with external parties. For internal Debian stuff, the access someone has is better desribed by whatever team(s) he's part of anyway. I don't see a particular need to officially have a name for various kinds of teams wether that's packagers, translators, doc writers or whatever. A lot of people cross those boundaries anyway, so need little categories they'll be not. (For those who do care I'll wish you happy bikeshedding on the names and makeups of the various groups and leave you to it) All in all I find the current proposal to be a huge step in the right direction, and something that's long overdue. The more steps you add, the sooner people will stop. IOW less and less people will become full DDs, and instead of bringing new blood to the project, you bring new blood to the lesser contributors and deplete the core contributors (sorry to make such distinctions between full DDs, lesser or core contributors, it's what people try to make it about, not what I think of it). Instead, we should just have a world split in three: Users, Contributors (User that reports bugs and does occasionnal patches or similar stuff), Developers. Translators, people helping with the website and so on, any people that does _regular_ help to the project just deserves to be the latter. The fact that it requires NM for all of them is pure nonsense. I think we agree :) As of the sacred upload rights, FWIW, I think we shouldn't give DD status to any people that is going to abuse his uploads rights when he should not. It's 10x less likely that a translator will NMU a package out from the blue, than a clueless DD will NMU a package and screws it badly. I've never heard of the former[0], I've seen the latter a couple of times. however unlikely non-packagers are to abuse upload privilige sooner or later someone will (not necessarily intentionally). Like commit rights or DA- access, only giving upload rights to people who need it makes most sense IMO -- Cheers, Cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Re: Developer Status
On jeu, oct 23, 2008 at 02:55:46 +, cobaco wrote: The more steps you add, the sooner people will stop. IOW less and less people will become full DDs, and instead of bringing new blood to the project, you bring new blood to the lesser contributors and deplete the core contributors (sorry to make such distinctions between full DDs, lesser or core contributors, it's what people try to make it about, not what I think of it). Instead, we should just have a world split in three: Users, Contributors (User that reports bugs and does occasionnal patches or similar stuff), Developers. Translators, people helping with the website and so on, any people that does _regular_ help to the project just deserves to be the latter. The fact that it requires NM for all of them is pure nonsense. I think we agree :) Actually no, because what I wrote deceive what I meant. The fact that it requires the current for of NM for any of them, the ones who will upload packages included, is awful. I hate in Ganneff proposal the fact that it just standardize the 6 months delay to be a DD. It's acknowledging that we suck, and trying nothing to fix the problem. It's unacceptable to me. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgptqtjWZXeTy.pgp Description: PGP signature
Re: Developer Status
On Thu, Oct 23 2008, Pierre Habouzit wrote: On Thu, Oct 23, 2008 at 01:28:44PM +, Manoj Srivastava wrote: On Thu, Oct 23 2008, Pierre Habouzit wrote: On Wed, Oct 22, 2008 at 10:10:29PM +, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. Could those poeple please comment on their motivations and why they think this proposal is a good idea please ? Can you comment on your motivations, please? Huh, I'd like to understand why all these people in Cc: have thought such a policy was so important it couldn't go through the usual Debian way of consensus, and was it looks like it's imposed to us without prior discussion. I assume it's because there is a very good reason to that, and I'm seeking it, so that I can judge the proposal on its (hidden to me right now) merits. I did not think that polishing a plan, making sure it would work, and getting buy in from people whose work it might impact in any way precludes it from consensus building. I hate half baked proposals thrown over the wall for the general public to chew on. A well detailed, thought out, workable plan is to be preferred in every way to half baked ideas, so I helped bake it. How it goes from here is up to the proposer. manoj -- Always leave room to add an explanation if it doesn't work out. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-m-team] Developer Status
Pierre Habouzit wrote: On Thu, Oct 23, 2008 at 01:28:44PM +, Manoj Srivastava wrote: On Thu, Oct 23 2008, Pierre Habouzit wrote: On Wed, Oct 22, 2008 at 10:10:29PM +, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. Could those poeple please comment on their motivations and why they think this proposal is a good idea please ? Can you comment on your motivations, please? Huh, I'd like to understand why all these people in Cc: have thought such a policy was so important it couldn't go through the usual Debian way of consensus, and was it looks like it's imposed to us without prior discussion. I assume it's because there is a very good reason to that, and I'm seeking it, so that I can judge the proposal on its (hidden to me right now) merits. I'm in the CC and the first I heard of it was the post to d-d-a. I think it contains some good ideas, but in the areas releated to DM and DM-Upload-Allowed fields, it's a regression. -- see shy jo signature.asc Description: Digital signature
Re: Developer Status
On Thu, Oct 23, 2008 at 08:45:11AM -0500, Manoj Srivastava wrote: This is not an evil, destroy Debian effort. Thanks Manoj, very well written. I totally agree. For sure the tone _could_ have been made more clear that since the beginning, but hey, we should learn how to read past each other tones. We are expected to have experience in mail communication after all ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
Lucas Nussbaum [EMAIL PROTECTED] writes: On 22/10/08 at 22:51 +, Clint Adams wrote: On Thu, Oct 23, 2008 at 12:10:29AM +0200, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. I am disappointed in all of these people. He wrote discussed, this doesn't mean that all of them agreed fully on this proposal^Hdecision. It would be interesting to have the point of view of each of those groups. You all know I'm lazy, so I'll just repeat myself: | (A small TS basically, the most important TS questions for them.) | This seems excessive. The point of DM was to kill off all the | bureaucracy and allow people in when they were able to convince a DD of | their skills. Adding a (small) NM process makes DM completely useless, I | think. [...] | Anyway, I've thought about this some more. At the moment, your proposal | seems to have three goals: |(i) Allow non-developer contributors to become project members. | (ii) Get rid of the horrible hack that DM is and replace it with |something closer to NM. [... stuff that was removed from the proposal and is now irrelevant ...] | (i) IMO needs a change to the constitution, as said before. This should | be a no-brainer, someone needs to prepare the changes, send it to -vote, | then kick the secretary to do the CfV. This should go through without | much discussion (draft title: Constitutional Amendment: Allow | non-developer members). | | (ii) is the messy part. Formally, doing it by declamation from | DAM/ftp-team is iffy, as it gets rid of a process that was endorsed by | the developer body in a GR last year. | The other problem with your proposal is that you make it harder to | contribute as package maintainer. Heck, making that easier was the whole | point of DM, reverting that change and replacing DM by Debian's NM | process five years ago (and that's basically what you are suggesting - | TS has grown excessively, a small subset of today's questions is what | people needed to do 5 years ago). | The fact that the NM committee (and not some random DD) does the package | check before allowing DM uploads should be enough. That's actually | what I had in mind when I proposed something like DM 2 years ago - which | was fine with you back then. Marc -- Fachbegriffe der Informatik - Einfach erklärt 38: Windows 95 Das Fortran 77 der Benutzungsoberflächen pgp800gRlhcJm.pgp Description: PGP signature
Re: Developer Status
On Thu, Oct 23, 2008 at 12:10:29AM +0200, Joerg Jaspert wrote: Developer Status And I should probably have written this inside the mail itself, but the most obvious things are those you forget. This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. And then you mention NM committee everywhere in your email and it was not asked at all. Apparently, DSA or keyring-maint knows more about problems or how to handle prospective developers that AM who has succesfully proccessed one NM applicant. Disclaimer: Even I am still listed as AM, I am supposed to not be any longer, I asked to stop working as AM after the election of last FD members that was not discussed at all in NM committe. I asked FD/DAM about this election and answer were totally poor and dissappoiting. Ana -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Manoj Srivastava wrote: On Thu, Oct 23 2008, Giacomo A. Catenazzi wrote: Reading the proposal and the people involved, I think the proposal is to complex and bureaucratic and it doesn't fit to the Debian structure. If you are not looking at the proposal on its merits, but you are basing your decisions o the person(s) involved in its creation, then you are falling into a logical fallacy called argumentum ad hominem. Logical fallacies detract from the merits of your counter proposals, unfortunately. It is only bad English. Joerg nominated teams, not persons. My and the people involved should be read as and the number of teams involved. The number of teams increment the bureaucracy (changing the proposal, coordination), and doesn't fit the Debian structure (role [proposers] vs. hierarchical [proposal]). It is bureaucratic also because of the number of stages between user and DD, etc. Anyway, it seems that other DD have similar ideas, so I let other to express them. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Lucas Nussbaum wrote: On 22/10/08 at 23:33 +0200, Joerg Jaspert wrote: and keyring managers would like to remain the authoritative source for who is in Debian. Indeed, that's a problem. What about changing the DM process so that keyring managers are responsible for this keyring as well? That's what he said: Changes to the DM Keyring - Keyring management will be moved to the control of keyring-maint. The NM committee will decide who will be added or removed, similiar to the way keyring-maint and DAM currently work together. [...] They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. There's a problem with DM currently: it doesn't work well with massively comaintained packages. For example, if you have: - a team with DMs DMa and DMb - DMa became DM to maintain Pa - DMb became DM to maintain Pb - DMa wants to help with the maintainance of Pb, but should not be given upload rights for Pb - DMb wants to help with the maintainance of Pa, but should not be given upload rights for Pa That's not a problem which should be solved by a technical workaround. If you are not confident enough that either DMa won't upload Pb or DMb won't upload Pa then why are you giving her/him rights to change anything in either Pa or Pb? It's like if you wanted to limit what packages DDs can upload and which not. Then you have a problem. If you are maintaining a centralized list for DM upload rights, please implement it as a list of (DM, Package), not just as a list of (Package). Or even better, a list of (DM, Package, DD who endorsed this DM for this Package). Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
First of all, I want to express my support for this idea. I think it can be improved. Specially, I think that having so many statuses is confusing. And I'd like the system to highlight the relationship with Debian, instead of the actual rights. Ideally, this would be defining two classes (yes, and then we can proceed to declare the war between classes, and take the winter palace, etc..) one that defines a full member, who can vote, be delegate, etc, and a contributor which cannot do that, but it's acknowledged anyways with an email address (I'd say a @debian.org address), an entry in LDAP, etc. That way, then you can grant people the right to upload, log in to machines, etc, independently of the class status. For example, I think that a NM should be given login privileges because that's many times needed to solve bugs. About this particular message in the thread: On Thu, Oct 23, 2008 at 07:41, Julien BLACHE [EMAIL PROTECTED] wrote: And also that feeling you seem to have that you are above the lot of mere mortals that we, DDs without delegations, are. [...] Pretty much the only thing in your proposal I agree with is the bit about getting DM under proper controls. Certainly you sound like you're above the rest of the mere mortals who aren't DDs. I'm afraid you're going to need more than very few questions from TS. I think it's important that DMs know their stuff, for we have quite some crappy packages in the archive already and we don't really need more of them. Can we stop blaming the problems of Debian on DM, sponsored uploads, etc? I've seen *plenty* of crappy packages and crappy methods from full-fledged DDs Until the day that every DD has to pass the same tests, and revalidate it periodically, this argument has no grounds. In my case, for example, I had to do a lot more than get a phone call from elmo to get my DD status. Heck, having an upload sponsored is way more work than that! And that I totally disagree with. Being lintian-clean doesn't tell much about the quality of the package, and tells exactly nothing about the quality of the packager. I think we've had some examples of clueless DMs and even clueless new DDs in recent times (proving that even a full TS might not be enough). Do you want more of that, or less of that? Do I really want to know all what's needed in TS to maintain a few perl or python packages? What about a silly C application that has no complex issues? The answer is no, I don't need that. And I might not need some of that stuff until the day I start packaging a shared library. I will need some of that stuff the day I have to do a transition, or perform some debhelper tricks, etc. But people can start working, feel acknowledged and encouraged, and LEARN, instead of being pressured with all the NM stuff at once. What is your big fear? That a newbie uploads a broken libfoo-perl, which has a popcon of two and no reverse-deps? I have a problem with non-technical persons voting on technical issues, or issues having technical implications for the developer body. I have even more of a problem with non-technical persons leading a technical project. Then we should ban non-lawyers to vote on anything related to copyrights, patents, etc. Modifying the constitution should be protected from incompetent non-lawyers too! And what part of being a DPL can't be done by somebody who knows the project, does hard work, and is respected but hates packaging stuff? I can think of a couple of examples that could even win that election... I am against this part of your proposal. Voting rights should be coupled with proper understanding of the Project at large, including the technical stuff, which is, after all, the base of this Project. Understanding the project doesn't mean understanding dpkg, there are things much more important, because, remember... above all we are a group of people, and maybe this mail shows that you should not be allowed to vote on social issues? -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 05:33:19PM +0900, Charles Plessy wrote: Joerg, this means that if we want to have a word to say about how the Debian project defines its members, we have to participate to this discussion *now*, or block it. snip This is a situation that will not help to get the best out of the discussion. Won't you accept to postpone it to after the release? Can we please stop this kind of arguments? 1) Once something like that gets posted, experience tells that there is no way to stop the discussion. Trying is pretty much useless. 2) It is not like we should stop doing *anything* until we release. I've joined the discussion and also signed up for the http://wiki.debian.org/BugSprint. Given that we are only 17 people listed there, maybe you should better advertise that page (or similar initiative) instead of asking people to not discuss something which is very interesting for our project. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
On Thu, Oct 23, 2008 at 05:55:00PM +0200, Pierre Habouzit wrote: I hate in Ganneff proposal the fact that it just standardize the 6 months delay to be a DD. It's acknowledging that we suck, and trying nothing to fix the problem. It's unacceptable to me. Other projects are doing similar; e.g. I think there is a 4-6 month delay for Ubuntu members before they can apply as Ubuntu MOTU, in which time they have to show sustained contributions and are getting evaluated. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, 23 Oct 2008, Martín Ferrari wrote: For example, I think that a NM should be given login privileges because that's many times needed to solve bugs. Theoretically being DD is not a prerequisite to getting shells on debian systems. Practically it is since we have no infrastructure to maintain such people's keys etc. Having NMs in a keyring, maintained by keyring-maint, would probably solve this, and we could provide access to our porter machines when there is the need. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 09:59:09AM +0200, Bas Wijnen wrote: - Debian Developing Member (DDM) = what's called DD in the proposal. Given how rooted is the acronym DD in the Debian community, I doubt it is a good idea to change it or even to get rid of it. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
On Thu, Oct 23, 2008 at 01:20:32PM +0100, Mark Brown wrote: But the more important part is IMO that the proposal *finally* respects the non-packaging contributors (and there are many, I guess). For them we can now have similar steps which in the end means DD rights without the need of learning technical stuff they won't ever use. Non-packaging contributors were always supported in the current NM process - this issue was discussed at the time the process was created and the intention was that the TS part of the process would reflect the specific contributions the person was making to Debian. I understand there are NMs who've made it through like this. Sorry, but that's not support, or at least not *complete* support. I do want non-technical contributors in Debian (that's the main reason why I'm generally in favor of this proposal), and I do want them to *vote*, because Debian is more than the union of its parts^W packages. Still, I won't be at ease with upload rights to the archive given by default to non-technical contributors. The status quo did not support inhibiting upload rights to voting developers (OK, it could have been enforced via dak, but that's not an answer). The new proposal supports much better non-technical contributors (which Debian badly needs to recognize, really) and is not against the kind of pre-existing support you have mentioned. Cheers. PS thanks to Jan Hauke for the previous you were replying to -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
* Joerg Jaspert: Following our Constitution §8.1.2, DAM declares that Debian Members are to be treated as Developers who do not maintain packages wherever the term Developer is used in one of our documents. This strongly smells like abuse of procedure. I know it's difficult to implement this properly in Debian's framework, but can we please at least try to do it that way? The proposed approach might have some unwanted consequences (like the Technical Committee deciding on full DD status). I'm also surprised that voting rights come before global uploading rights. Shouldn't that be the other way round? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joerg Jaspert wrote: We plan to integrate DM more closely into the NM process/system while keeping the spirit of easing entry into Debian for newcomers. At the same time we add a separate track for less-technical contributors. I have to say that I don't like *at all* the way that you're handling this; you posted to d-d-a which implies that this is an announcement, not a proposal and while I know that it is within your powers to do such changes, I think that it is obvious that something like that should be decided (and by that I don't mean overruled) by the body of the DDs and not by any DPL delegate. Also, you admitted that you forgot to clarify who you (plural) are, only to reveal us that you discussed this with other delegates, without further explaining what exactly you mean by that. And from Manoj's reply to the thread (and correct me if I'm wrong) it surely didn't sound like he planned anything with you. It is no secret that discussing stuff is not your style (and I don't mean this as an insult), but please try to bear with us and be more cooperative, both within the project and within specific teams (I'm thinking DebConf organization and sponsorship teams here). I, for one, would support or even propose a GR to overrule you (whoever you might be) as a delegate if you proceed with enforcing this proposal without getting an approval by a GR. Debian Contributor -- Debian Maintainer - Debian Member - Debian Developer Now, regarding your proposal itself, I agree with others that it sounds too bureaucratic, even for Debian. Explaining the differences between maintainer, uploader, Debian Maintainer and Debian Developer to outsiders is hard enough as it is. Please, let's try to Keep It Simple, Stupid. Also, I find it amazing that noone has mentioned all those Alioth -guest users. Am I the only one to think that we should find a way to make Alioth and its users more official and acknowledge that most of those users work for Debian and should be considered members of the project? contributor.debian.org mail Let's not forget that all Alioth users get a mail alias under d.o, we shouldn't consider it _that_ big of a deal. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 03:12:01PM -0200, Martín Ferrari wrote: Ideally, this would be defining two classes (yes, and then we can proceed to declare the war between classes, and take the winter palace, etc..) one that defines a full member, who can vote, be delegate, etc, and a contributor which cannot do that, but it's acknowledged anyways with an email address (I'd say a @debian.org address), an entry in LDAP, etc. Sorry, but the devil is in the details. In this case is precisely in the etc. :-) For example, do you think we should have a member which can vote but can not upload? I think we should, and that's the main benefit of this proposal. A benefit I think we should have as a project. Let me play with ASCII art: Rights | VoteUpload Role | ---+- OUT| 0 0 DD | X X DM | 0 X DC | X 0 DC is the Debian Contributor role we are missing. Of course you can add rights (i.e., columns to the table), and hence add an exponentially growing numbers of roles, the point is which of these roles are the interesting one. IMO DC is one of them. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Forget classes, think privileges (was: Developer Status)
martin f krafft [EMAIL PROTECTED] wrote: http://lists.debian.org/debian-project/2005/02/msg00079.html [...] Why don't we just take each and every of those privileges and define criteria for how to obtain the privilege, and then simply give people privileges according to what they need, rather than having a defined set of rigid classes? Obviously, one could still group privileges (e.g. to be able to vote, you have to endure debian-private). I think that's an excellent idea. I would also like any privilege request queue handled in an approximately First In First Out manner and I would try to vote accordingly in a GR. I've been suggesting NM reform since 2003ish. One recent post is:- http://lists.debian.org/debian-project/2007/11/msg00085.html Thanks for saving me time by putting the suggestion in better words than I could! -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 08:01:17PM +0300, Faidon Liambotis wrote: I, for one, would support or even propose a GR to overrule you (whoever you might be) as a delegate if you proceed with enforcing this proposal without getting an approval by a GR. Can we please wrap part of this thread up by saying that: most of us---i.e., the participants to this thread---would BE OK with passing this proposal *with GR* (after the usual needed discussion time), whereas most of us would NOT BE OK with passing this proposal *without GR*? I have the feeling this is the global sentiment, but you know: I think I've expressed the same concept as you (speaking with Faidon here), but there is a whole mileage between the way I put it down and the way you put it down. (And I'm on purpose not judging the relative merits of the two ways.) Still, I think I'll be more than happy to avoid experiencing in this thread everything which is in between :) Debian Contributor -- Debian Maintainer - Debian Member - Debian Developer Now, regarding your proposal itself, I agree with others that it sounds too bureaucratic, even for Debian. Is it? I mean, the names looks clear to me. And the procedure is just two alternative paths: one towards voting contributors with no upload rights, the other towards voting contributors with upload rights. But of course bureaucratic is subjective, hence your opinion is as valuable as mine, I'm only surprised that that many people find it so. Explaining the differences between maintainer, uploader, Debian Maintainer and Debian Developer to outsiders is hard enough as it is. TBH, the current distinction to DM and DD looks like the more complex part of the game, but that part (for what it concerns the difficulty of explaining it) is left untouched by this proposal. Also, I find it amazing that noone has mentioned all those Alioth -guest users. Am I the only one to think that we should find a way to make Alioth and its users more official and acknowledge that most of those users work for Debian and should be considered members of the project? I haven't thought about it, but this is a very interesting observation indeed (same on the other on the alioth.d.o mail domain). Still, it is not clear to me how to merge the two proposals. I mean, while I see a partial overlapping among the two infrastructure, I really do not want to get away from alioth project admins the ability to decide upon which accounts are member of their projects. Are you maybe suggesting that alioth account creation should be bound to being a debian contributor? I see more harm than good in something like that ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
On Thu, Oct 23, 2008 at 07:37:51PM +0200, Florian Weimer wrote: I'm also surprised that voting rights come before global uploading rights. Shouldn't that be the other way round? IMO they should be decoupled. It should be able to have the one without the other and vice-versa (see the ASCII art I've posted already). If there is no consensus on that, ... then we have just found a very good reason to have a GR :-) Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach signature.asc Description: Digital signature
Re: Developer Status
On Thu, Oct 23, 2008 at 16:01, Stefano Zacchiroli [EMAIL PROTECTED] wrote: Sorry, but the devil is in the details. In this case is precisely in the etc. :-) For example, do you think we should have a member which can vote but can not upload? I think we should, and that's the main benefit of this proposal. A benefit I think we should have as a project. Yes! What I was saying is to detach the membership status (i.e. out / contributor / member) from the specific right, to as not have a nightmare of acronyms :) But I do believe voting should not be restricted to what's today a DD. Maybe I was not clear enough. -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Marc 'HE' Brockschmidt a écrit : Lucas Nussbaum [EMAIL PROTECTED] writes: On 22/10/08 at 22:51 +, Clint Adams wrote: On Thu, Oct 23, 2008 at 12:10:29AM +0200, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. I am disappointed in all of these people. He wrote discussed, this doesn't mean that all of them agreed fully on this proposal^Hdecision. It would be interesting to have the point of view of each of those groups. You all know I'm lazy, so I'll just repeat myself: If I understand correctly, that is the answer you sent to Joerg, right? | (A small TS basically, the most important TS questions for them.) | This seems excessive. The point of DM was to kill off all the | bureaucracy and allow people in when they were able to convince a DD of | their skills. Adding a (small) NM process makes DM completely useless, I | think. [...] | Anyway, I've thought about this some more. At the moment, your proposal | seems to have three goals: |(i) Allow non-developer contributors to become project members. | (ii) Get rid of the horrible hack that DM is and replace it with |something closer to NM. [... stuff that was removed from the proposal and is now irrelevant ...] | (i) IMO needs a change to the constitution, as said before. This should | be a no-brainer, someone needs to prepare the changes, send it to -vote, | then kick the secretary to do the CfV. This should go through without | much discussion (draft title: Constitutional Amendment: Allow | non-developer members). | | (ii) is the messy part. Formally, doing it by declamation from | DAM/ftp-team is iffy, as it gets rid of a process that was endorsed by | the developer body in a GR last year. | The other problem with your proposal is that you make it harder to | contribute as package maintainer. Heck, making that easier was the whole | point of DM, reverting that change and replacing DM by Debian's NM | process five years ago (and that's basically what you are suggesting - | TS has grown excessively, a small subset of today's questions is what | people needed to do 5 years ago). | The fact that the NM committee (and not some random DD) does the package | check before allowing DM uploads should be enough. That's actually | what I had in mind when I proposed something like DM 2 years ago - which | was fine with you back then. How long has it been discussed? I am really surprised that your comments still fully apply to the current proposal (it looks like a policy), so basically your comments havn't been addressed. Really strange for a mail using we to represent numerous teams/persons, including you as a member of the Front Desk. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Luk Claes wrote: Raphael Geissert wrote: What about getting every maintainer's key in a keyring and LDAP? it would finally allow for a better management system to take place The problem is that not all maintainers have keys in the first place. Which in theory is not good. Even packages that later get uploaded by a DD should be signed. /me thinks about double-signed files (first signature by the maintainer, second by the uploader). Cheers Luk Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On 23/10/08 at 12:05 -0500, Raphael Geissert wrote: Lucas Nussbaum wrote: On 22/10/08 at 23:33 +0200, Joerg Jaspert wrote: and keyring managers would like to remain the authoritative source for who is in Debian. Indeed, that's a problem. What about changing the DM process so that keyring managers are responsible for this keyring as well? That's what he said: What I meant was: What about *simply* changing the DM process so that keyring managers are responsible for this keyring as well, and dropping all the other changes in Joerg's mail? Changes to the DM Keyring - Keyring management will be moved to the control of keyring-maint. The NM committee will decide who will be added or removed, similiar to the way keyring-maint and DAM currently work together. [...] They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. There's a problem with DM currently: it doesn't work well with massively comaintained packages. For example, if you have: - a team with DMs DMa and DMb - DMa became DM to maintain Pa - DMb became DM to maintain Pb - DMa wants to help with the maintainance of Pb, but should not be given upload rights for Pb - DMb wants to help with the maintainance of Pa, but should not be given upload rights for Pa That's not a problem which should be solved by a technical workaround. If you are not confident enough that either DMa won't upload Pb or DMb won't upload Pa then why are you giving her/him rights to change anything in either Pa or Pb? DM was sold as a limited upload rights solution. I think that some people did not realize that it wasn't that simple: some people might have the right to upload stuff by mistake because of this design flaw. It's like if you wanted to limit what packages DDs can upload and which not. Aren't we talking about DM? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joerg Jaspert wrote: On 11547 March 1977, Felipe Sateler wrote: While, strictly speaking, this increases the barrier to get DM compared to the current implementation of DM, we do not think it is an unreasonable or too high level. Anyone who is able to get a package put together in a lintian clean way will be able to get DM without much effort or time used. So this basically requires DMs to do the (somewhat reduced) PP and TS questions, and I don't see the real reason for this. The idea behind DMs is to maintain a package one knows how to maintain. The only reason I can see here is that DDs are not being trusted in their advocations, which is a far worse problem that won't get solved by this. As written above, the actual amount of checks DM have to do is left to the NM Committee and can be adjusted as needed. This does IMO not contradict DM, but it enhances the value of it in the long term. Right now you can be DM, but have to pass the full NM before you can get DD. In future you get DM (and yes, you have a tiny amount of more work to do for this), be it for a few months and then you can get DD relatively easy by just doing the last few steps needed. Ie. once you are a DM you are already about half through NM. What you are doing is moving the work from one side to the other (pre-DD to pre-DM). Given that the idea of DMs was to reduce the barrier of entry, it kind of defeats the purpose. Those two classes are the initial set in which every NM will end up. After six months as DC or DM one might chose to become a Debian Member or Debian Developer. This - ensures that the interest in Debian isn't short-term. Why do people keep thinking this is a good thing? Because short term involvement usually creates more work than it helps, IME? I would like some numbers to back this claim. Also, what is short term? I would find one year to be sufficient to do a great amount of good work, but then a 6-month process is too much bureaucracy. - enables them to learn more about the workings in Debian and generally helps them for the next step. They should be doing this on their own, and not force an arbitrary limit on them. What if they did this before applying for DD/DME/DM/DC status? Then it will be a no-brainer to pass the rest in this process. That is not the point. Why do I have to wait 6 months to learn more when I already did that? Unfortunately a large number of people trying to join Debian did not do that before applying, as past has shown us. I really don't see why NM should be a mentoring process. Instead of asking NMs to do stuff during the process, I think it would be much better to ask them to show what they have already done. This way you get less work for the AM/whatever and force NMs to do their homework before applying and not while. This all smells like a whole lot of bureocracy for no gain to me. I do see the gain for everyone that wants to join and also for those non-technical people that do help to make Debian better. Not everything in Debian is about packaging alone, even if some people (not attacking you, thats a general some) love to think there is nothing besides packages. We do want translators, we do want documentation writers, they all help to make Debian even more the Universal OS by opening it up to those not speaking english. Or those that aren't the most clueful ones in technical things and just want to use a great OS to get their daily work done. Yes, the most important part in Debian is about packaging, without this there won't be a place for translators/documentation writers, but that doesn't mean we should ignore or deny their existance. I do want translators, documentation writers, etc to be recognized for their work. I also want them to have the tools to do their work. The DMe thing would only accomplish adding your name to a list, since it gives you no tool/privilege to do your work better/easier. I want them to do, eg, i18n campaigns like Christian Perrier does. For that they require technical skills, that is true. But then every contributor to any software project has to learn a few things before they can be effective (eg, learn about patching or the VCS in use). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Joerg Jaspert wrote: On 11547 March 1977, Raphael Geissert wrote: Debian Maintainer - They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. I believe everything is ok up to this point: why does the NMC need to review the packages? I mean: has there been any problem with the current way DMs are allowed to upload? can't the project trust in DDs as to what packages can DMs upload? We do trust DDs - everyone can become a member of the NM Committee, you just have to do a little AM work. ...you just have to do a /little/ extra work I would say. I don't think that's the right way to do it. If a reviewing team is really needed it should be built from the QA side, not from the management/NM side. Which would thereby have to drop the AM work requirement and instead put some other sort of requirement, if needed/wanted. By adding this extra step it makes the process more complex and turns something useful into something more like a process with lots of paper-work: It would require to: 1. first: find a sponsor to upload a package, 2. then become trusted, 3. get advocated, 4. ID check (btw, will it still require keys to be signed by DDs? or are DCs or Dwhatever more than enough?), 5. TS check, 6. SOC agreement, 7. NMC approval, 8. keyring-maints stuff, 9. NMC approval of packages. Umm, well: 1. no change to now 2. no change to now 3. no change to now, only the destination of the approval mail for DMs changes 4. Yes, this is a change, you need a DD or DME to sign your key. One might adjust it so that DC/DM can sign for other DC/DM (or maybe make that 2 of them sign one). 5. I hope you read the footnote? It can easily be adjusted to fit whatever the current situation is. Which means that they can make it a full TS plus must fix 1000 RC bugs - or just nothing. Yes, but my concern is about turning that part into templates that fit everyone[tm]; just like the current NM process. 6. no change to now 7. is DM-Team approval now 8. is DM-Team keyring foo stuff now 7 and 8 are only one right now. 9. this can easily be in 7., and only get invoked if you want to add more packages to your list later Which makes the process more complex. [DCDMQ] The intention is that the NM-Committee will select the actual set of questions used, not this mail. It can easily be adjusted to fit whatever the current situation may want to have. For DM we imagine it would be a very limited TS set, like making sure someone can deal with the BTS and knows the basic tools (lintian, dput/dupload, debsign). It is not meant as a full (first part) of NM and lots of boring tasks before one get DM, but as a basic check for a minimum knowledge. In contrast to current DM this is based on source packages and allows uploads of new binary components, which have to pass NEW, too. That's great, but what is it going to happen to cases like #502943? That is an interesting corner case. (Note that for todays code I'm happy to accept patches/git trees to merge to fix any of such errors). Im currently not 100% sure what the best is in this case. I'd say first of all take that upload into account to allow the DM to upload the package, and to comply with the GR check if the package isn't taking over a binary package from another source package _which is also in the same distro_. Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, 23 Oct 2008, Raphael Geissert wrote: Having NMs in a keyring, maintained by keyring-maint, would probably solve this, and we could provide access to our porter machines when there is the need. What about getting every maintainer's key in a keyring and LDAP? it would finally allow for a better management system to take place The LDAP is DSA's tool for managing shell accounts and per-user email setup. It deals primarily in terms of people, who have a uid, a name, a forwarding email address, a PGP key (fingerprint), etc. Maintainers are concept of packages and thus leans more towards the ftpmaster side who, if I understand correctly, already maintain a list of all maintainers somewhere in their database. Maintainers are also often role accounts, like I guess Debian OCaml Maintainers. Therefore I don't think trying to get this particular piece of information into the debian LDAP would be particularly straight forward. Also I question what good it would actually do. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Felipe Sateler wrote: I do want translators, documentation writers, etc to be recognized for their work. I also want them to have the tools to do their work. The DMe thing would ^^^ That should be DC. only accomplish adding your name to a list, since it gives you no tool/privilege to do your work better/easier. I want them to do, eg, i18n campaigns like Christian Perrier does. For that they require technical skills, that is true. But then every contributor to any software project has to learn a few things before they can be effective (eg, learn about patching or the VCS in use). -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Peter Palfrader wrote: On Thu, 23 Oct 2008, Raphael Geissert wrote: Having NMs in a keyring, maintained by keyring-maint, would probably solve this, and we could provide access to our porter machines when there is the need. What about getting every maintainer's key in a keyring and LDAP? it would finally allow for a better management system to take place The LDAP is DSA's tool for managing shell accounts and per-user email setup. It deals primarily in terms of people, who have a uid, a name, a forwarding email address, a PGP key (fingerprint), etc. Maintainers are concept of packages and thus leans more towards the ftpmaster side who, if I understand correctly, already maintain a list of all maintainers somewhere in their database. Maintainers are also often role accounts, like I guess Debian OCaml Maintainers. Therefore I don't think trying to get this particular piece of information into the debian LDAP would be particularly straight forward. Also I question what good it would actually do. If you only keep human maintainers in LDAP (or teams turned into LDAP groups) you will end up with all the information you to easily know who is who and to grant access to stuff. It is also about turning data into, linked, information. Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Raphael Geissert wrote: Joerg Jaspert wrote: On 11547 March 1977, Raphael Geissert wrote: Debian Maintainer - They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. I believe everything is ok up to this point: why does the NMC need to review the packages? I mean: has there been any problem with the current way DMs are allowed to upload? can't the project trust in DDs as to what packages can DMs upload? We do trust DDs - everyone can become a member of the NM Committee, you just have to do a little AM work. ...you just have to do a /little/ extra work I would say. I don't think that's the right way to do it. If a reviewing team is really needed it should be built from the QA side, not from the management/NM side. Which would thereby have to drop the AM work requirement and instead put some other sort of requirement, if needed/wanted. The NM committee is composed of AMs which already completed doing a review process succesfully in the last couple of months. So I think it's only logical to ask them to review. I think a (prospective) DM is better served by such a (hopefully) proper review than a possibly less good review of a random DD. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
2008/10/23 Julien Cristau [EMAIL PROTECTED]: On Thu, Oct 23, 2008 at 14:41:13 -0500, Raphael Geissert wrote: Peter Palfrader wrote: Also I question what good it would actually do. If you only keep human maintainers in LDAP (or teams turned into LDAP groups) you will end up with all the information you to easily know who is who and to grant access to stuff. ^ IOW: this could help turn maintainers into something closer to the project by: a) keeping track of them b) recognising them: either you are there or not c) granting access even if you are just a maintainer and not a Dsomething d) letting maintainers indicate when they are in VAC, to differentiate them from MIA e) insert your own idea here It is also about turning data into, linked, information. If this answers the above, or actually means anything at all, then I think I missed it. Hope that explains it better. Sorry for not doing it before. Cheers, Julien Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net Rita Rudner - I wonder if other dogs think poodles are members of a weird religious cult. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, Oct 23, 2008 at 03:51:47PM +0200, Pierre Habouzit wrote: On Thu, Oct 23, 2008 at 01:28:44PM +, Manoj Srivastava wrote: Can you comment on your motivations, please? Huh, I'd like to understand why all these people in Cc: have thought such a policy was so important it couldn't go through the usual Debian way of consensus, and was it looks like it's imposed to us without prior discussion. I assume it's because there is a very good reason to that, and I'm seeking it, so that I can judge the proposal on its (hidden to me right now) merits. Actually, the merits of the plan are not hidden to you. They are stated and/or derived from the original post to d-d-a. What is hidden (and what you are apparently seeking) is the motivations. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Developer Status
2008/10/23 Luk Claes [EMAIL PROTECTED]: Raphael Geissert wrote: Joerg Jaspert wrote: On 11547 March 1977, Raphael Geissert wrote: Debian Maintainer - They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. I believe everything is ok up to this point: why does the NMC need to review the packages? I mean: has there been any problem with the current way DMs are allowed to upload? can't the project trust in DDs as to what packages can DMs upload? We do trust DDs - everyone can become a member of the NM Committee, you just have to do a little AM work. ...you just have to do a /little/ extra work I would say. I don't think that's the right way to do it. If a reviewing team is really needed it should be built from the QA side, not from the management/NM side. Which would thereby have to drop the AM work requirement and instead put some other sort of requirement, if needed/wanted. The NM committee is composed of AMs which already completed doing a review process succesfully in the last couple of months. So I think it's only logical to ask them to review. I think a (prospective) DM is better served by such a (hopefully) proper review than a possibly less good review of a random DD. Right, but do the members of the NMC cover the wide variety of programming languages? or what kind of review are they going to do? just packaging stuff? if it is just the latter it would be much easier and faster to send a RFC to -mentors and let people scream out loud. And please note that I said QA side, with which I didn't mean to refer to the QA group, but to a variety of people who know what to look at and how to do it; not a random AM who happens to have already completed doing a review process successfully (which actually doesn't guarantee that the AM is competent enough, as the usual NM process consists on sending the templates and later reviewing the responses). Continuing with my example of sending an RFC to -mentors, I would be interested in comparing the list of AMs also doing -mentors works with those who don't, and with regular contributors to -mentors who are not involved with NM. Cheers Luk Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net Robert Benchley - The surest way to make a monkey of a man is to quote him. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
Raphael Geissert wrote: 2008/10/23 Luk Claes [EMAIL PROTECTED]: Raphael Geissert wrote: Joerg Jaspert wrote: On 11547 March 1977, Raphael Geissert wrote: Debian Maintainer - They are allowed to upload their own (source) package. The allowed list of (source) packages to upload can be edited by any member of the NM committee[NMC], who will do a package check before they add new packages to the DM's list. I believe everything is ok up to this point: why does the NMC need to review the packages? I mean: has there been any problem with the current way DMs are allowed to upload? can't the project trust in DDs as to what packages can DMs upload? We do trust DDs - everyone can become a member of the NM Committee, you just have to do a little AM work. ...you just have to do a /little/ extra work I would say. I don't think that's the right way to do it. If a reviewing team is really needed it should be built from the QA side, not from the management/NM side. Which would thereby have to drop the AM work requirement and instead put some other sort of requirement, if needed/wanted. The NM committee is composed of AMs which already completed doing a review process succesfully in the last couple of months. So I think it's only logical to ask them to review. I think a (prospective) DM is better served by such a (hopefully) proper review than a possibly less good review of a random DD. Right, but do the members of the NMC cover the wide variety of programming languages? or what kind of review are they going to do? just packaging stuff? if it is just the latter it would be much easier and faster to send a RFC to -mentors and let people scream out loud. And please note that I said QA side, with which I didn't mean to refer to the QA group, but to a variety of people who know what to look at and how to do it; not a random AM who happens to have already completed doing a review process successfully (which actually doesn't guarantee that the AM is competent enough, as the usual NM process consists on sending the templates and later reviewing the responses). You're very wrong here. The AM's job is to review if someone would be capable of being a good Debian Developer. Reviewing responses to the templates is *not* the main job. Have the prospective DD learn things; get the prospective DD think and search before answering; and reviewing actual tasks and skills by reviewing the prospective DD's packages next to possible other 'tasks' takes most of the time. It's not at all about a questionaire where you only have to tick the right answers because that would defeat the spirit of the process. For many applicants it takes a long time because they think it's just a questionaire... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Thu, 23 Oct 2008 15:12:01 -0200, Martín Ferrari wrote:
I have a problem with non-technical persons voting on technical
issues, or issues having technical implications for the developer
body. I have even more of a problem with non-technical persons leading
a technical project.
[..]
And what part of being a DPL can't be done by somebody who knows the
project, does hard work, and is respected but hates packaging stuff? I
can think of a couple of examples that could even win that election...
Ack.
The job of a DPL is not to write cool code or maintain fancy packages
but to -- well, lead the project.
And IMO that requires not so much technical skills but skills and
experience in communication, organization, dispute handling, change
management, and other social skills.
And as we can see every other day there's room for improvement in this
areas of soft skills in Debian in general ...
I am against this part of your proposal. Voting rights should be
coupled with proper understanding of the Project at large, including
the technical stuff, which is, after all, the base of this Project.
Understanding the project doesn't mean understanding dpkg, there are
things much more important, because, remember... above all we are a
group of people, [..]
Agreed, and I like that aspect in the new concept: that it puts the
most valuable resource of an all-volunteer project more into the
focus: the volunteers.
Acknowledging different ways and intensities of contributions and
having a clearer concept of paths through the project and
requirements for different stages can IMO raise the motivation of
both current and future contributors -- and thereby help Debian to
flourish as a whole.
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Rolling Stones: Sweetvirginia
signature.asc
Description: Digital signature
Re: Developer Status
Bas Wijnen wrote: On Wed, Oct 22, 2008 at 11:29:53PM -0300, Felipe Sateler wrote: Debian Contributor -- Basically, they need to pass the ID check, agree to the Social Contract/DFSG and have successfully answered a set of questions similar to the ones used in the current first PP step, to keep doing the same thing they have been doing all this time. No. Current Debian Maintainers also need an ID check, agree to SC/DFSG/DMUP and be advocated. The only thing that is added (and that was made clear by Joerg), is that they need to answer a very limited set of questions. I am talking about the DNDCs here. DNDCs have no priviledge whatsoever besides getting included in a list. So this basically requires Debian Maintainers to do the (somewhat reduced) PP and TS questions, and I don't see the real reason for this. The idea behind Debian Maintainers is to maintain a package one knows how to maintain. Those people are getting upload rights to the archive. Don't you think it's reasonable that the project wants people to show that they won't mess things up before giving such a priviledge to them? Becoming a Debian Maintainer is supposed to be a light-weight version of the New Maintainer process. It's not a I'll skip the New Maintainer process entirely-version. If the current Debian Maintainer process is failing for some reason, please elaborate. If it's not, then I don't see why adding more checks is useful. The only reason I can see here is that DDs are not being trusted in their advocations, which is a far worse problem that won't get solved by this. We have over 1000 members. That's way too much to use the if you have 1 invitation, you're in-system. Looking at the recent flamewar, I'm pretty sure almost every DM has at least one other DM whose advocation they don't trust. So I don't think one advocation is not enough is a problem at all. It's just a result of having many members. Don't forget that this is a quick thing. People who don't care enough to answer some quick questions (or show in some other way that they can handle the responsibility) aren't interested enough to get the priveledge we're talking about, IMO. Hmm, I see the point. However, remember that the current Debian Maintainer thing is intended for maintainership of few packages. As the original Debian Maintainer process was intended (someone gets a package sponsored, works with the sponsor for a few releases, and then the sponsor is confident the sponsoree won't screw up so flags the DM-Upload-Allowed: yes), I do think 1 invitation, you're in should work. If it is not working this way, then perhaps it doesn't. But I haven't heard anyone say that yet. - ensures that the interest in Debian isn't short-term. Why do people keep thinking this is a good thing? If people only have short-term interest, that's not a bad thing in itself. But in this case we're talking about giving them long-term priviledges (upload any package; vote; become DPL, that sort of thing). We want members of our project to have a long-term interest, don't you agree? Partially, depending on the definition of long-term. I do agree that voting and becoming DPL or other delegation should require long-term interest. But I think that for general upload rights the bar is way lower. As I said in another message, 1 year is enough to do a lot of work, but spending half of that year waiting is not useful, I think. - enables them to learn more about the workings in Debian and generally helps them for the next step. They should be doing this on their own, and not force an arbitrary limit on them. What if they did this before applying for DC/DM status? In the proposal, there is no help during these 6 months. So basically, if people want to do this on their own, the project will ask them to say so before doing that (in the proposal). Saying so means applying for DC status. Applying for DM is not possible before those 6 months are over. You seem to want to rush total outsiders into the most priviledged positions of the project. Why would that be a good thing? What is the problem of letting people work 6 months with slightly fewer rights? I don't want to rush people into privileged positions. I object arbitrary limits, specially when I think the limit will miss many important cases. While you might not intend that, it still does. DDMs would be DNDMs + general upload rights, which is clearly a DNDM DDM relationship. ... You say there is no first or second class, but DDMs would drop down to DNDMs. Of course there technically is a full and almost full rights membership. What I think he means to say, is that DNDMs should not be looked down upon, and that they do get everything they need from the project. That's why I said you might not intend that. If they are effectively almost-DDM, there is a large room for looking down. Personally, I think a DNDM should have
Re: Developer Status
On Thu, Oct 23, 2008 at 07:27:03PM +0200, Stefano Zacchiroli wrote: On Thu, Oct 23, 2008 at 09:59:09AM +0200, Bas Wijnen wrote: - Debian Developing Member (DDM) = what's called DD in the proposal. Given how rooted is the acronym DD in the Debian community, I doubt it is a good idea to change it or even to get rid of it. True, but the proposal splits the current DD in two types, namely DDM and DNDM. Currently DNDM doesn't exist, but people who aren't using upload rights because that's not what they're doing for Debian are also DD. So at least one of them is going to get a new name. It would be very nice to have a naming where DDM (or perhaps just DM) would still be DD, but I couldn't think of a scheme where that was possible while still showing the logic of the roles. Calling every member a developer just doesn't make sense. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html signature.asc Description: Digital signature
Re: Developer Status
On Thu, 23 Oct 2008 20:16:01 +0200, Stefano Zacchiroli wrote:
Debian Contributor
--
Debian Maintainer
-
Debian Member
-
Debian Developer
Now, regarding your proposal itself, I agree with others that it
sounds too bureaucratic, even for Debian.
Is it?
I agree, I fail to see what's bureaucratic about the proposal. After
all it's a simple 2x2 matrix with requirements for the 4 boxes.
I mean, the names looks clear to me.
I'm not really happy with the terms from Ganneffs proposal and like
Bas' ideas better; IMO they are more logical and acknowledge that
both packaging and other activities constitute membership; although
we should probably keep the DD somewhere to avoid total confusion.
In general I think iff procedures are changed we should take the
opportunity to also clean up the terms which are kind of a mess at
the moment IMO.
What I'm missing is a positive name for the non-packinging area; Bas'
developing vs. non-developing gives just a negative description
(people that don't maintain/upload packages), a positive term
describing what they actually do would recognize their work better
IMO. I didn't have any idea so far, which word would cover all these
activities.
And maybe we could make the search for terms easier if we found an
apposition for the first stage that can be prepended or appended to
the term in the second stage; something like junior or candidate
(no, I don't like both of these, just to give an idea).
Ok, here's a rather incomplete ASCII art, maybe it inspires someone
else:
/Area | Packaging | Other
Stage / | |
D Member | D Developer | D XY
D Contributor | Junior DD | Junior D XY
Are you maybe suggesting that alioth account creation should be bound
to being a debian contributor? I see more harm than good in something
like that ...
Ack, alioth accounts are great for new people when they join teams,
and that's most often before they think about becoming a $whatever.
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Konstantin Wecker Bettina Wegner: Stille ist's
signature.asc
Description: Digital signature
Re: Developer Status
On Thu, Oct 23, 2008 at 09:12:04PM +, gregor herrmann wrote: On Thu, 23 Oct 2008 20:16:01 +0200, Stefano Zacchiroli wrote: Debian Contributor -- Debian Maintainer - Debian Member - Debian Developer Now, regarding your proposal itself, I agree with others that it sounds too bureaucratic, even for Debian. Is it? I agree, I fail to see what's bureaucratic about the proposal. After all it's a simple 2x2 matrix with requirements for the 4 boxes. unbelievable -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9gTocubDLH.pgp Description: PGP signature
Re: Developer Status
Stefano Zacchiroli wrote: Can we please wrap part of this thread up by saying that: most of us---i.e., the participants to this thread---would BE OK with passing this proposal *with GR* (after the usual needed discussion time), whereas most of us would NOT BE OK with passing this proposal *without GR*? ACK. Personally, I probably wouldn't vote in favor of this proposal as it is but I would fully respect the outcome if it was decided by the means of a GR, obviously :) I also think that some of the underlying problems that this proposal tries to solve exist and the subject warrants further discussion. I haven't thought about it, but this is a very interesting observation indeed (same on the other on the alioth.d.o mail domain). Still, it is not clear to me how to merge the two proposals. I mean, while I see a partial overlapping among the two infrastructure, I really do not want to get away from alioth project admins the ability to decide upon which accounts are member of their projects. Are you maybe suggesting that alioth account creation should be bound to being a debian contributor? I see more harm than good in something like that ... Yes, I think that should be the case. The fact that with the current proposal this would do more harm than good (with which I perfectly agree) is exactly the reason I find it bureaucratic and overcomplicated. For example, there's nothing special about a DC. No upload rights, no vote rights, no debian.org logins. Just an entry to a 6-month quarantine period to be able to be promoted to a role with actual privileges. And, well, I find it /insulting/ to our current, real, contributors to require them to get an ID check (therefore meeting a DD in real life), go through NM FD, having an AM assigned and answer questions, just to call them what they are! My PoV is that we should *lower* the barrier for new contributors, value and *acknowledge* their contributions and accept them for what they are, (limited) members of the Debian project. I feel that Alioth has served this purpose in a way. This proposal achieves nothing to that effect; quite the opposite, IMHO. OTOH and on an unrelated but relevant to the proposal, I fully agree that we should give the rights to vote and be voted to non-maintainers (artists, translators, documentation writers etc.). e.g. making TS optional NM and tieing it to upload rights would be a simple way to do this but I haven't given any serious thought on this. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
