Re: RFC - Changing current policy of debian.net entries
Re: Stefano Zacchiroli 2012-06-25 20120625165835.gb20...@upsilon.cc Making this even clearer with a *.incubator.debian.org namespace might be a good idea. (Modulo some transition time, doing so will eventually replace *.debian.net, if I got that right.) - I've already discussed in a related thread of a few months ago how I think the current distinction between debian.net and debian.org should be documented, incidentally resolving other visibility problems of those services. Not that the dnsZoneEntry LDAP entry is publicly available, we should have an automated generated index of debian.net services, with pointers to the responsible DD. I think it'd be a good idea to have such index live at http://www.debian.net together with an explanation of the debian.net/.org distinction. I don't think *this part* of the confusion is enough to justify changes of the current scheme (but see below for another possible reason). I agree that debian.net and debian.org are a tad too similar such that an outsider can clearly see that the former is in incubation, but that's what we have at the moment, and I'd rather not replace it by something more ugly. Let's just document it more prominently. Maybe .debian.net owners should be encouraged to put a note on the website, or something like that. Generally speaking, every time we add an approval step I start to fear bottlenecks and the creation of new mighty powers; avoiding that is one of the key advantages of the current scheme. If the main problem .debian.net is very useful in that it enables DDs to get things done. Let's not put in more bureaucracy in front of it. is squatting, then I see two possible solutions: 1) be liberal by default, but empower someone to decide that a name is not acceptable. I think DSA would be a reasonable choice, as you already decide on *.debian.org, but I suspect DSA would not want to have this veto power (choice which I respect) Afaict there's no written rule that says don't put your private homepage there or similar. Actually should be useful for Debian should be enough of a rule. With that, someone can slap the offenders, e.g. DSA or DAM. 2) find some clear cut rule. One I've proposed in the past is that for any *.debian.org entry, the corresponding *.debian.net should not exist (or point to the debian.org ones, depending on the protocol). This one will still give some sort of veto power to DSA, but it will come with the factual justification of an existing homonymous service I've seen .debian.net used for testing .debian.org services, but that's mostly confusing to users. I wouldn't put in an official must not exist rule there, but an should not exist or redirect to debian.org makes sense. Btw, what would actually be an improvement would be shared debian.net entries, i.e. entries that anyone can edit. (Maybe that should even be the default.) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Debian training and code review
Re: Lars Wirzenius 2010-09-15 1284541176.2573.77.ca...@havelock This reminds me: it would be good to improve not just the quality of our packages, but our developers. Just a quick comment here: DM has improved the quality of people passing NM *a lot*. Historically, we (FD, DAM) have seen lots of applicants whose profile in the project was quite low - few packages maintained, few uploads, not involved in more general projects (qa, release etc.). I'm definitely not saying that these were bad developers, it was just more difficult to judge their involvement and contributions. Nowadays, we usually [1] ask DD applicants to become DM first. The typical NM now is maintaining packages in teams, doing infrastructure work (build-scripts for pkg-perl, ...), and is active in more than one packaging group or project. I don't think this extra step is filtering out people - those who would have applied for DD previously will still do, but at the point where they get an AM, they are well-prepared. At the same time, DM helps them to work independently from others at an earlier time. (Plus there's people that do not want to upgrade to DD and are happy with the new DM role.) Developing a Linux distribution involves a lot of skills, and stuff keeps changing all the time. It would perhaps be a good idea to have training sessions within Debian. [...] (+1 on that, the above comment wasn't meant to say this is a bad idea.) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: On terminology
Re: gregor herrmann 2010-07-05 20100705174124.gj4...@belanna.comodo.priv.at _If_ the membership stuff is changed; is anybody working on this issue currently? It's on top of the NM TODO list, together with the website rewrite. (Which is a precondition.) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: A team to grant rights on collab-maint?
Re: Enrico Zini 2010-06-15 20100615102602.ga11...@enricozini.org On Mon, Jun 14, 2010 at 12:45:32PM +0200, Raphael Hertzog wrote: Now I would like to stop dealing with those requests and thus I would like a team of people to replace me. Do you have a way to know what percentage of non-DDs who can commit to collab-maint are DMs? Why not automatically include all DMs in the collab-maint group? And to drive the idea further, what about a public-maint group that everyone with an alioth account can commit to? That sounds like an interesting experiment to see if random people generate good commits or tend to screw things up. (There's still someone who need to do the actual upload. I'd hope they do review changes.) If some people think that DMs (the public) screw up, they could still request a new debian-maint or dd-maint group that doesn't include them. If there's still too many legitimate (non-DM) requests to join collab-maint, that sounds rather like a problem with the definition of access than a executive body deciding on individual requests. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: A team to grant rights on collab-maint?
Re: Roland Mas 2010-06-15 87d3vs79yp@mirexpress.internal.placard.fr.eu.org And to drive the idea further, what about a public-maint group that everyone with an alioth account can commit to? I'm not sure I want that. Everyone with an alioth account (which you can get with no vetting besides an email check) would get a shell account with write permissions on a large amount of repositories. I meant shell account. To make access truely public would be a bit much, I guess. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: The role of debian-private
Re: Enrico Zini 2010-06-09 20100609140853.ga3...@enricozini.org So, some people are advocating in favour of a private mailing list for DD chatter. The fact that that idea is being very vocally pushed by no less than two people prompts me to double check some fundamental facts about the Debian project. I think the basic problem is that some threads live longer than their original subject and tend to degrade in chatter about random other topics. New mailinglists wouldn't solve that problem as the threshold for randomness is different for everyone, but some debian-offtopic list could make make sense. (I wouldn't join it.) Too few MUAs have a button for don't bother me about new mail in this (sub-)thread. Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: infrastructure team procedures proposal
Re: Josip Rodin 2008-03-22 [EMAIL PROTECTED] I've been composing a proposal regarding how Debian's infrastructure teams operate. It would be a good idea if the interested members of teams take a look at it and contribute their insight. The last version of the text is at: http://lists.debian.org/debian-project/2007/10/msg00142.html Isn't that overly generic and overly complicated at the same time? Which specific existing problem does it attempt to solve? (I.e. which problem do you expect to be easier to solve post-GR?) Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Bits from the New Maintainer Front-Desk
Debian New Maintainer Front-Desk [EMAIL PROTECTED] https://nm.debian.org/Christoph Berg November 25, 2007 http://www.debian.org/devel/join/ Hi, the New Maintainer Front-Desk would like to announce that Brian Nelson ([EMAIL PROTECTED]) has been removed from the team after a long period of inactivity. We would like to thank Brian for his engagement and his work on the New Maintainer process and the applications he handled as Application Manager. Christoph signature.asc Description: Digital signature
Updated Debian Maintainers Keyring
With the upload of debian-maintainers version 1.4, the following changes to the keyring have been made: dm:[EMAIL PROTECTED] Removed key: 190A8C7607743E3130603836A1183F8ED1028C8D A summary of all the changes in this upload follows. Debian distribution maintenance software, on behalf of, Christoph Berg [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 25 Nov 2007 16:59:13 +0100 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 1.4 Distribution: unstable Urgency: low Maintainer: Debian Maintainer Keyring Team [EMAIL PROTECTED] Changed-By: Christoph Berg [EMAIL PROTECTED] Description: debian-maintainers - GPG keys of Debian maintainers Closes: 452828 Changes: debian-maintainers (1.4) unstable; urgency=low . * Removed keyring admin Brian Nelson. Closes: #452828 * Removed keyring admin Michael Beattie. * Removed Debian maintainer Kartik Mistry. Files: a0c3dbd0f3f38e374a195322a7f9e1d2 1013 misc extra debian-maintainers_1.4.dsc 486c71631ea07110a365de09832a7ebb 247772 misc extra debian-maintainers_1.4.tar.gz 7230db6b6834933548a2325e892c0f0a 78212 misc extra debian-maintainers_1.4_all.deb daeb0f4eebd719fe4eb073991007f4a2 95870 raw-keyring - debian-maintainers_1.4_all.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHSZ5sxa93SlhRC1oRAioTAJ9TDqMV123MQ7iW5AZxPY1xPSUshgCgoZ43 GaT9+0Fzuaod7k17aQU+bwI= =Bk2y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Planet policy?
Re: Joerg Jaspert 2007-08-07 [EMAIL PROTECTED] Im not sure why this isnt yet integrated into Debian, afaik Myon tried to do that already with Mako, but I dont know why it didnt happen. CC-ing both, hoping we get that into official planet soon. :) I never got around to talk to Mako about that - I have had a look at the planetplanet source, but my python fu was/is not sufficient to produce a proper patch, so I went on to write the front-end in perl. The source is http://svn.df7cb.de/debian/planet/ . It would be nice to see it integrated. What do I have to do? :) Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Response to Position Statement to the Dunc-Tanc experiment
Re: Anthony Towns 2006-10-27 [EMAIL PROTECTED] Hi Anthony, thank you very much for the in-depth reply, that's what I had hoped for when signing in to the statement. I'd encourage people both pro- and anti- Dunc-Tank to consider the advice of http://www.donotfeedtheenergybeast.com/ and whether continuing to publicise and debate the topic actually aids your goals. The reason I'm a bit fed up of Debian at the moment is that the flamewars on the lists has risen to a level that it is really no fun anymore. I don't specifically blame dunc-tank for that - it's rather the general way things are handled. Perhaps it is really not possible to reach consenus in a 1000+ people project, but then we should think about ways how to overcome this. Maybe we can concentrate the discussions on that? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Improving the DAM-queue?
Re: Reinhard Tartler 2006-10-11 [EMAIL PROTECTED] From my observations, is seems that the only persons who can judge about these questions are the current DAMs (James and Joerg), and perhaps the DPL, since only they can approve new members of FD and DAM. (Given that I understand the current practice correctly). New DAM and FD members get appointed by the existing members of the respective group. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Security incident on Alioth and other Alioth news
Re: Raphael Hertzog 2006-09-06 [EMAIL PROTECTED] Alioth's web server was unavailable for most of the 5th of september. It was simply stopped because we discovered that some script kiddies were running an IRC proxy. After thorough investigation, we discovered that they exploited a pmwiki security hole[1] to deface some web pages, to install some malicious php pages which in turn were used to setup the IRC proxy. [...] On a related matter, we're preparing the move of Alioth to a new (and bigger) machine (called wagner.debian.org), and we'll make use of that opportunity to further strengthen the security measures as well as add more security checks. In that light, wouldn't it make sense to keep svn.debian.org separate from the highly exposed http://*.alioth.debian.org services? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: question:debian for new minimac intel?
Re: Pablo Rodrÿedguez Alonso 2006-05-17 [EMAIL PROTECTED] My name is Pablo Rodríguez and i´m a debian user in my intel pc. I reacently buy an apple minimac intel. I would like to know if there´s a debian version that i could install in my mac intel. If there´s not, I would like to know if in the future it would be a version. Doesn't the normal i386 installer work? Btw, you might have better luck asking on the debian-user list, this one is not meant for technical questions. Christoph signature.asc Description: Digital signature
Re: Proposal: The future of the Debian NM process
Re: cobaco (aka Bart Cornelis) 2006-05-16 [EMAIL PROTECTED] what's the rationale for needing a 2nd package? e.g. I currently maintain 1 small simple sponsered package, I also have contributed for several years as a translator. If we're introducing a new stage with upload rights for specific packages why shouldn't I be able to get upload rights for my 1 package? That's definitely a point to be discussed. I'm reluctant to give upload rights to people who haven't much experience yet, and the number of packages certainly limits experience in terms of problems you have encountered and mastered. If you've been maintaining a single package for some time, you should definitely be allowed to upload it, though there has to be a lower limit on the involement (like the mentioned 3 months). We should find some guidelines which measure that. Yes, that is a very greyish area. Christoph signature.asc Description: Digital signature
Re: Proposal: The future of the Debian NM process
Re: Jeremiah Foster 2006-05-16 [EMAIL PROTECTED] Limiting voting rights seems a step in the wrong direction. Doesn't debian want more enfranchisement rather that less? We don't limit anything here, the prospective DMs can't vote in the current system either. We can of course discuss on whether to give the DMs voting rights (and which), but at the moment I don't think they would get any. If you want to vote, you should be able to proceed to full DD membership quite easily. The intention is to create an intermediate role that people can get in easier/earlier that allows them to learn. The expectation is that some people will stay here if they are happy with uploading their packages. At the same time, the people applying for full DD are more experienced, and hence create less load on AMs. Most non-capable candidates will be filtered out in the DM checks. At the same time, people get (restricted) upload rights earlier, such that the following DD process does not delay them that much from working on their packages. Is there a way to reduce administration and bureaucracy rather than expand it? I am astonished at the backlog in the New Maintainer database, but maybe I am naive. We can't reduce bureaucracy by lessening the checks we do at the moment - there's just too many people trying to get in, and we want to maintain the qualification level the NM process has proven to produce so far. In my view, the problem is that many applicants apply to early (most often for legitimate reasons!), so that the AMs have a hard time to go with them through all NM stuff, which is no fun for either side. The hope is that by inserting an easy step inbetween, the NMs will benefit by the ability to upload and get involved more deeply earlier, and the AMs will benefit by getting (2nd-stage) applicants that have a more profound knowledge. Christoph signature.asc Description: Digital signature
Re: Proposal: The future of the Debian NM process
Re: Hubert Chan 2006-05-16 [EMAIL PROTECTED] 6. can use his gpg key to upload this package [2] - no account/@d.o address yet - every upload which would go to NEW needs a sponsor [3,4] I think it may be good to allow the sponsor to decide when the DM is allowed to make uploads without a sponsor when he/she is satisfied that the DM knows what he's doing with the package. e.g. simple packages may just need a single upload. More complicated packages (e.g. libraries, if the DM doesn't have previous experience packaging libraries) may need a bit more oversight by the sponsor before he/she is satisfied. Whether we activate that per maintainer or per maintainer-package combination is also something we have to discuss. (If we go into that direction at all.) [3] Do we allow existing sources with new binaries to go to new? (Library renames etc.) - has to be discussed We could leave this up to ftp-master. e.g. for a simple SONAME bump, they can accept the package. For more complicated package reorganizations, they can reject with a request for a sponsor. My idea was not to put any additional load on ftp-master and to have automatic rejects for that reason. If they have to decide what's wrong with a package, they could as well explain it themselves to the uploader, since it would take the sponsor the same time to figure it out. Oh, and a SONAME bump is a highly non-trivial thing, don't assume others maintain a whole bunch of libraries like you do :) Christoph signature.asc Description: Digital signature
Proposal: The future of the Debian NM process
Hi, these are my thoughts on how the NM process could look like in the future. The proposal has been inspired by Anthony Town's blog posting at [1], by my own experience in NM and being an AM, and finally by discussions with Marc Brockschmidt. [1] http://azure.humbug.org.au/~aj/blog/2006/04/12#2006-04-11-maintainers Let's summarize the current process first: 1. ITP, package created, sponsored 2. work on the package (bug fixing, new upstream releases) 3. (hopefully) more contribution like other packages, patches, other projects 4. advocate, NM application 5. wait for AM 6. NM process 7. wait for DAM There are some problems with that, mostly summarized by Marc in his d-d-a posting [2] and the following thread on -project, so I won't repeat them here. [2] http://lists.debian.org/debian-devel-announce/2006/04/msg6.html Here's my proposal: +- | Introduce an intermediate role Debian Maintainer (DM). | Summary: is allowed to upload packages already in the archive by himself. | Needs sponsoring for new packages, no vote rights. Can either proceed to | become DD or stay a DM. +- The intention is to create an intermediate role that people can get in easier/earlier that allows them to learn. The expectation is that some people will stay here if they are happy with uploading their packages. At the same time, the people applying for full DD are more experienced, and hence create less load on AMs. Most non-capable candidates will be filtered out in the DM checks. At the same time, people get (restricted) upload rights earlier, such that the following DD process does not delay them that much from working on their packages. The difference to Anthony's proposal is that I don't want to kill sponsoring. Sponsoring has worked quite well so far, as it includes both review by an experienced developer and gets people in touch with the project. Also, I want an application manager to handle the application and not just use a simple mail bot to make sure people have at least a basic knowledge. This DM process should be as light-weight as possible. The process I propose looks like: Stage 0: 1. ITP, package created, sponsored - same as before 2. contributes to Debian: - work on the package (bug fixing, new upstream releases) with sponsored uploads - 2nd package with 1 upload (e.g. not a totally trivial package, a rule of thumb could be like at least 6 uploads for all packages in total) - some other contributions (e.g. bugs on other packages) - the applicant should contribute for a minimum of 3 months before actually applying. Stage 1: 3. get an advocate, apply for DM 4. AM assigned (much faster (hopefully [1])) 5. DM process - ID check (DD signature) - light version of the classical NM templates should be only a few kB, 1 mail 6. can use his gpg key to upload this package [2] - no account/@d.o address yet - every upload which would go to NEW needs a sponsor [3,4] 7. continuous contribution, one or more of: - other packages - bug reports with patches - other projects - the intention here is that the DM has to show interest in the project beyond his own small set of packages before applying for DD - again minimum of 3 months Stage 2: 8. advocate [5], DD application 9. wait for AM (again, hopefully shorter) [6] 10. DD process - redesign of the DD process is a different topic 11. wait for DAM 12. may vote/upload/NMU/log in/whatever Discussion, notes: [1] that's why we are doing all this :) [2] new keyring (maintained by keyring-maint) that includes mapping keyid - maintainer address, katie only accepts uploads from that keyring when the maintainer address matches. [3] Do we allow existing sources with new binaries to go to new? (Library renames etc.) - has to be discussed [4] new source packages can probably be automatically enabled for a DM using the keyid - address mapping (alternatively, use a mail robot fed by the sponsor) [5] Do we require a different advocate? (Should be no problem at that stage, but is an additional burden.) [6] Require a different AM? Some random other notes: Names: Changing the term Debian Developer is impossible. The term Debian Maintainer says what the people will do, and sounds nice. The proposed term Debian Contributor and similar proposals sound too much like they do stuff, but that's not the real thing. dpkg: Should we introduce a new Signed-By (Built-By?) field in the .changes? (As by Anthony's observation that it's hard to see who sponsored which upload.) Thanks go to Marc Brockschmidt who provided feedback on this draft. If you are at DebConf, there will be 2 related BoFs: one at Friday morning where we will discuss current AM work to talk about experience and how we are handling stuff, and one at Friday noon where I want to discuss the NM process future (i.e. this proposal and other ideas). If you are an (D)AM, currently in NM, plan to apply, applied
Re: irc.debian.org
Re: Paul Johnson 2006-05-14 [EMAIL PROTECTED] Why does it necessarily have to be IRC? Jabber fixes a lot of IRC's shortcomings, without bringing along all the political drama and baggage OFTC, Freenode, and every other IRC network in existence. Switching to another IRC network just sets things up to repeat and have this discussion again in another few years. If you don't care about IRC, why don't you just let us choose the network we prefer? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Reforming the NM process
Re: Michael Banck 2006-04-12 [EMAIL PROTECTED] On Wed, Apr 12, 2006 at 01:25:28AM -0500, Manoj Srivastava wrote: Could you report such sponsors, so we may take their sponsorship privileges away? There's no technical way to do this (yet), as far as I can see. Iirc one developer had his upload rights restricted to his own packages before, because he did a series of harmful NMUs. I don't know the details, though. (This was probably hard-coded somewhere, so that's not a solution that should be applied very often.) Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Reforming the NM process
Re: Raphael Hertzog 2006-04-12 [EMAIL PROTECTED] - first require each appliacnt to document their contribution when registering on nm.debian.org. Then the FD checks if it's enough or not. If not, he's immediately put on hold and the applicant can come back a few months later (unless we have an AM who is willing to also play as trainer). In my feeling the web form makes it a bit too easy to apply, a mail-based system would require more interaction, and could at the same time include some I did the following stuff part. Maybe the current system should just be changed to send a mail to the applicant like it does sent to the prospective AM(s). 1.1.2 Application Managers ~~ The lack of free Application Managers that led to the accumulation of applicants waiting for an AM is mostly based on the fact that many developers don't care about the NM process, so only a few people are actually helping out. And also that you rarely ask for new AM on d-d-a and that the AM HOWTO is difficult to find and outdated. That's party because the front desk likes to get AMs by their own incentives. This should usually lead to AMs that are more interested in the process, and hence more active, than those that only reply to some d-d-a posting. I don't know what happen on nm-committee but for example I believe that general discussion between AM on how to improve the system can happen on [EMAIL PROTECTED] instead. (And Christoph Berg told me that such discussion have been going on nm-committee since that's where he discussed the possibility to use MIA scripts for NM) The discussion is happening on -newmaint (and -project and -devel and...). Contrarily to what I told you on IRC, nm-committee didn't have anything of it, though I expected it would be involved in drafting Marc's mail we are discussing here. 1.2.5 More than one AM per applicant On this topic, I would really like that we setup a centralized system which would not be mandatory but we that we strongly encourage to use. The best solution that I see is re-using a similar infrastructure than the one used by MIA. Christoph Berg was ready to implement it (as I am). As I said on IRC, I would be interested myself to have such a central place to store my NM communication. What I don't want is any tool that would be used to check if a particular AM is inactive, slacking, unresponsive etc. Every AM whom I've asked what he thought about a central mailstore said no thanks I like my privacy. At first I couldn't understand these reservations, but from reading the recent postings in this and the related threads, I do share them. AM bashing is the last thing that would help to improve the NM process, and even if not stated explicitely, the intention behind that MIA style DB seems (seemed?) to be the ability to check AM activity. I'd love to be proven wrong, but for now I'd rather spend my time on working with my current NMs (and the MIA stuff). Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Third call for votes for the debian project leader election 2006
Re: Manoj Srivastava 2006-04-06 [EMAIL PROTECTED] quote who=Steve Langasek date=Thu, Apr 06, 2006 at 02:30:46AM -0700 And maybe I'm too heavily steeped in Debian culture to take an objective view, but I don't see any reason why translators, documentation writers, artists, et al. should look at the term developer and conclude it's not for them. The term Developer has been used for many years in Debian, and efforts to change it are doomed to fail. No current (package- maintaining) developer will want to give that title away. What we can do, is to extend this title to all kinds of Debian (contributing) members, be it artists, lawyers, whatever. I'm very much in favor of doing this. First, none of these groups usually think of the work that they do as development. That's just not he way the word is used. But that'a semantic argument. The larger reason that this is a problem is because: (1) We as a project (and an NM project) are hesitant to give these people developership since it means they can upload to the project which introduces a set of potential risks and problems (one more account to compromise, etc). I agree that this is a problem. We have to make up our mind of who we want to accept as member (Developer). I'm willing to discuss that at Debconf, so if anyone else is interested in doing this, please tell me. I'm sorry. If we can't trust these people not to abuse upload privileges, then I certainly do not want to see them get a say in deciding how we conduct the project's business. Eiether we trust them, in which case we should induct them in as full members, or we don't, and in that case they do not get to vote. My fullest ack here. Half-memberships of all kinds doesn't help, and just insults people. Either we accept someone as a member and trust them to use their abilities to the best (i.e. they won't NMU glibc if they are an artist, and won't redesign the Debian logo if they are a kernel hacker), or we shouldn't accept them as member. This doesn't mean that every developer would have access to every corner of the project (like currently, not every DD is a member of the 'debadmin' unix group), but that there are no un-crossable borders (I'm a package DD, yet I could ask for access to the webwml group to start translating webpages). Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
About expulsion requests
Dear developers, I know that having codified expulsion procedures is tempting to use them, and I do think that they are a good thing to have. But please consider one thing when you think about invoking them: [1] Please use debian-private. [3] The reason is simply that expulsion is not a technical issue like requesting the expulsion of the sh port from the archive or whatever, but it concerns people. People have a life, and however bad they have been, they deserve the privacy that every civilized society guarantees its members - you wouldn't like your neighbor to post he has been forgetting to clean the stairway in a public newspaper even if it were true. It is not simply that Google friends will ever after find bits about the procedure and all the facts, dirt, and other things thrown there, but about the dignity we should always uphold. When the subject decides to make the process public, that's their decision, not yours. Thanks. Footnotes: [1] Rather the 2. Get support step from [2]. [2] http://lists.debian.org/debian-devel-announce/2005/08/msg5.html [3] Supporters have to be DDs anyway. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: About expulsion requests
Re: Lars Wirzenius 2006-03-16 [EMAIL PROTECTED] I disagree. Posting things to -private does not really keep them secret or confidential, but it does generate a lot of rumors. Rumors are usually worse than the real thing. Therefore, in my honest opinion, it's better to keep things in the open, even for the subject of an expulsion request. I for myself would very much prefer the rumors, and maybe even publically spreading (leaking?) the word on irc than to deliver the expulsion request directly to every lurking slashdot/heise/whatever writer on earth. There is a difference. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Neuer User deutscher Sprache
Re: Ulrich Müller in [EMAIL PROTECTED] Ein paar einfache Fragen an euch: debian-user-german@lists.debian.org ist die richtige Liste für solche Fragen. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: DEBIAN OBSOLETE RELEASE
Re: [EMAIL PROTECTED] in [EMAIL PROTECTED] The question is : are Security updates created for the 3.0 release ? Yes. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Debian Pure Project
Re: Robert Tolu in [EMAIL PROTECTED] My name is Robert Tolu and I currently lead a project known as Debian Pure (www.debianpure.com). [from the website] | However, installing a Debian desktop is not new-user friendly. Have you considered joining the debian-installer team? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: How to be debian developer
Re: Rapid Sun in [EMAIL PROTECTED] Last month, i have attended Debian Mini Conference in Beijing. The project manager, Mr. Martin, mentioned about helping Debian. Cambodia is new to Open Source. I am very interesting in this and some of my students want to be debian developer. There are many ways to get involved: go to the #debian channels on IRC, fix some bugs on bugs.debian.org, find a nice package to adopt (see the wnpp bugs) or package a new one, etc... This is all summarized at http://www.debian.org/devel/join/, which also has pointers to all kinds of documentation. The baseline is: you don't ask for participating, you just do it by getting involded in the areas you are interested in. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: linuxmag
Re: Lars Jørgensen in [EMAIL PROTECTED] Sorry this was the wrong place to paste this i did send this mail to the wrong adress im so sorry! I did copy the wrong mail adress on your officiel site im am so sorry!. Again i am really sorry i hope you would take my sorry - SORRY! :( Could you please additionally stop being sorry? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: About new release
Re: Jesús Delicado Martínez in [EMAIL PROTECTED] The last release of Debian is 3.0r1 in the Fist Feet, but in last news, on 21th November, there is another release stable, the release 3.0r2. So, what is the last stable release? The last stable release is 3.0r2, as announced here: http://www.debian.org/News/2003/20031121a The fact that the Debian web pages are not as up-to-date as usual is due to a recent breakin in project machines: http://www.debian.org/News/2003/20031121 Christoph -- Christoph Berg [EMAIL PROTECTED], http://www.df7cb.de/ Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944 signature.asc Description: Digital signature
Re: About Debian
Re: About Debian [Aashraful Aashique [EMAIL PROTECTED], Sat, Sep 13, 2003 at 03:34:50AM -0700, [EMAIL PROTECTED]] I am interested about Debian Linux.So if possible please send me the Debian CD. Hello, thank you for your interest in Debian. Information on how to obtain Debian can be found at the Debian web site at http://www.debian.org/distrib/ Christoph -- Christoph Berg [EMAIL PROTECTED], http://www.df7cb.de Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944 pgpKihtkehlHA.pgp Description: PGP signature
