Re: Code of Conduct violations handling process
On Wed, Sep 03 2014, Piotr Ożarowski wrote: [Scott Kitterman, 2014-09-03] We could have an on stage censor with a switch for the microphone. I am disappointed; the response could have been so much more cpnstructive. yeah, lets do censorship. I lived in a country with censorship¹, we didn't have people swearing and nobody dared to say something which is not politically correct, at least in public. Grat times! Is your position then that condes of conduct and enforcing harassment policies are a form of censorship? (I am congnizent that you have not stated this, and harassment was not part of this discussion, but I do believe it is related) and more seriously, the day Debian will do censorship is the day I retire from the project. How do you suppose we keep the atmosphere from devolving back to the poisonous flame-fest days, and enforce various codes of conduct policies? I have seen far too many tech conferences without codes of conduct devolve into misogynistic and occasionally racist experiences. The argument that codes of conduct are forms of censorship is frequently made, but, I am afraid, not very convincingly. manoj -- Good news from afar can bring you a welcome visitor. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Code of Conduct violations handling process
On Wed, Sep 03 2014, Piotr Ożarowski wrote: [Manoj Srivastava, 2014-09-03] Is your position then that condes of conduct and enforcing harassment policies are a form of censorship? (I am congnizent that you no, if I'd think that, I'd retire already, no? I am glad to hear that. and more seriously, the day Debian will do censorship is the day I retire from the project. How do you suppose we keep the atmosphere from devolving back to the poisonous flame-fest days, and enforce various codes of conduct policies? I have seen far too many tech conferences without codes of conduct devolve into misogynistic and occasionally racist experiences. The argument that codes of conduct are forms of censorship is frequently made, but, I am afraid, not very convincingly. my point is some people react out of proportion (and that's why I did as well, didn't you notice at least a bit of sarcasm in my mail?). I could not be sure. Feeling and emotional nuances are hard to convey in email,and I certainly struggle with correctly judging peoples intent if they are at odds with what is expressed in writing. So, if there was a speaker guideline in play, and if the delegates determine that that was violated, I shall be disappointed if nothing was done due to the stature of the speaker. Some people want(ed) to codify in CoC other political correctness things that I don't agree with. I like our current CoC and I don't want to change it. Respect for others seems to be a part of our CoC, no? manoj -- The trouble with eating Italian food is that five or six days later you're hungry again. -- George Miller Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Code of Conduct violations handling process
On Wed, Sep 03 2014, Scott Kitterman wrote: As far as I can tell, he spoke the truth as he knows it. I have no idea if he's right or wrong, but he was stating his perspective and we ought to be open to that. While he could have phrased it better, I don't think the CoC protects people from having to hear opinions relevant to the project that they disagree with or make then feel bad because they are being accused of bad behavior. Often the difference between expressing an opinion in an acceptable manner and expressing it unacceptably is indeed how one phrases it, so the devil lies in the details Having said that, I have just rewatched the talk, and I personally was not offended. I do think calling people bigots is rude, and in a way attacks their expression of their closely held opinions -- which is exactly what people here seem to want to defend. People associated with the FSF or those who feel i sympathy with them feel offended, I find it somewhat disappointing that we care so little about people being offensive, given the progress we have made. manoj -- Civilization is the progress toward a society of privacy. Howard Roark, in Ayn Rand's _The Fountainhead_ Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: [Debconf-discuss] Code of Conduct violations handling process
On Wed, Sep 03 2014, Steve Langasek wrote: The stated purpose of the CoC is to ensure that our conference is a safe space for all members of the Debian community. In what way would a change in approach to dealing with a violation after the fact, where the offender is no longer at the conference, further that goal? Perhaps to set the tone for future conferences, and to emphasize that we actually do try to act on violations of the bits about respect and making attendeea feel welcome (unless we think we are a community where being called crazy bigotted peple amounts to welcoming speech) manoj -- When more and more people are thrown out of work, unemployment results. Calvin Coolidge Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Code of Conduct violations handling process
On Wed, Sep 03 2014, Steve Langasek wrote: On Wed, Sep 03, 2014 at 09:52:44AM -0700, Manoj Srivastava wrote: People associated with the FSF or those who feel i sympathy with them feel offended, I find it somewhat disappointing that we care so little about people being offensive, given the progress we have made. This thread is not about whether we care about people being offensive (which, btw, is terribly subjective). This thread is about whether the CoC should be used to enforce people *not* being offensive. And that is a very slippery slope with no bottom in sight. Then we should strip language out of the CoC about being respectful to people and making attendees feel welcome, to avoid giving a false impression that those things are actually important and shall be enforced. manoj -- Hlade's Law: If you have a difficult task, give it to a lazy person -- they will find an easier way to do it. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Code of Conduct violations handling process
On Thu, Sep 04 2014, Christian Kastner wrote: On 2014-09-04 01:34, Manoj Srivastava wrote: On Wed, Sep 03 2014, Steve Langasek wrote: On Wed, Sep 03, 2014 at 09:52:44AM -0700, Manoj Srivastava wrote: People associated with the FSF or those who feel i sympathy with them feel offended, I find it somewhat disappointing that we care so little about people being offensive, given the progress we have made. This thread is not about whether we care about people being offensive (which, btw, is terribly subjective). This thread is about whether the CoC should be used to enforce people *not* being offensive. And that is a very slippery slope with no bottom in sight. Then we should strip language out of the CoC about being respectful to people and making attendees feel welcome, to avoid giving a false impression that those things are actually important and shall be enforced. This hyperbole is not productive; neither is the hyperbole on the other side of this discussion (mostly when this thread started). Err. It is not meant to be hyperbole. But nice try being dismissive. Kudos. The CoC talks about: *) All attendees are expected to treat all people and facilities with respect and help create a welcoming environment. *) We ask all our members, speakers, volunteers, attendees and guests to adopt these principles. *) Sometimes this means we need to work harder to ensure we're creating an environment of trust and respect where all who come to participate feel comfortable and included. *) Respect yourself, and respect others. Be courteous to those around you. *) We ask everyone to be aware that we will not tolerate intimidation, harassment, or any abusive, discriminatory or derogatory behavior by anyone at any Debian event or in related online media. If we are not going to enforce these principles, for they are slippery slopes, we should indeed take them out of the CoC, so as to not misrepresent the nature of the experience people might have. It might make a difference to people as to what kind of CoC exosts (some scince fiction authors have stated on blogs that they shall not attent conferences without a CoC, so it is not unforseeable that people might make decisions based on the CoC. We should not have things in the CoC we have no intention of enforcing, slippery slope or otherwise.) manoj -- A man paints with his brains and not with his hands. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: devotee predictable random numbers
On Thu, Jun 07 2012, Touko Korpela wrote: On Thu, Jun 07, 2012 at 12:00:19AM -0700, Manoj Srivastava wrote: Once I get my act together again, I have devotee v 2.0 that I think is generally useful enough to package, since I have moved it to a command pattern based workflow, and thus people may add modules (check gpg sigs) or remove tham (no ldap checks), and move the action noides around at will (do gpg checks _after_ ldap checks) Is predictable RNG allows recovery of secret monikers (CVE-2012-2387) fixed now in devotee? https://lists.debian.org/debian-devel/2012/04/msg00528.html http://www.openwall.com/lists/oss-security/2012/05/22/11 Interesting thread. No, this has not yet been fixed in devotee. I'll patch v2.0. manoj -- The documentation is in Japanese. Good luck. Rich $alz Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uljurj7@glaurung.internal.golden-gryphon.com
Re: General Resolution: Diversity statement results
On Wed, Jun 06 2012, Stefano Zacchiroli wrote: On Wed, Jun 06, 2012 at 03:24:37PM +0100, Ian Jackson wrote: The voters' preferences are a bit annoying to grep for etc. because they aren't normalised. So I wrote the script below, just now. If someone would like to include it in some package with a suitable name, and perhaps give it a manpage, please do so. Alternatively feel free to just take it of course. Rather than having a separate utility to do so packaged, I'd rather prefer to have devotee output normalized tally sheets. Doing so seems compatible with the transparency principle of Debian public votes. The existence of obscured votes due to the lack of normalization seems to be nothing more than a bug in how we present results. Did you consider turning your script into a devotee patch? devotee is written in Perl too, so it's potentially not to hard to just plug your script in as a patch. Thanks for your script (and for considering the patch idea)! Cheers. I'll be happy to add a normalization filter while publishing a cooked tally sheet. I would still prefer to keep the raw tally sheet around on the grounds of using a tally sheet minimal changes to how the voter actually voted (minimal changes, and because the current system kinda works). Once I get my act together again, I have devotee v 2.0 that I think is generally useful enough to package, since I have moved it to a command pattern based workflow, and thus people may add modules (check gpg sigs) or remove tham (no ldap checks), and move the action noides around at will (do gpg checks _after_ ldap checks) manoj -- If I do not return to the pulpit this weekend, millions of people will go to hell.-- Jimmy Swaggart, 5/20/88 Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C pgp4RAQELkv1W.pgp Description: PGP signature
Re: DEP5: Making Files: * non-optional
On Mon, Sep 13 2010, Lars Wirzenius wrote: The current DEP5 draft says: * **`Files`** * Required for all but the first paragraph. If omitted from the first paragraph, this is equivalent to a value of '*'. * Syntax: white space separated list * List of patterns indicating files covered by the license and copyright specified in this paragraph. See File patterns below. Does anyone oppose if I remove the If omitted... sentence? I see no reason to make the format unnecessarily complicated by having it optional. In other words, I propose to make the Files: field mandatory in all paragraphs except the first (header) one, where it is not allowed at all. Currently, one only needs to list the copyrights in the package, without specifying which file each copyright applies to. How is that specified in DEP5 format? Implying that all copyright notices apply to all files would be an untruth. I would suggest that a missing files: field in the headers implies that no statement is being made about which files the copyright notice applies to, instead f implying it applies to all files. manoj -- A little inaccuracy saves a world of explanation. C.E. Ayres Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk1dprbt@anzu.internal.golden-gryphon.com
Re: DEP5: Making Files: * non-optional
On Mon, Sep 13 2010, Lars Wirzenius wrote: The current DEP5 draft says: * **`Files`** * Required for all but the first paragraph. If omitted from the first paragraph, this is equivalent to a value of '*'. * Syntax: white space separated list * List of patterns indicating files covered by the license and copyright specified in this paragraph. See File patterns below. Does anyone oppose if I remove the If omitted... sentence? I see no reason to make the format unnecessarily complicated by having it optional. In other words, I propose to make the Files: field mandatory in all paragraphs except the first (header) one, where it is not allowed at all. Currently, one only needs to list the copyrights in the package, without specifying which file each copyright applies to. How is that specified in DEP5 format? Implying that all copyright notices apply to all files would be an untruth. (Or are we expanding the requirements for copyright files to map copyright notices to files in the source package?) I would suggest that a missing files: field in the headers implies that no statement is being made about which files the copyright notice applies to, instead f implying it applies to all files. manoj -- Though I'll admit readability suffers slightly... --Larry Wall in 2...@jato.jpl.nasa.gov Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87occ1pr09@anzu.internal.golden-gryphon.com
Re: DEP5: Making Files: * non-optional
On Mon, Sep 13 2010, Lars Wirzenius wrote: On ma, 2010-09-13 at 09:06 -0700, Manoj Srivastava wrote: Currently, one only needs to list the copyrights in the package, without specifying which file each copyright applies to. How is that specified in DEP5 format? Implying that all copyright notices apply to all files would be an untruth. (Or are we expanding the requirements for copyright files to map copyright notices to files in the source package?) There is a consensus, as far as I can see, to allow the first (header) paragraph to have Copyright and License fields that will apply to the package as a whole, rather than to each file. This is an upcoming change that is in the pipeline (but I don't want to make all changes at once). As far as I know, I don't have a single package for which a copyright field applies 6to all files in the source package (I might have missed one, but I think not). I don't think I have a copyright notice that applies to a package as a whole, but I am not a lawyer. If a source package is an aggregated work, with bits of the package coming from different sources and authors, not all copyright notices apply to the whole package. In such a case, how can I not have, umm, the first paragraph? :-) I would suggest that a missing files: field in the headers implies that no statement is being made about which files the copyright notice applies to, instead f implying it applies to all files. On the other hand, this means a paragraph where the Files field is missing by mistake will be interpreted wrongly. I find putting the information in the header paragraph to be cleaner, but I admit it is a subtle point. It's better to be explicit when possible, to allow errors to be noticed easier. Can we explicitly specify a way of saying that we wish to make no statement mapping a copyright or license field to any file? Say, by saying File: UNSPECIFIED or something? manoj -- Quantity is no substitute for quality, but its the only one we've got. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbhtp5xc@anzu.internal.golden-gryphon.com
Re: DEP5: Making Files: * non-optional
On Mon, Sep 13 2010, Jonas Smedegaard wrote: On Mon, Sep 13, 2010 at 08:59:34AM -0700, Manoj Srivastava wrote: On Mon, Sep 13 2010, Lars Wirzenius wrote: The current DEP5 draft says: * **`Files`** * Required for all but the first paragraph. If omitted from the first paragraph, this is equivalent to a value of '*'. * Syntax: white space separated list * List of patterns indicating files covered by the license and copyright specified in this paragraph. See File patterns below. Does anyone oppose if I remove the If omitted... sentence? I see no reason to make the format unnecessarily complicated by having it optional. In other words, I propose to make the Files: field mandatory in all paragraphs except the first (header) one, where it is not allowed at all. Currently, one only needs to list the copyrights in the package, without specifying which file each copyright applies to. How is that specified in DEP5 format? Implying that all copyright notices apply to all files would be an untruth. Is this question any different from what I responded to on August 13th? The question is not very different, but then, as now, the anser raised some concerns about spreading misinformation. Here is, I believe, an example of what you ask for: Copyright: 2009, John Doe License: GPL-2 Verbatim license from source bla bla with reference to common-licenses With Lars' proposal (and allowed now too, but not mandated) it would look like this: Files: * Copyright: 2009, John Doe License: GPL-2 Verbatim license from source bla bla with reference to common-licenses And if this copyright notice does not apply to all files, I think this is an incorrect statement. I would prefer that the format we are creating does not force me to incorrectly imply that the copyright notice applies to all files in the package. I would suggest that a missing files: field in the headers implies that no statement is being made about which files the copyright notice applies to, instead f implying it applies to all files. Hmm. Interesting indeed! Yes, this is actually one thing that I silently found relief in when the ability to drop the Files: * line for first (non-header) section was introduced: Until then I felt slightly awkward about stating that _all_ files had a certain license, when in fact I knew for sure that only some of them explicitly stated copyright and licensing. Or when I know for sure some files specified a *different* copyright notice, but I do not want to keep track of which files these were, and keep the list updated. manoj -- Aren't you glad you're not getting all the government you pay for now? Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwxdp5x9@anzu.internal.golden-gryphon.com
Re: DEP5: Making Files: * non-optional
On Mon, Sep 13 2010, Russ Allbery wrote: Manoj Srivastava sriva...@ieee.org writes: On Mon, Sep 13 2010, Lars Wirzenius wrote: As far as I know, I don't have a single package for which a copyright field applies 6to all files in the source package (I might have missed one, but I think not). I don't think I have a copyright notice that applies to a package as a whole, but I am not a lawyer. If a source package is an aggregated work, with bits of the package coming from different sources and authors, not all copyright notices apply to the whole package. In such a case, how can I not have, umm, the first paragraph? :-) This is similar to the issue that prompted the discussion that Lars is referring to. I believe that once that change is made, you can achieve your goal by having a debian/copyright file with only one paragraph, with License and Copyright fields in that paragraph. That will present license and copyright information about the entire package without making any statements about specific files. If you want to add subsequent paragraphs about specific files, you can also do that. As long as you have no Files: * paragraph, this should have the semantics you desire. Ah, of course (smacks forehead). Yes, that indeed does address my issues, I was just slow seeing it. Sorry for the noise. manoj -- The ends justify the means. after Matthew Prior Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bp81ouwi@anzu.internal.golden-gryphon.com
Re: DEP-5: general file syntax
On Sat, Aug 21 2010, Russ Allbery wrote: Ben Finney ben+deb...@benfinney.id.au writes: Lars Wirzenius l...@liw.fi writes: * Have one copyright statement per Copyright field, and have multiple instances of the field. This is my preference, and what I've been doing in my packages. Unfortunately, this creates real challenges for parsers. I've written a few RFC 5322 parsers, particularly for Usenet, and allowing repetition of headers always causes headaches in representation. You end up having to add another layer of data structure, with corresponding changes to everything that consumes information from the parser, if you don't want to throw away information. It's also a divergence from the Debian control file format, which allows only one instance of a field per stanza, probably for much the same reason. If I recall correctly, 2822 allows for header field folding: --8---cut here---start-8--- 2.2. Header Fields Header fields are lines composed of a field name, followed by a colon (:), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. A field body may be composed of any US-ASCII characters, except for CR and LF. However, a field body may contain CRLF when used in header folding and unfolding as described in section 2.2.3. All field bodies MUST conform to the syntax described in sections 3 and 4 of this standard. 2.2.3. Long Header Fields Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called folding. The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: Subject: This is a test can be represented as: Subject: This is a test Note: Though structured field bodies are defined in such a way that folding can take place between many of the lexical tokens (and even within some of the lexical tokens), folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere. The process of moving from this folded multiple-line representation of a header field to its single line representation is called unfolding. Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. --8---cut here---end---8--- Can't we just fold long copyright header fields similarly? manoj -- Houston, Tranquillity Base here. The Eagle has landed. Neil Armstrong Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v9rz02a@anzu.internal.golden-gryphon.com
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13 2010, Mark Brown wrote: On Thu, Aug 12, 2010 at 05:10:11PM -0700, Don Armstrong wrote: On Fri, 13 Aug 2010, Craig Small wrote: What are these benefits? The major important bits are that people who are basing distributions on Debian or are using Debian in the enterprise or embedded environments can more easily determine the set of licences that they need to audit for compliance purposes and due dilligence. Debian will also know better what licences we are distributing in main, and can possibly track issues where we are unable to ship specific derivative works. In order to truly deliver on this we'd need the entire distro to be converted to DEP5 format but elsewhere in the thread it was stated that this is not a goal. Also, this goal only requires one to list the licenses under which the package sources are delivered, but need not say anything about which _files_ are under which license (and currently, there is no requirement to list any source files in copyright either, so listing the files is an additional requirement). manoj -- Executive ability is deciding quickly and getting somebody else to do the work. John G. Pollard Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxsqmux5@anzu.internal.golden-gryphon.com
Re: DEP-5 meta: New co-driver; current issues
On Thu, Aug 12 2010, Lars Wirzenius wrote: On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote: On 08/12/2010 02:45 PM, Lars Wirzenius wrote: - Migrating all packages to the new format is an insane task which would take a *long* time and a lot of work. There is no goal to migrate all packages. That's a strawman. I found that surprising; perhaps I have forgotten a lot about this proposal. So, if I understand this correctly, this proposal is to come up with some way of creating a standard format for copyrights that is not meant to be universal (since lacunae that make it unusable for some packages are not going to be addressed), and not all packages will ever have a machine readable copyright? I had hoped that we would try for a format simple enough to be generally usable (just a header Type: GPL; Subtype: V3) would address a lot of use cases without being onerous and much more detailed than what is required now. Do we know what use cases we are trying to address? Just having a machine parseable list of licenses per package (perhaps with known tags for popular licenses, and other) seems to be far more simply addressed than the complex schema I seem to recall being bandied about. manoj -- The 80's -- when you can't tell hairstyles from chemotherapy. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871va3o8wh@anzu.internal.golden-gryphon.com
Re: Question in respect to GNU/Lnux affiliation
On Sun, Mar 14 2010, Russ Allbery wrote: The Hickeys hick...@nbnet.nb.ca writes: How come the GNU/Linux site does not have Debian on its free distribution list, and makes no mention of Debian at all it seems? Is this because Debian does not adhere to the GNU/Linux Free Software Definition? There have been a variety of different reasons over the years, but the primary ones, the ones that are unlikely to change, and the reasons why the Debian listing was removed in the first place as I understand it are: * Debian supports the non-free archive section even though it isn't part of Debian proper and provides information about it and links to it. * Debian does not follow the level of discipline that the FSF wants to follow about never linking to non-free software or non-free software companies. The project promotes such software in some ways by the criteria used by the FSF. Also, the project has decided that the FSF promotes software which is non-free (mostly software that happens to be documentation) and treats it as such. So, fro Debian's perspective, the FSF want s Debian to execie such discipline in a selective manner (the selection happening by Debian ignoring it's own definitions, and hewing to the FSF's definitions). manoj -- Paul Revere was a tattle-tale. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fx42w87q@anzu.internal.golden-gryphon.com
Re: squeeze release cycle?
On Mon, Nov 09 2009, Raphael Hertzog wrote: On Mon, 09 Nov 2009, Russ Allbery wrote: So, there was a long discussion here after Debconf about the merits or lack thereof of a freeze date at the end of this year for a squeeze release early next year. My general feeling of the discussion was that there was a fair bit of opposition to freezing and releasing so quickly after lenny, but since that's also my personal opinion, I may be misreading the discussion. Either way, where I think we left that discussion was with a statement that no decision had been made and the release team and others were going to think about this and provide more information later. Indeed, we lack a clear vision again. madduck's email on -release have also been unanswered: http://lists.debian.org/debian-release/2009/10/msg00239.html http://lists.debian.org/debian-release/2009/11/msg00022.html Luk proposed a new freeze date of march 2010: http://lists.debian.org/debian-devel-announce/2009/10/msg2.html But indeed it's only a proposal at this point. The release team needs to set a date in stone now. Back in the bad old days, we paid a lot of attention to one aspect of the release attributes: Quality, as measured by release critical bugs. That gave to nice aphorisms like release when ready, but did not really cater to timeliness of the releases. We should take care not to let the pendulum swing too far the other way: Where timeliness trumps the quality. We also have release goals; which implies that the release team likely to be looking at other things than just dates: A) Is the current testing release close to being release quality? It does not need to be perfect, but freezing with a large number of release critical bugs either makes for a long freeze, or a reduction in quality of implementation as we ignore otherwise RC bugs. I recall freeze/release times being linked to RC bug thresholds, and while I am not advocating a tight coupling, a total de-coupling does not seem advisable either. B) Are the current release goals on track to being met? Would a little bit of slack time help, as long as it is not too much? manoj -- QOTD: Some people have one of those days. I've had one of those lives. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Distributing software written by hostile upstream developers
On Thu, Sep 17 2009, Steve McIntyre wrote: On Thu, Sep 10, 2009 at 09:47:10AM -0500, Manoj Srivastava wrote: On Thu, Sep 10 2009, Steve McIntyre wrote: Well, what happens if somebody wants to maintain software where there is a strong set of opinion that we don't want it? In this case, I'd like to delegate the power to the ftpmasters to say so and reject from NEW etc. If we have a clear consensus that that would be OK then fine; otherwise I'd like to run this through the GR process to make sure the project as a whole agrees. It could be controversial, which is why I'm bringing this up now rather than via an argument after-the-fact... I would like to see more on how the ftpmasters (a small group of overworked people already tasked with too much) will be able to determine that there is a strong set of opinions that we do not want it (as opposed to a small vocal minority that vehemently opposes something -- we have had people violently opposed to things like HAL and udev)? Before we chose to override a DD's decision about their own package, there ought to be an objective criteria for that override, in my opinion. Sure, that sounds reasonable. What would you suggest as objective criteria? Well, given that this is all about personal opinions, the only objective criteria I can come up with is a measure of the popularity of sentiment against the package. We could attempt to measuer both, by a devotee straw-poll, for example. - [ ] I advocate the package - [ ] Dislike the package, but not enough to prevent it in Debian - [ ] Dislike the package, encourage the developer not to package it - [ ] Dislike the package, prevent it from entering the archive And then set up a criteria that the number of people opposing - + 0.25 * number of people deprecating it number of people advocating it some threshold in terms of Q. By setting up the criteria for the strength of opposition upfront, we preclude arguments about bias against a specific individual from clouding the issue. However, I am not part of the group you have evidently discussed this with, and am no aware of the rationale and motivation that might have surfaced in those discussions, so there might be aspects of desirable criteria I might have missed; feel free to expand on this. manoj -- Do not worry about which side your bread is buttered on: you eat BOTH sides. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Distributing software written by hostile upstream developers
On Thu, Sep 10 2009, Steve McIntyre wrote: On Thu, Sep 10, 2009 at 11:00:53AM +0200, Petter Reinholdtsen wrote: If someone really want to maintain such package, we should not prohibit it, but we should make it clear that it is strongly recommended to not maintain such package, and that the advantage of the software should be weighted against the problems it causes for the Debian community. Perhaps we should also suggest that one start working on alternatives for packages with hostile upstream, instead of spending time on social interactions with upstream. :) Well, what happens if somebody wants to maintain software where there is a strong set of opinion that we don't want it? In this case, I'd like to delegate the power to the ftpmasters to say so and reject from NEW etc. If we have a clear consensus that that would be OK then fine; otherwise I'd like to run this through the GR process to make sure the project as a whole agrees. It could be controversial, which is why I'm bringing this up now rather than via an argument after-the-fact... I would like to see more on how the ftpmasters (a small group of overworked people already tasked with too much) will be able to determine that there is a strong set of opinions that we do not want it (as opposed to a small vocal minority that vehemently opposes something -- we have had people violently opposed to things like HAL and udev)? Before we chose to override a DD's decision about their own package, there ought to be an objective criteria for that override, in my opinion. manoj -- Q: What's yellow, and equivalent to the Axiom of Choice? A: Zorn's Lemon. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
On Wed, Aug 19 2009, Josselin Mouette wrote: Le mardi 18 août 2009 à 19:10 -0500, Manoj Srivastava a écrit : I would say it is attacking the character or motives of a person who has stated an idea, rather than the idea itself. You can’t de-humanize a discussion to the point of considering what has been written without considering who wrote it. Sure. You might think the other guy is an asshole. You do not have to interject that into the discussion. Isn't that what this discussion is about? manoj -- Bolub's Fourth Law of Computerdom: Project teams detest weekly progress reporting because it so vividly manifests their lack of progress. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
On Wed, Aug 19 2009, Bernhard R. Link wrote: * Manoj Srivastava sriva...@debian.org [090818 22:42]: On Tue, Aug 18 2009, Bernhard R. Link wrote: * Ben Finney ben+deb...@benfinney.id.au [090818 11:28]: Perhaps you have a better way of succinct terms to use when challenging those logical fallacies? I think succinct terms help not at all here. Once there is a succinct term 90% of their use is name-calling. If people think something is wrong they should say what is wrong and not invoce some name. If you want a full description of the logical fallacy in all replies, sure. The point is that the best refutation of a logical fallacy is to point out it is a logical fallacy, and thus, stop basing the rest of the discussion based on the logical fallacy. I'd prefer if on-topic would not be about who did wrong, but stay at the facts. So, if someone went off-topic and introduced strawman arguments, or went and attacked a person, or said that some argument should be discredited because of some character traits of another person, this should not be even pointed out because pointing out these things is off topic? Would this not encourage such behaviour? and let such arguments lie unchallenged in the archive? All those fallacies are easy enough that if they are really done, one can name the arguments (like noting that some arguments uttered are indeed arguments against what the person things was the topic at hand. But not against what was suggested/meant, because of...) or the lack thereof (I fail to see why we cannot implement it only because the one suggesting has a bad character in your eyes). Sure. Just dropping names of logical fallacies without justifying why they fit a post in question. I have no argument with this. These attacks on people, as opposed to discussion of what they said, is one of the major reasons discussion threads devolve into unproductive chaos. We should be managing to police discussion better, and the first step is identifying that such a post has been made. My point is that if something like that is done, it should be done on another list. So that the discussion itself can continue and the meta- question at hand can be solved (Was that an unrelated attack to the person or not?). If that is in one thread, then it dilutes the discussion about the fact and the meta-point is opened at a place where people have other things to care about). The idea is not merely to correct the behaviour of the person who does these things, they are also to point out, and refute, these errors in logic. So, if theonly goal was to educate the poster, then doing so on another list/thread would suffice. But if the idea is to have a technical discussion, then the logical flaws need to be pointed out in the same discussion. Just callingit strawman with no justification is suboptimal, I agree. If you call something a strawman, you should also justify why it is so (like, you are argying against point A, which not one ever advocated, and you are ascribing to me positions I never took. This is a strawman). I think it is even better without the strawman at all. Everyone is It would be fantastic without the strawman arguents in the first place, yes. able to understand that arguing without having agreed what point is argued about does not work. Expressing your perceived difference of the points in discussion and why the arguments uttered are against the one but not the other, is something that will usually help the discussion and does not need any fallacy or strawman. If the respondent points out why the post is a strawman argument, using the shorthand phrase strawman does not detract from the discussion, in my opinion. Because we should all be aware that the error could also be on our side. Giving the arguments makes it easier for the other side to answer them and thus either to convice you or by making them answer them to make you see what they misunderstood so you can convice them. Adding the extra abstraction[1] of the fallacy adds more things to smear the discussion. Thus I think that naming the fallacy is only helpfull if you think the other person is doing it on purpose. And I think most will agree that with that accusation the discussion if escalated to a flamewar even it was not before. Hmm. I think we might actually be in agreement here; calling something a fallacy wthout describing why it is the case does have these drawbacks. But using the term, while also explaining why the term is valid, seems like a good thing. Without the rationale for using hte term, you are correct, it is just name calling. I think it has at most merits in a meta-discussion about whether some post was acceptable or not. I do not think it will help the discussion about the facts in my eyes, and only has potential for new discussions. (Take
Re: Summary of the debian-devel BoF at Debconf9
On Tue, Aug 18 2009, Leo \costela\ Antunes wrote: Hi, Ben Finney wrote: Bernhard R. Link brl...@debian.org writes: Perhaps there is a way to […] discourage all meta-discussion or mentioning of fallacy, ad-hominem or strawman on the other lists. Perhaps you have a better way of succinct terms to use when challenging those logical fallacies? Surely you're not saying you want such fallacies to go unchallenged in the forums where they appear? I believe he meant only that these keywords tend to denote a crossing into the realm of meta-discussion, where the point in question ceases to be discussed, and instead the arguments themselves become points of contention. It doesn't mean the arguments are worthless, but indicates a certain departure from the main point, which could mean this branch of the discussion has started to dilute - so to speak - the thread and therefore could be taken somewhere else, in order to keep the central thread concise. But really, the divergence from the discussion happened earlier, when the discussion degenerated into name calling (which is what ad hominem attacks are), or strawman attacks, which tend to derail the discussion by standing up irrelevant positions and arging against that, leading to thread bloat. Allowing these logical fallacies to stand, and not refuting them, lead to a discussion that goes nowhere, or floats off into sub optimal directions if not scotched in the bud. Indeed, leaving logical fallacies unchallenged does nore to harm the discussion than pointing them out and trying to bring the thread back to a logical discussion; and leaving ad hominem attacks unchallenged poisons the discussion environment to the point that it detracts from the discussion itself. manoj -- Can't open /usr/games/lib/fortunes.dat. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
On Tue, Aug 18 2009, Bernhard R. Link wrote: * Ben Finney ben+deb...@benfinney.id.au [090818 11:28]: Bernhard R. Link brl...@debian.org writes: Perhaps there is a way to [???] discourage all meta-discussion or mentioning of fallacy, ad-hominem or strawman on the other lists. Perhaps you have a better way of succinct terms to use when challenging those logical fallacies? I think succinct terms help not at all here. Once there is a succinct term 90% of their use is name-calling. If people think something is wrong they should say what is wrong and not invoce some name. If you want a full description of the logical fallacy in all replies, sure. The point is that the best refutation of a logical fallacy is to point out it is a logical fallacy, and thus, stop basing the rest of the discussion based on the logical fallacy. And really, if some logical conclusion is so broken that this brokeness has its own name, then everybody should be able to see it. This is a nice theory, but in reality one does see people arging against the person, or their perceived personality, or their traits, or ascribing motives to them all the time. These attacks on people, as opposed to discussion of what they said, is one of the major reasons discussion threads devolve into unproductive chaos. We should be managing to police discussion better, and the first step is identifying that such a post has been made. So either someone does it on purpose (then it is just some form of misbehaviour and discussing it only on topic on some mailing list about behviour on mailing lists). First, that list would be pretty nasty and uninteresting, so not many people would subscribe to it, and this notice would go mostly unnoticed, in the meanwhile, the poisonous email would have derailed the original discussion. Or the writer really missed something. (In this case I cannot imagine shouting strawman will make them understand), but staying with the facts and not entering the meta-level helps more. Just callingit strawman with no justification is suboptimal, I agree. If you call something a strawman, you should also justify why it is so (like, you are argying against point A, which not one ever advocated, and you are ascribing to me positions I never took. This is a strawman). I guess that is a reason why those succinct terms are so often used to throw them againt people like names-calling. And that is why I think they do not belong in any discussion unless you are sure you know everything better. But using the term, while also explaining why the term is valid, seems like a good thing. Without the rationale for using hte term, you are correct, it is just name calling. manoj -- For every bloke who makes his mark, there's half a dozen waiting to rub it out. Andy Capp Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
On Tue, Aug 18 2009, Michael Banck wrote: On Tue, Aug 18, 2009 at 03:17:55PM -0500, Manoj Srivastava wrote: Allowing these logical fallacies to stand, and not refuting them, lead to a discussion that goes nowhere, or floats off into sub optimal directions if not scotched in the bud. Indeed, leaving logical fallacies unchallenged does nore to harm the discussion than pointing them out and trying to bring the thread back to a logical discussion; and leaving ad hominem attacks unchallenged poisons the discussion environment to the point that it detracts from the discussion itself. I think peopluld prefer if those were pointed out in private mail. That assumes the only one you are seeking to give the right impression about the topic at hand is the person making the logical fallacy; but, really, you want to refute the illogical, fallaciour argument in the forum where it was published. Allowing logical fallacies to be widely disseminated, and the refutation to go to private email, is likely to lead to the outcome that the public discussion and archives are fill of unchallenged, unrefuted local fallacies. This seems somehow suboptimal to me. manoj -- There are twenty-five people left in the world, and twenty-seven of them are hamburgers. -- Ed Sanders Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
On Tue, Aug 18 2009, Steve Langasek wrote: On Tue, Aug 18, 2009 at 03:25:30PM -0500, Manoj Srivastava wrote: And really, if some logical conclusion is so broken that this brokeness has its own name, then everybody should be able to see it. This is a nice theory, but in reality one does see people arging against the person, or their perceived personality, or their traits, or ascribing motives to them all the time. Except that this is *not* the definition of the ad hominem fallacy. The ad hominem fallacy is claiming that a person is bad, *and therefore their arguments are wrong*. I would say it is attacking the character or motives of a person who has stated an idea, rather than the idea itself. The most obvious example of this fallacy is when one debater maligns the character of another debater (e.g, The members of the opposition are a couple of fascists!), but this is actually not that common. A more typical manifestation of argumentum ad hominem is attacking a source of information -- for example, responding to a quotation from Richard Nixon on the subject of free trade with China by saying, We all know Nixon was a liar and a cheat, so why should we believe anything he says? [0] Pointing out that someone is being a jerk on the mailing list is *not* an ad hominem fallacy. But saying that their message should not be heeded because at some other point in the past they had been jerks is one. Discounting a message because of a (perceived) character trait of the author is also suspect. These attacks on people, as opposed to discussion of what they said, is one of the major reasons discussion threads devolve into unproductive chaos. We should be managing to police discussion better, and the first step is identifying that such a post has been made. Given the sorts of things you've objected to as ad hominem attacks in the past, I definitely don't agree. A number of these have been legitimate complaints about behaviors that distract from or derail technical discussions. So you are saying that I misidentified some mail as an attack on a person. Which is perhaps an argument for my point: we need to identify that such a post has been made. I do not see the basis for your refutation here. Also, if the rationale for the disagreement is that you are say that a trait you say I possess (mistakenly objecting to non attack as an attack) is the reason my message (we should identify and curtail attacks on people) should be discounted -- sound familiar? Hmm. Sometimes heated complaints - but no less legitimate for all that. Complaining about the behaviours of a person might be legitimate, but not if it is put forth as the reason to discount the actual content of the message. It also is probably off topic for the thread. And in no way is it a counter argument. In all of these cases, the relevant question is not who makes the argument, but whether the argument is valid. manoj [0] http://www.csun.edu/~dgw61315/fallacies.html -- All the existing 2.0.x kernels are to buggy for 2.1.x to be the main goal. -- Alan Cox Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Wed, Aug 12 2009, Gunnar Wolf wrote: Manoj Srivastava dijo [Wed, Aug 05, 2009 at 10:08:13AM -0500]: Based on Debian's last two releases, I think we have a 22 month release cycle going; stretching it to 24 years is not a big deal. Speaking for myself, I think have a predictable freeze date, every two years, is a good thing. Umm... But the time from freeze until release is so far not predictable at all. Etch was way swifter than Lenny (or FFS than Sarge). They were all intended to be frozen for much less time than they ended up being. So… Freezing every 24 months (I won't even make a pun on your 24 years) can push us over the edge. Yes, I understand that this means the 24 months include the freeze time for the previous release. Still. In the time line below, I am considering freeze of the toolchain and base (d-i) as the start of the freeze, since we have not yet done that for Squeeze). These are culled from the d-d-a archive, looking for the mail announcing thte tool chain freeze. sarge: 2004/08 - 2005/06 (10) (freeze in stages) etch:2006/08 - 2007/04 (5) 24 months between freezes, 22 for release lenny: 2008/07 - 2009/02 (7) 21 months between freezes, 22 for release squeeze: 2010/?? - This is different from the time line AJ posted, since I am counting from the time we froze toolchain/base packages, since as far as I know the tool chain freeze date has not been announced. So it seems to me that we have pretty much stable interfreeze and ihnter-release cycles, and which is why I think we can manage to sustain 2 year release cycles. manoj -- You will lose an important disk file. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Wed, Aug 05 2009, Mark Shuttleworth wrote: Thanks for the input. This was a far gbetter reasoned mail than some that have appeared on the list. OK, so that's the theory. How do we get there? How do we get many distributions to sit down and explore the opportunities to agree on common base versions for major releases? Well, the first thing is to agree on the idea of a predictable cadence. Although the big threads on this list are a little heartbreaking for me to watch, I'm glad that there hasn't been a lot of upset at the idea of a cadence in Debian so much as *which* cadence. We can solve the latter, we couldn't solve the former. So I'm happy at least at that :-) Based on Debian's last two releases, I think we have a 22 month release cycle going; stretching it to 24 years is not a big deal. Speaking for myself, I think have a predictable freeze date, every two years, is a good thing. I do have objections to starting that with a foreshortened release cycle, and while I am neutral about December as a freeze month in general, I suspect that the the actual date should come after negotiating with major component package maintainers (and upstream), and efforts in house aimed at improving Debian, and, ultimately, other distributions. So yes, I concur. How do I think it could work in practice? Well, if Debian and Ubuntu went ahead with the summit in December, where we reviewed plans for 2010 and identified opportunities to collaborate, I think we would get (a) several other smaller distributions to participate, and (b) several upstreams to participate. That would be a big win. It would set us off on a good course. If we delivered, then, we would virtually guarantee that almost all the distributions and key upstreams would participate the next time around. And if *that* worked, we'd win RHEL over too. Umm, what summit is this? I think this is something that the Debian developer community has not been told about yet (which is somewhat irritating, but that is the theme for a different thread). First, there has been no secret cabal or skunkworks effort to influence Debian. As best I can tell, folks from both Debian and Ubuntu who have deep insight into release management established a shared interest in working together better, at many levels, and this was one idea that came forward. The fact that those discussions were open and ongoing was no secret - I wouldn't have talked about it in the media if it were! (Ironically, someone suggested that the fact that I was talking publicly about something in Debian implied there was a secret cabal. Aiieee.) Well, the proof of the pudding is in the eating, no? The fact that the majority of the developers have expressed a complaint that they were not in the loop seems to indicate that the non secret bit has yet to be adequately demonstrated. This reminds me of a notice that was on display on the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard. Third, I think we need to call on the people who are not fundamentally prejudiced to speak out. As long as criticism does not immediately accrue the label of bias, this is fine. Now, if, as in a previous mail from you, synchronization implies that people are agreeing to ship with the same versions of the tool chain, X, KDE/GNOME, and other major components, that would mitigate some of the worry heard on this list about Debian being taken advantage of. Of course, determining what version of these packages will ship in a release needs to involve the maintainers and upstream developers of the package in question, with the RM's having a deciding role in what does or does not make the cut (decision after consultation is a horse of a different color than a priori decisions). I currently object to shortening the current release, causing various teams to shelve their ongoing improvements and development plans, in order to hasten towards a sync process that has not even begu the process of deciding on which versions of major packages we will ship (and, personally, what the status of the reference selinux security policy shipped will be). I see this as a good point to start discussion, not as a point where we decide to freeze in four months or so from now. manoj -- There are two kinds of egotists: 1) Those who admit it 2) The rest of us Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On syncing freeze dates with other distributions
On Mon, Aug 03 2009, Russ Allbery wrote: Michael Banck mba...@debian.org writes: The other concern I have is lengthening our release cycle to 2 years - I think this is quite a bit too long, I am very happy with the current (rather informel) 1,5 years which is just between the 6-month release cycle of the Fedora, OpenSuSE and Ubuntu community distributions and the RHEL, SLES, LTS enterprise distributions. Amen. I think two years is a little too long and 18 months would be much better. We never actually have managed the 18 month release, have we? We freeze approximatly 18 months after the last release, and then release about 2 years or so after the last release. So, in steady state, freezing/releasing roughly two years apart will be close to what we do, no? I don't think Debian should make pledges external to the project about our release cycle at this point, at least not until we've done the same freeze at least twice on the same schedule and have proven internally that we can do it consistently. I also think that we should be looking at when we freeze not merely at when a derived distro freezes, but when major system components release, and when top level sister distributions freeze (we'll get far more benefit for Debian users were we to sync up with fedora/rhel; and have more clout with upstream, especially if Ubuntu sync's up with Debian/red hat as well). manoj -- Money is better than poverty, if only for financial reasons. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Tue, Aug 04 2009, Anthony Towns wrote: I'm a little bothered by the lack of release team involvement in the discussion, but I wonder if the reason isn't simply that it's probably pretty hard for them to pick a way of responding that won't be misinterpreted to fit folks predisposition to argue that Ubuntu are thieves! or everything's always decided behind closed doors! or similar. I am afraid I do not see how participating in the discussion will fuel the paranoia of folks that everything's always decided behind closed doors! part. They can always point out how any of the proposals being bruited will impact actual releases, or help iron out impracticalities in suggestions (not every thing need be shot down out of hand [yes, yes, I know, that's what I often do]) manoj -- When all else fails, read the instructions. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Mon, Aug 03 2009, Moritz Muehlenhoff wrote: Aligning our releases with RHEL rather than with Ubuntu seems more worthwhile to me. They have similar stabilisation lengths as we did for previous releases and they're investing a lot of work into the kernel, from which we could profit immensely. Now that's a thought. This would also help with SELinux, since we would freeze with a tested and polished releawse-ready version of SELinux userland and policies. So, I would say that sync'ing with a peer distribution makes way more sense than sync'ing with a Debian derivative. manoj -- Just because he's dead is no reason to lay off work. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Mon, Aug 03 2009, Philipp Kern wrote: [ Please note that I'm taking all my hats off for this post, especially ] [ debian-release ones. ] On 2009-08-03, Sandro Tosi mo...@debian.org wrote: What I'm wondering is: why should *we* adapt to ubuntu? why was not ubuntu in the first place to accommodate our plans, instead of the other way around? Why was not ubuntu that proposed we freeze when Debian freeze but the opposite or so? since when upstreams make their plans on downstreams? Well, there is a certain hope that upstreams above Debian would also adapt at some point. They are far more likely to adapt, I would think, if Debian sync's with RHEL, rather than Debian sync'ing with a Debian derivative. manoj -- If you mess with a thing long enough, it'll break. Schmidt Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian redesign
On Sat, Aug 01 2009, Steve Langasek wrote: On Sat, Aug 01, 2009 at 11:41:29AM +0200, Werner Baumann wrote: Another example: Why replace Getting Debian with download. Getting Debian links to a small tutorial about the various ways to - well - get Debian. Why name it download? Because all the others have a download area? To catch generation download? Because the current website is *all but impossible to navigate*, lacking many of the signposts that users rely on to find their way. On the current Debian website, we have the following sidebar: Getting Debian CD vendors CD ISO images Network install Pre-installed None of these includes the key word download. We should not make users think this hard in order to figure out how to download Debian - that's entirely the wrong kind of elitism! Sounds like the solution is to perhaps replace CD ISO images with Download CD(images), not replace Getting Debian IOW, the replacement is beig advocated at the wrong heading level. manoj -- Those who do not understand Unix are condemned to reinvent it, poorly. Henry Spencer, University of Toronto Unix hack Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Thu, Jul 30 2009, Raphael Hertzog wrote: On Thu, 30 Jul 2009, Marc Haber wrote: In fact, I would prefer if Ubuntu had to change _their_ scheduled to accomodate us, if they want to have the advantage of being in sync with us. It's _their_ advantage after all, not ours. I don't mind who changes the date for the other but I really don't agree that doing it is only for Ubuntu's advantage. Nobody in Debian would have taken such a decision, we are Debian developers and have no interest in helping only Ubuntu. I wish I could actually whole heartedly concur, but actual actions do not seem to mesh with the nice sentiment. What we're speaking of is synergy between both distributions. You know the it's the principle behind “the combination of both is worth more that the sum of individual parts”. Another nice sentiment. But the whole is not always more than the sum of the parts; and in this particular case, the synergy between the distributions is far skewed one way. I spend a log of time with my upstreams, and I am trying to implement the philosophy that any change in my packages be trated as a bug (whether or not it is in the bts), and sent upstream. I use upstream bug trackers, and upstream mailing lists, accommodating the author. Very rarely do I see such feedback coming from Ubuntu (the SELinux maintainers are the the pleasant exception). If Ubuntu were better at feeding back patches into the debian bts, well, what you say might have been true. We are not only major supplier to Ubuntu, we have our end customers ourselves. I'd prefer that it stayed that way. The synchronization with Ubuntu is not going to remove our identity. Anything to back up this assertion? We'll keep our user base and the possible improvements in both Why would the casual user select something that has old KDE/GNOME, has the same or more bug fixes (since bug fixes rarely migrate from ubuntu to debian, based on my experience), and does not have commercial support? While I personally care little about popularity, I do think this assertion that we will not lose our users is unfounded optimism. manoj -- Even if you persuade me, you won't persuade me. Aristophanes Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Thu, Jul 30 2009, Steve Langasek wrote: On Thu, Jul 30, 2009 at 11:07:58AM +0200, Marc Haber wrote: We'll keep our user base That's what I doubt. Ubuntu LTS will be better than Debian stable in all aspects, why should anybody continue using Debian stable? You believe that Debian, releasing with approximately the same set of packages as an Ubuntu LTS but with a requirement to only release when ready instead of releasing on a fixed schedule as Ubuntu LTS will, offers no relevant differentiation at all for users? If ubuntu freeze starts later than the Debian freeze, and if fixes to Ubuntu do not often migrate back to Debian, I do see it likely that ubuntu LTS, combined with interim Ubuntu release, will make Debian irrelevant in the eyes of the common public (like, not distro geeks). With that comes a falling user base, and with falling interest we stop getting the creme de la creme of the developers (Oh, doubtless we'll keep getting people of second and third tier skills for a while). Doesn't this imply that everyone who continues using Debian today does so merely as an accident of the release schedule and the particular set of packages that land in a given Debian release? I am sure this is true of some portion of the user base. There seems to be an assumption here that Ubuntu would benefit from bugfixes from Debian developers, but that the reverse would not be true. Is this what you believe? Does that mean you don't think Ubuntu developers contribute fixes back to Debian today? Exactly. As I mentioned in another message; I spend far more time rebasing changes made in debian to feed upstream, using their BTS and mailing lists, and modifying and tweaking patches to their satisfaction; and I rarely see this in the 25+ packages I still maintain from Ubuntu (exception: SElinux related issues). While never committing to keep any given package in sync with Debian, Ubuntu developers certainly are actively engaged in pushing their changes upstream to Debian. So they seem to be targetting my packages not to push changes to? kinda doubt that. manoj -- A sinking ship gathers no moss. Donald Kaul Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
On Thu, Jul 30 2009, Bernhard R. Link wrote: Silly is mostly about missing intellectual skills, so applying it to actions, ideas or questions is mostly pars pro toto meaning the human it originates from. I beg to differ. I have had dumb ideas in the past, and even proposed them; but while admitting I occasionally may have dumb or silly ideas in no way means *I* think I am a dumb person (YMMV). Intelligent people may have dumb/silly ideas. Dumb people occasionally have brilliant ideas. One should not equate the quality of ideas to the quality of the proponent, unless one wishes to be unpleasantly surprised bvy the frequency of the error of ones ways. manoj -- Carmel, New York, has an ordinance forbidding men to wear coats and trousers that don't match. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Wed, Jul 29 2009, Alexander Reichle-Schmehl wrote: Hi! Steffen Moeller schrieb: Same here. The release team, or the individual that pressed the button for the announcement, I suggest to apologize for disturbing our community. The text was coordinated within the entire press team, our release masters, the head of the technical commitee and the DPL. IMHO there's no need for an apology. I think that just expands the set of people who owe an apology. manoj -- sillema sillema nika su Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Wed, Jul 29 2009, Luk Claes wrote: Who would you like to propose a release cycle to the project if not the Release Team? A proposal would have been absolutely appropriate, with discussions by various teams as to the best time to freeze. To be clear the Release Team cannot just decide what the release cycle will be, though we proposed a plan in the team's keynote at DebConf and the plan was welcomed by the audience. There were some important considerations though. The audience for the talk was what fraction of the developer set? We do not plan to do a yearly release, we plan to have a release about every 2 years while having a one time exception for next release by freezing this December. Why? There are development plans underway by folks (and yes, I am one of them) where packages will be polished for release about a year from now -- and the short release cycle throws a monkey wrench into the works. Why was this not discussed before hand? Are we so beholden to canonical that we must slave our releases to their LTS? I thought they borrowed our code, not the other way around. The main reason is that the Release Team hopes to now have the momentum to make a time based freeze work. If we would delay, it will very probably mean that many developers 'forget' about what the time based freeze is about. If you want to get the developers behind your release schedule, keeping us in the loop is a better idea. As such, it seems to me you think that treating developers like mushrooms will have no impact on your precious release schedule. I think you might find that the release team can't make releases on its own. The developers have had the opportunity and still have the opportunity to get stuff done before the release. It's true that developers should probably consider to already be careful about what to upload, but there is still opportunity to do changes till the freeze. I see no reason for developers kept out in the cod to do so; really. While the release team might be constitutionally delegated to decide when to release on a whim, the developers are also constitutionally protected from having to do something they do not want to. manoj -- Sigmund Freud is alleged to have said that in the last analysis the entire field of psychology may reduce to biological electrochemistry. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Wed, Jul 29 2009, Nico Golde wrote: Hi, * Sune Vuorela nos...@vuorela.dk [2009-07-29 12:07]: On 2009-07-29, Luk Claes l...@debian.org wrote: Who would you like to propose a release cycle to the project if not the Release Team? What I have seen so far, both from the press announcement and from the video, it is not a proposal. it is a decision. [...] Why is that such a big problem for you? I mean without stating my opinion about the content of this decision itself I think as it's the release teams job to make such decisions and for myself just trust them that this is the best decision for the project. Everyone is free to join the And if I feel that is not the best decision for the users of my package? manoj -- Try not to have a good time ... This is supposed to be educational. Charles Schulz Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Wed, Jul 29 2009, Steve Langasek wrote: On Wed, Jul 29, 2009 at 01:36:16PM +0200, Bernd Zeimetz wrote: count me in. me too. Obviously we need to force the release team to talk with the important teams in Debian. If i'd have to come up with a GR it would probably sound like While we appreciate the plan of fixed freeze cycles, the plan to start them in December 2009 is not acceptable for the project. We ask the release team to talk with all important teams (kernel, d-i, kde, gnome, ftp-master, dsa,) to find an appropriate date. Would *you* intend to talk to all of these teams, before starting a GR declaring that the proposed timeline is not acceptable to them? Feh. Do as I say, not as I do. manoj -- Alcohol, hashish, prussic acid, strychnine are weak dilutions. The surest poison is time. -- Emerson, Society and Solitude Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Wed, Jul 29 2009, Joerg Jaspert wrote: The Debian project did empower the Release Team to manage our releases. We did not tell them Manage the release by exactly following whatever we did in the past. So they are entirely free to chose the way a release is done. §2.1. General rules 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. So the developers are then within their rights to ignore the short first freeze, and work to release whenever the packages are really ready. manoj -- I don't believe in psychology. I believe in good moves. Bobby Fischer Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Wed, Jul 29 2009, Stephen Frost wrote: * Sune Vuorela (nos...@vuorela.dk) wrote: I'm hoping that we can convince the release team to change their mind. I doubt you can, and I hope you don't. It could have been announced better, but in general I think it's a good thing for Debian. Please get over how it was announced. Well, yes and no. I think a freeze every two years is a good idea. I just do not think that we should freeze in 5 months or so. manoj -- God is real, unless declared integer. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Wed, Jul 29 2009, Steve Langasek wrote: (Which is still an important and necessary process, even if some people currently feel the release team is shoving this decision down their throats - if there are problems with the proposed plan, we can only fix those and make the next Debian release as great as possible by discussing them respectfully and working together to solve them.) Really? I doubt that the effort to get the next release of debian to a state where we can ock down a out of the box install or virtual machine with selinux strict policy is going to get any consideration at all. All the short first release cyce seems to do is to ensure that canonical's LTS will always be a more compelling product than a Debian release, being slightly newer and improved. Does not sound like a win for Debian (just makes us even more irrelevant). manoj -- It is the quality rather than the quantity that matters. Lucius Annaeus Seneca (4 B.C. - A.D. 65) Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
On Sat, Jul 25 2009, Lars Wirzenius wrote: For example, in the specific case under discussion, the criticism might have been expressed something like this instead: I think this is a bad idea. It creates extra work for developers You are making the assumption that the authors reaction to Bad is less negative than the reaction to Silly. While this is subjective, I do not think it is without contention: Bad possibly has the connotation of malice, or active harm, Silly has association with harmlessness. (c.f. The Collaborative International Dictionary of English v.0.48 [gcide]) I personally would regard either adjective as equally negative, though I would be driven to either defend my idea or concede it's silliness, instead of attacking the critic. I have also seen ideas characterized as stunningly bad (hi, diziet), which seems to be in line with silly. Negatively characterizing ideas, and acceptable negative adjetives, with all the subjectivity involved, seems ... strange. Mind you, my his a silly idea phrase was a single clause in a long email detailing why the idea was, err, suboptimal, so the whole reaction seems somehow overwrought. Sorry for jumping in again (I had promised to stay off the thread), but I respect Lars, and I thought he deserved a public response. manoj -- Death carries off a man busy picking flowers with an besotted mind, like a great flood does a sleeping village. 47 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership - take #1: inactivity
On Fri, Jul 24 2009, Kevin Mark wrote: If someone goes through the arduious process of becomeing a DD: proving their knowledge of: a. FLOSS ideals, b. Debian ideals, c. FLOSS legal ideas, d. computer languages, e. social skills f. and patience to wait for various approvals, account creation, g. getting packages though NEW and h. making uploads that dont damage users systems. And then assuming they go MIA, get their account deactivated and then reapply for DD status. What are they expected to show to be readmitted? I dont assume that they lost any of those skills in a-h. Packaging for Debian is not a static knowledge base; policies and practices change, and there are changes in infrastructure. If you have been away for a few years, you migh well be out of touch, and it is not unreasonable for the project to ask them to demonstrate that they retain the requisite skills. Also, computer language skills do degrade with lack of practice; I am far less fluent in languages I have not used for a few years than when I was using them actively. Is it a show of re-commitmant needed? I think so. manoj ps: You have a huge sig, in the good old days nettiquette limited sigs to less than 4 lines. -- Overdrawn? But I still have checks left! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
On Fri, Jul 24 2009, Luk Claes wrote: Twisting people's words is unfortunately very normal behaviour for Manoj. On Fri, Jul 24 2009, Raphael Hertzog wrote: Or he should post less and take the time to review what he writes... (including the pass where he's supposed to remove the unneeded agressivity) This is hilarious. Two posts attacking the man -- ad hominem -- and these are the folks talking about being less aggressive. The contents of these posts are prime examples of hilarious hypocrisy. manoj -- A black cat crossing your path signifies that the animal is going somewhere. Groucho Marx Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership - take #1: inactivity
On Fri, Jul 24 2009, Matthew Johnson wrote: On Fri Jul 24 08:43, Steve Langasek wrote: I am not convinced of this. Infrastructure contributions are necessary and valuable, but we don't admit people as Debian Developers on the basis of infrastructure contributions, nor to work on infrastructure; They may need (depending what it is they do) Debian machine access, which is typically restricted to DDs (although I don't know whether specific exceptions are made). Then that is also easily measured. We can easily log access to restricted developer machines, and add that tot he mettric. manoj -- Don't tell me what you dreamed last night for I've been reading Freud. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
On Fri, Jul 24 2009, MJ Ray wrote: Manoj Srivastava sriva...@debian.org wrote: [...] I think that we can go over much to the other side: We should not be overly genteel about silly ideas. [...] I don't think there's anything wrong with being a polite society (=genteel) even when confronted with a silly idea. Maybe the above should be gentle instead of genteel? Sorry if this is just picking up a typo or malapropism, but I really do think there's a substantial point here: the project should remain polite even in the face of really daft ideas (like the 3017th report that our website CSS is invalid just because the W3C validator is incomplete). Calling a daft idea silly is being rude now? Deep-six the idea by all means, but there's no need to be crass. Frankly, calling an idea silly does not seem crass to me (compared to things I can point out to posted on the planet) manoj -- The first 90% of a project takes 90% of the time. The last 10% of a project takes 90% of the time. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership - take #1: inactivity
On Fri, Jul 24 2009, Stefano Zacchiroli wrote: On Thu, Jul 23, 2009 at 11:52:11PM +0200, Bernd Zeimetz wrote: Should activity in teams be enough reason to be regarded as an active DD? Yes. On Thu, Jul 23, 2009 at 10:35:00PM -0500, Manoj Srivastava wrote: Also people who do translations. Perhaps we can institute other sensors/probes that can track such activity? (Committing to a VCS could send off a email to a bot recording who did the commit, for example). This can detect any activity by a person on a team VCS site, for instance. This is the kind of things I intended (and still intend) to avoid in the proposal. DD rights let you do things you couldn't do without them, mainly two: vote and do uploads [1]. I think we should measure them as a basis for being active, you can continue doing the other tasks also without DD rights. Fair enough. One can also add logging in to restricted machines to this (need to be a DD to do that), but not if we take into account Steve Langaseck's argument that purely infrastructure activities should not serve as a basis for non-MIA. manoj -- Do not think by infection, catching an opinion like a cold. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
On Fri, Jul 24 2009, Luk Claes wrote: Manoj Srivastava wrote: On Fri, Jul 24 2009, Luk Claes wrote: Twisting people's words is unfortunately very normal behaviour for Manoj. On Fri, Jul 24 2009, Raphael Hertzog wrote: Or he should post less and take the time to review what he writes... (including the pass where he's supposed to remove the unneeded agressivity) This is hilarious. Two posts attacking the man -- ad hominem -- and these are the folks talking about being less aggressive. Twisting again are you? Only if you call quoting what you say twisting your words. This is a concept funny in itself. You did note that you were not talking about the contents of my message, but were ascribing a negative charecterization of myself -- and that you did it again? You should consider reading up on logical fallacies, and argumentum ad hominem; that ought to demonstrate that did not have to do any word twisting at all. manoj -- People who fight fire with fire usually end up with ashes. Abigail Van Buren Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
On Fri, Jul 24 2009, Luk Claes wrote: Manoj Srivastava wrote: On Fri, Jul 24 2009, Luk Claes wrote: Manoj Srivastava wrote: On Fri, Jul 24 2009, Luk Claes wrote: Twisting people's words is unfortunately very normal behaviour for Manoj. On Fri, Jul 24 2009, Raphael Hertzog wrote: Or he should post less and take the time to review what he writes... (including the pass where he's supposed to remove the unneeded agressivity) This is hilarious. Two posts attacking the man -- ad hominem -- and these are the folks talking about being less aggressive. Twisting again are you? Only if you call quoting what you say twisting your words. You put it in a different context to match better what you wanted to bring across, I name that twisting, though you're still free to call that whatever you like. Actually, the context was that someone said I twisted words (no examples provided), and you respnded with that one liner (again, with no substantiation) Charles Plessysy wrote: Le Thu, Jul 23, 2009 at 10:30:17PM -0500, Manoj Srivastava a écrit : While I do not approve of ad hominem attacks on the mailing list, I think that we can go over much to the other side: We should not be overly genteel about silly ideas. You twist people words and extrapolate to the silliest interpretation, that you use as a pretext for adding insults to your messages. I am sick of this, and unsubscribed from this list. Twisting people's words is unfortunately very normal behaviour for Manoj. Cheers Luk This is the full text of your message. Still seems an ad hominem, so I think you have not made your case about twisting words. This is a concept funny in itself. You ridiculously trying to defend yourself from twisting words while continuing to do it in more subtle ways, sure. And your messages continue to be examples of unsubstantiated ad hominem attacks, and, dare I say it, mis stating facts, based on this thread alone. manoj -- A witty saying proves nothing, but saying something pointless gets people's attention. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership - take #1: inactivity
On Wed, Jul 22 2009, Charles Plessy wrote: Personnaly, I would not mind a more stringent mechanism, for instance defining activity as changing one’s LDAP password once per year. Or if we want to be fancy, we could count time not in years but in releases. Releases are the greatest events of our Project, and there would be some sense to ask the developers if they want to do one more or retire after each time we harverst the fruits of our hard work. For the debian-med Alioth project, I proposed to make a post-release general ping but I am late to start it. If there is interest, I can report how it was perceived by the members after I finish it. his is silly. It is one thing to track activities that a DD is expected to perform in the normal course of being a DD, and performing which needs one to be a DD, and quite another to create bureaucratic busy work so someone can check off a mark. That goes for unsolicited pings to active developers as well. Now, if there is active work going on that does not reflect itself in uploads, then I can see using a signde/encrypted email to a role address every couple of years or so could be a work around to the auto MIA process. manoj -- Once the erosion of power begins, it has a momentum all its own. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership - take #1: inactivity
On Wed, Jul 22 2009, Steve Langasek wrote: If it's going to be automated, does it behoove us to also send automated mails to DDs that are getting close to the two-year limit, warning them? Or is it your view that 2 years without activity is so far beyond what's reasonable that there's no reason to give such a warning? I would say the latter holds. And I also agree that MIA != emeritus manoj this could be interesting, going through NM again -- I'm a mean green mother from outer space Audrey II, The Little Shop of Horrors Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
On Thu, Jul 23 2009, Charles Plessy wrote: Le Thu, Jul 23, 2009 at 03:44:01PM -0500, Manoj Srivastava a écrit : his is silly In case you had any doubt about it, let me confirm: it hurts to read that kind of answer. It does not help, nor bring any useful element to the discussion by starting your anwers with that kind of statements. Please consider refraining from writing them. While I do not approve of ad hominem attacks on the mailing list, I think that we can go over much to the other side: We should not be overly genteel about silly ideas. And I even defined why the Idea was silly: Instead of the proposal, that seeks to measure activities that require DD-ship to perform, and indeed are required for performing ones duties as a developer, adding bureaucratic busy work is indeed suboptimal. If critiques of your ideas hurt you, I suggest you start off by thinking harder about them, and doing a self critique t discover where you might be falling short. manoj -- Laugh while you can, monkey-boy. Dr. Emilio Lizardo Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re-thinking Debian membership - take #1: inactivity
On Thu, Jul 23 2009, Bernd Zeimetz wrote: Steve Langasek wrote: (Are you referring here to package teams, or infrastructure teams?) I doubt that packaging teams are a problem here, I'd imagine that every DD uploads a package one a year anyway. But I know that there are/will be DDs which do infrastructure stuff only, and rarely upload packages. Such DDs should never be regarded as MIA, of course. Also people who do translations. Perhaps we can institute other sensors/probes that can track such activity? (Committing to a VCS could send off a email to a bot recording who did the commit, for example). This can detect any activity by a person on a team VCS site, for instance. Setting up a bot should not be too much work, once we set out the format of the structured email received. And an archive of the mail, perhaps sorted by the human it is attributed to, can help a human auditing the system. manoj -- Life is a yo-yo, and mankind ties knots in the string. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Draft vote on constitutional issues
On Tue, May 12 2009, Wouter Verhelst wrote: On Sun, May 10, 2009 at 06:59:41PM +0100, Matthew Johnson wrote: On Sun May 10 18:34, Luk Claes wrote: 3. Option X overrides a foundation document, possibly temporarily (?) Not possible. You can only override a decision and amending a foundation document is the previous option. What would you call the vote to ship non-free software in etch? Because that is what I mean. We are agreeing to do something which the foundation document said we would not, but only for a certain period of time (etch). I don't _care_ what you call that, I call it a temporary override of a foundation document. I think this is the core of the disagreement. I do not call it a temporary override of a foundation document; I call it a temporary practical consensus between the needs of our users and the needs of the free software community. I thought we had agreed to adhere to a document that lays out how these conflicts between the need of the users and the free software pledge we made is to be resolved: , |5. Works that do not meet our free software standards | | We acknowledge that some of our users require the use of works | that do not conform to the Debian Free Software Guidelines. We | have created contrib and non-free areas in our archive for | these works. ` As I understand it, we, as a project, have acceoted that there is tension between the needs of our users, and the dictates of free software; and the solution we have come up with is called contrib and non-free areas in our archive. Isn't that perfectly clear? manoj -- Non-sequiturs make me eat lampshades. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Voting on messages: a way to resolve the mailing list problems
Hi, So, are there going to be guide;lines for this voting on emails? On /., when one moderates, there are clear labels: troll, off-topic, flamebait, etc. When we put in voting, would there be some guidelines for what is or is not acceptable criteria for disapproving a message? Can people disapprove if a message is - they disagree with the message? - the author is french? - The author's sexual orientation displeases them? - the author is male? If there are such guidelines, will there be consequences to wilful and prolonged abuse of moderation guidelines? Is there going to be meta moderation? I would have considered that these would fall under common sense or people are not insane clauses, but I have recently heard people on IRC professing that since they were not asked to accept the constitution, just hte SC and the DFSG, they do not feel bound by constitutional mandates, and thus can do whatever they want in their activities in Debian. I am scared that we might have arrived at the point that unless there are strong guidelines and policies laid out about voting, this mechanism is likely to be abused as well. manoj -- A fool and his money are soon popular. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFC: General resolution: Clarify the status of the social contract
Hi, I like the idea of clarifying what the principles of the project actually are, since, as aj said, all the decisions about lenny would fall out from the position the project take about the foundation documents. While I have always thought that foundation implied the proposal below, apparently this is not a universally held view. I think we will keep coming back to this biennial spate of disagreement we have, as we determine whether or not we can release with firmware blobs or what have you. This also would help developers, the ftp-masters, and the release team with a clear cut expression of the projects goals and clarifies how the project has decided to view the social contract. Given that, I suggest we have a series of proposals and amendments, each in a separate email, sponsored and seconded independently, that could look something like this below: ,[ The Social contract is a binding contract ] | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ the social contract should stop us from including anything that | doesn't comply with the DFSG in main ` ,[ The social contract is binding, but currently flawed ] | This amends the proposal above, and replaces the text of the proposal with: | The developers, via a general resolution, determine that the social | contract should apply to everything Debian does, now and in the future; | _AND_ it is and was a mistake to have the DFSG cover firmware because | we have not yet been able to limit Debian to only DFSG-free firmware | in a suitable way. This mistake should be corrected by amending the | social contract. ` ,[ The social contract is binding but may be overridden by a simple GR ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract should apply to /almost/ everything Debian does, now | and in the future; _AND_ for the few cases where it should not apply | now, there should be an explicit GR affirming that variation (by simple | majority) ` ,[ The social contract is a goal, not a binding contract ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is an aspirational document: while we aim to achieve as | much of it as feasible at all times, we don't expect to get it | completely right for some time yet. This includes DFSG-freeness of all | firmware ` ,[ The social contract is a non-binding advisory document ] | This amends the proposal above, and replaces the text of the proposal | with: The developers, via a general resolution, determine that the | social contract is a statement of principle only, and has no particular | force on the day to day operations of Debian, except in so far as it | influences individual contributors' actions. ` If all these variations get sponsored and seconded, the ballot would look like: [ ] The Social contract is a binding contract [ ] The social contract is binding, but currently flawed [ ] The social contract is binding but may be overridden by a simple GR [ ] The social contract is a goal, not a binding contract [ ] The social contract is a non-binding advisory document I think we need this clarification, so people no longer accuse other people of malfeasance based on a flawed understanding on the correct status of foundation documents. I do have an ulterior motive: clarifying this will help those of us currently evaluating whether this is the project they signed up for, and whether we want to continue to be a part of it. Some of the options above, if they passed, would be a clear proof that the project might have moved on from the principles that were in effect when we joined the project. manoj -- May you do Good Magic with Perl. Larry Wall's blessing Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpGnYFLBViJx.pgp Description: PGP signature
Re: RFC: General resolution: Clarify the status of the social contract
On Fri, Dec 19 2008, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: I think we will keep coming back to this biennial spate of disagreement we have, as we determine whether or not we can release with firmware blobs or what have you. This also would help developers, the ftp-masters, and the release team with a clear cut expression of the projects goals and clarifies how the project has decided to view the social contract. Given that, I suggest we have a series of proposals and amendments, each in a separate email, sponsored and seconded independently, that could look something like this below: I think these have the same flaw as our current situation: none of them state who interprets the Social Contract and the DSFG if there is a dispute over what they mean. We know there will be such disputes. Just saying that they're binding (or not binding) doesn't resolve those disputes. I do ont think that determining who interprets the non-constitution foundation documents belongs on the same ballot. It is a flaw in the constitution, and should be fixed, I would second proposals that let the secretary not just interpret the constitution, but all other foundation documents as well. This seems in line with the constitution already handing tot hte secretary the role of interpreting the constitution. I also like the fact that then the secretary is given the role of interpreting the foundation documents, and determining final form of the ballots; I would suggest that the secretary be stripped of the power to run the actual vote (a wee bit of automation to devotee will allow somewone else to run it. This way the secretary has no more access to the votes that people cast than any other developer. Again, a constitutional amendment modifying the powers of the secretary should be discussed independently of deciding what the role of the SC is. manoj -- There are two ways of disliking poetry; one way is to dislike it, the other is to read Pope. -- Oscar Wilde Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
[ ] The Social contract is a binding contract, DPL interprets [ ] The Social contract is a binding contract, secretary interprets [ ] The Social contract is a binding contract, tech ctte interprets [ ] The Social contract is a binding contract, individuals interpret [ ] The Social contract is a binding contract, new ctte interprets [ ] The social contract is binding, but currently flawed, DPL interprets [ ] The social contract is binding, but currently flawed, secretary interprets [ ] The social contract is binding, but currently flawed, tech ctte interprets [ ] The social contract is binding, but currently flawed, individuals interpret [ ] The social contract is binding, but currently flawed, new ctte interprets [ ] The social contract is binding but may be overridden by a simple GR, DPL interprets [ ] The social contract is binding but may be overridden by a simple GR, secretary interprets [ ] The social contract is binding but may be overridden by a simple GR, tech ctte interprets [ ] The social contract is binding but may be overridden by a simple GR, individuals interpret [ ] The social contract is binding but may be overridden by a simple GR, new ctte interprets [ ] The social contract is a goal, not a binding contract [ ] The social contract is a non-binding advisory document [ ] Further Discussion I would hate to have to run that vote. I strongly suggest we separate these orthogonal issues. manoj -- Any discovery is more likely to be exploited by the wicked than applied by the virtuous. -- Marion J. Levy, Jr. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: General resolution: Clarify the status of the social contract
On Fri, Dec 19 2008, Luk Claes wrote: Manoj Srivastava wrote: Hi, I like the idea of clarifying what the principles of the project actually are, since, as aj said, all the decisions about lenny would fall out from the position the project take about the foundation documents. While I have always thought that foundation implied the proposal below, apparently this is not a universally held view. You want to clarify what the principles of the project really are and all you talk about is point 1 of the Social Contract??! Maybe you take the other points for granted, though it surely looks strange to me. So, where is your proposed wording which will not appear strange to you? I also think it's rather strange to talk about binding and non-binding regarding 'Guidelines'. As long as it are guidelines, the question will always remain how to interprete them in any circumstance AFAICS. The social contract is supposedly a contract. Also, the last two of thte options in the mail seem to be where you are coming from. If not feel free to suggest other options or better wording. manoj -- Sometimes I worry about being a success in a mediocre world. Lily Tomlin Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Why the gr_lenny ballot is the way it is
Hi, This whole set of discussions and proposals started a couple of months ago, when concerns were raised about firmware blobs, dfsg violations, and the release. This, after a round of disuccion, led to three proposals on how the release should be conducted, in view of firmware blobs currently in the linux kernel packages. The proposals led tyo a great deal of heated responses, and whole slew of related proposals were produced -- related, as in all of them dealt with firmware blobs and difsg violations, and dealt with the release process, and some of them were for handling just the current release, others sought to solve the issue of firmwarfe for this and all future release4s, either directly, or delegating the decisions to a group of developers, and away from the general resolution mechanism of resolving this for future releases. All of these related proposals would handle, one way or the other, the issue of this release and firmware. Some of them would grant dispensation to more than just firmware, and some of them solve this problem for future reelases as well, but all would resolve the release _now_. Also, some of the proposals are indeed orthogonal, or, at least, mutually incompatible; and in some cases, selecting one option makes the others moot. Yes, some of the options on this ballot have long term impact, but they are also equally capable of solving our What to do about Lenny problems. Since they all solve the Lenny issue, they are relevant, and related, solutions for the issue. I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. Now, we have been fairly non-anal about differing options on out ballots being formally proposed as amendments (I amend proposal foo, and replace all the words in that proposal by these below ), I did not see any reason to change being anal retentive for just this vote. The ballot is a mess. While I think the related proposals should be placed on the same ballot overrides ere, the prooposals are not truly all orthogoanl. We could, for example, do the allow the delegation of DFSG violatio decisions to the release team, _and_ also rulke that firmware should be granted special dispensation in the DFSG. So, while the power set of the options is not feasible, we could have a slew of options combining the various proposed options, if people wanted to vote on a compatible set of options. This was discussed a month ago, in early november, giving people who wanted to vote on a combination of optiosn plenty of time to propose favourite combinations. Message-ID: 87ej1cd11m@mid.deneb.enyo.de Message-ID: 871vxczbww@anzu.internal.golden-gryphon.com No one seemed to want such combinations enough to follow up on that. Also, splitting a vote into multiple ballots, with related proposals affecting the same action (lenny release, for instance) , is a horrendously bad idea -- since the massive amounts of strategic voting possibilities will taint the final result. Given that these proposals are strongly related, they should be on the ballot together. The permanent solution proposals, if they fail to pass, may be discussed, modified, and brought to the table again. manoj -- Those who will be able to conquer software will be able to conquer the world.-- Tadahiro Sekimoto, president, NEC Corp. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Call for vote (Re: call for seconds: on firmware)
On Fri, Dec 12 2008, Ean Schuessler wrote: Does 5 refer only to firmware that is not currently identified as being non-free? If that is the case, is 5 a viable choice? If it doesn't resolve the problem completely and allow us to release then it needs to be accompanied by a plan for the other problem firm/software. I am not sure if we do have firmware that is known for a fact to be non-free; but if there is, this option does not allow us to ship it in main. If it did, it would have needed a 3:1 majority as well. I have a machine which does need non-free firmware-XXX packages for the network card, and the non-free firmwares on a usb stick solves the problem nicely. I don't think shippinf the firmware separately is a show stopper. manoj -- I have ways of making money that you know nothing of. John D. Rockefeller Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Call for vote (Re: call for seconds: on firmware)
. such firmware can and should be part of our official installation media. -- The options choice 2, choice 3, choice 4, and choice 6 supersede foundation documents, temporarily or permanently, and thus need a 3:1 majority. The options choice 1 and choice 5) require a simple majority to pass. The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEk//6wRBAD7CH1mElXRhrTJnTrTZZQDcQjG4mRBaFEAe+azE3t6L9JMXVOp Ups7m8u9xwKYr0qfpJWw5oTFEebvN6wLP90tJrqavBfBY6YpO5LZdhnki3ddLni5 vWlHtpcUmmELJW7xXLjvzZQYtzanwV3qyUJYBqSoCtb5RYXIWaus8fGJVwCgrtoZ AdTAmX7xsUMNZMi9guvrcyEEAPptWEI6KHmv3UlR3+9O+fKnCCgk43ll591qxw68 pbXfYSAY6PUfh7xcz/z9hnlWBbSYCMbrykovCTO85A77O5NT9SwKb3oKk+s4NxWi Ylx6DDK6q/+9DmGK/1yXg0vZ8ylybImjbRp7d5S2MSnX/GWvQXOPX6LKu6hXb2lN ZlkiBADcKq8jTjXdtRkqTRDKPM39yCk/90locWDdA4umSmpNRszQZkWcxJ/bTdIb mr9MBqv4dIn1QR2H+Kd8L4HSZtgTZu9QbosGYDC2ddrAmkqUw4Mzazp5IaZ2p1H+ E07hxn5Ex5Fv8o1hTsOxu6tVtahhgq4245hHF3onN+1FGliXfLQ8TGVubnkgR1Ig dm90ZSBrZXkgKEVwaGVtZXJhbCBLZXkpIDxncl9sZW5ueUB2b3RlLmRlYmlhbi5v cmc+iGYEExECACYFAkk//6wCGwMFCQAk6gAGCwkIBwMCBBUCCAMEFgIDAQIeAQIX gAAKCRDElT8+Z8sSYje+AJ96psJX6s59kM4CFsIcrOn1FXa93wCfbLi1kzpbWKMj VQ2ATo/lDgL11syIRgQQEQIABgUCSUAB7gAKCRAhutq7vyRCTOHaAJwPIbDOF9bC orHryY/u48uPcXOqqwCfYwqAF8qaSzhkaPK2CFkfVVbKhK65Ag0EST//sRAIAISc /3f41mVRM9aw/pNADIGTajm/HwBm89fxUpV8/8dG2oQu6BLMXEWjwMweqWDDQDi7 dYzy+/TpTmyB7x9ELrZi8n89E0Z1nII1CnhCtak+yNf2I9rgk4FrDmfjIfB8UZD/ zHtKVdrACw7pBZAawfeg0NXZoaqroDXvRke+s7TEHZ2N+hRkhsdztqTy0Dz2/HMJ fOV/DEwhM8LtU83ZyiFLioLZvKJINc8JMSX3PwUOgqeig3JwBPGlrzF/H8gdZ4Og k8nlfQOafoSc6UI99BzKh+VcJJgyJH4utWD26Xpni7TS0W/pWeL0Kz126BU87ucc TW7D/vGkzBfP3UjOFQMAAwYH/RSkEuOtEu2u9x29ZsvFuN076Ef+3r5YmAOH0EBt KJfIWPSivEbGtrE4/VgoESIX8/jpnG2XhFxOB79AOBUw7UHyF2uo9FtwQdv0N/Do Wjcgr/v+Ex874HjBF4yocy2jU36efAM+Yy8G0N9pM2ZA59YDXQsUf1XX56m37fV5 LCkSbdfBNVJcWZJTczrTZIq+JdGT0hwiaQISd7QCVAQ78/X1k+en8Tzbo35+KOdB FjDu4xjCA9H2W9MVK6ztBJNcfF0P/5dA57v0BFiEn/+BxNhGizv74joI3dcctP4L A1d83xIm6AodmbaG1Rvgbx48uU0BSZj3vK3POqEoHQ2b4OCITwQYEQIADwUCST// sQIbDAUJACTqAAAKCRDElT8+Z8sSYgE4AKCao/vj8qRc4Egxh7R+xKBRUhMLsACf S82/N6RTpAqhnFrj1WAqa+72eHk= =n/Xz -END PGP PUBLIC KEY BLOCK- -- Elvis is my copilot. Cal Keegan 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: call for seconds: on firmware
On Sun, Nov 16 2008, Stefano Zacchiroli wrote: On Sat, Nov 15, 2008 at 04:24:18PM -0800, Russ Allbery wrote: Hm, no, the impression that I got from this discussion that at least several people here think the result of Further discussion is: Let me observe that the fact that several people here think is not authoritative. That said, I disagree with point (ii) of your interpretation: i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iV Do we modify foundation documents: No v Do we override foundation documentsNo it should rather be Yes: ii Do we allow the Release Team to ignore SC violation bugs: Yes Rationale: with further discussion nothing changes. Today RMs are empowered, by delegation, to decide upon transitions and lenny-ignore tags. It will be the same tomorrow if further discussion wins. What they are not empowered to do is to decide to release with DFSG violations in main. If you think there is such a powere delegated to them, you need to show that these powers are there with the DPL in the first place, or that they belong to the RM. So, sure, they can ad whatever tags they wish to the BTS. But the release Lenny woth stuff the SC says we will not have in the Debian system, sorry, no. If people disagree with that, they can overrule delegates' decision as supported by our constitution. Err, it should not come to that, since they would be exceeding their authority in the first place (releasing something that the SC says Debian shall not). BTW, this is yet another hint that separate ballots would have been better, because we are implicitly calling for another GR in some special case, but unfortunately Dato's proposal to split ballots doesn't seem to have gained enough momentum. We can have a spearate vote on what to do post lenny, if people still want that. But currently, with the issue on how to go about releasing lenny, all these proposals are related. manoj -- 'Tis true, 'tis pity, and pity 'tis 'tis true. Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_ 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: call for seconds: on firmware
On Sun, Nov 16 2008, Adeodato Simó wrote: * Manoj Srivastava [Sat, 15 Nov 2008 17:38:56 -0600]: That does not seem to make sense. Either you have 'none of this non-free crap in the archive ever' or you have 'the release team downgrades these bugs and includes non-free crap' Not both. Which is why they are on the same ballot. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want to allow firmware in main independently of what the Release Team thinks? At this point, I think we should decide about Lenny. So the vote should be to allow firmware in main. We can then have another vote just about changing the SC to allow the rlease team to make Debian non-free when they so decide, separately. If you think such an option should be on the current ballot, please propose one, and call for seconds. So I suppose this is me saying there could be multiple votes, if sponsors so desire, but the release lenny vote has all the options on the ballot, since releasing Lenny can happen via any of these mechanisms. How does one vote, I want the Release Team to have freedom to use suite-ignore tags, plus I want Lenny not to be blocked by firmware issues even if the Release teams changes their mind and remove the lenny-ignore tags? So currently vote for what you want to happen for Lenny. We can have a different vote about changing the SC and the constitution later. I think we can be reasonably sure that the current spate of discussions is about releasing Lenny. For this action, any of the ballot options will have a distinct decision; and the ballot should have _all_ the possible courses of action for that decision. If, later, people want to try out changes to the SC/constitution, they can have their separate vote. Since we are in a hurry to release Lenny, the what to do with Lenny vote comes first. I'll be happy to run independent votes on any issue after that decision has been taken. I also think that the Lenny release hanging over our heads is tainting the discussion of the other options, but that is just my personal opinion. manoj -- It is easier to fight for principles than to live up to them. Alfred Adler 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: call for seconds: on firmware
On Sun, Nov 16 2008, Josselin Mouette wrote: Le samedi 15 novembre 2008 à 19:39 -0600, Manoj Srivastava a écrit : Hm, no, the impression that I got from this discussion that at least several people here think the result of Further discussion is: i Do we require source for firmware in main: Yes ii Do we allow the Release Team to ignore SC violation bugs: No iii What do we do for Lenny: Wait iV Do we modify foundation documents: No v Do we override foundation documentsNo and that seems to be consistent with what Manoj is ruling about overrides of the SC. This is my reading, yes. As far as I see, the SC is pretty clear, and leaves us no other option. It seems very convenient to decide at the same time that further discussion equals proposition #1 and that other propositions require 3:1 majority. This means that, if proposition #1 fails to gather 1:1 majority and other propositions fail to gather 3:1 (a very likely outcome), you get to decide that proposition #1 applies anyway. It makes me feel uneasy. The decision comes from here: ,[ The Debian Social Contract ] | | 1. Debian will remain 100% free | | We provide the guidelines that we use to determine if a work is | `free' in the document entitled `The Debian Free Software | Guidelines'. We promise that the Debian system and all its | components will be free according to these guidelines. ` ,[ The Debian Free Software Guidelines (DFSG) ] | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. ` ,[ The Debian Constitution ] | 1. A Foundation Document is a document or statement regarded as | critical to the Project's mission and purposes. | 2. The Foundation Documents are the works entitled `Debian Social | Contract' and `Debian Free Software Guidelines'. | 3. A Foundation Document requires a 3:1 majority for its | supersession. New Foundation Documents are issued and existing | ones withdrawn by amending the list of Foundation Documents in | this constitution. ` So, really, we cannot release programs (firmware) in main without source code just because a few delegates think we should. We can make the argument that the blobs have not been proven to be non-source code; however unlikely that is, and turn a blind eye to the unlikelyness of them being actual source code while we release lenny, or we can change or supersede the foundation documents, temporarily or permanently. manoj -- Only the hypocrite is really rotten to the core. Hannah Arendt. 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: call for seconds: on firmware
On Sun, Nov 16 2008, Steve Langasek wrote: On Sun, Nov 16, 2008 at 11:42:19AM -0600, Manoj Srivastava wrote: I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. The proposers and sponsors of option 5 didn't propose this as an amendment to the current GR. Why should they have to *withdraw* the proposal in order to get it considered separately at a later time? They only need to do so to prevent it from being on the current ballot. I think it would be a pity of any of the 6 options is withdrawn, since any of them could lend us relief from the current mess wrt Lenny release. As to future votes, anyone may propose a failed option on any vote for a fresh look anytime they so desire. manoj -- Our business is run on trust. We trust you will pay in advance. 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: call for seconds: on firmware
On Sat, Nov 15 2008, Adeodato Simó wrote: Peter Palfrader's proposal [1] explicitly said, and I quote: | I'm hereby proposing the following general resolution. I don't think it's acceptable to bundle it up with the ongoing GR, since it was not proposed as an amendment to it. I have explained why I think all these proposals are related (they all affect releasing lenny while kernels contain firmware blobs, and some of the solutions have effects that are more far reaching than others). Since they are related, they belong on the same ballot -- even if they were not all formally declared to be amendments of the original proposal. Our voting methods do not deal well with related options being on separate ballots. manoj -- Imitation is the sincerest form of television. The New Mighty Mouse 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: call for seconds: on firmware
On Sat, Nov 15 2008, Adeodato Simó wrote: ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and free software. We don't trade | them against each other. However during getting an release out of the | door, decisions need to be done how to get a rock stable release of the | high quality Debian is known for, release more or less on time, and to | minimize the usage of problematic software. We acknowledge that there | is more than just one minefield our core developers and the release | team are working at. | We as Developers at large continue to trust our release team to follow | all these goals, and therefor encourage them to continue making | case-by-case-decisions as they consider fit, and if necessary | authorize these decisions. | (Since this option overrides the SC, I believe it would require 3:1 | majority) Also, this one should not be voted together with the rest, since it's an orthogonal issue. This not /exclusively/ a solution for the problem for Lenny. We can ask the proposer of this option what he thinks, if you don't agree it should be split out. While some of the proposals have longer lasting effects than just the current release, they are still related: for example, the proposal singled out above, if passed, would make proposal 5 moot, and invalidate proposal 1. Given that these proposals are strongly related, they should be on the ballot together. Post Lenny, if we do want to change our foundation documents, we can try and do so; but splitting out options on how to handle the release of lenny in view of firmware blobs, and the apparent conflict with the SC, would result in a botched decision. Serial votes with subsets of options really lend themselves to tactical voting our voting method is not designed to deal with. manoj -- Screw up your courage! You've screwed up everything else. 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: call for seconds: on firmware
On Sat, Nov 15 2008, Stephen Gran wrote: This one time, at band camp, Manoj Srivastava said: On Sat, Nov 15 2008, Adeodato Simó wrote: | We as Developers at large continue to trust our release team to follow | all these goals, and therefor encourage them to continue making | case-by-case-decisions as they consider fit, and if necessary | authorize these decisions. Also, this one should not be voted together with the rest, since it's an orthogonal issue. This not /exclusively/ a solution for the problem for Lenny. We can ask the proposer of this option what he thinks, if you don't agree it should be split out. While some of the proposals have longer lasting effects than just the current release, they are still related: for example, the proposal singled out above, if passed, would make proposal 5 moot, and invalidate proposal 1. It's not possible to express the full set of relations in a single winner vote, as far as I can tell. It might be someone's vote to say 'none of this non-free crap in the archive ever' and simultaneously say 'but the release team does have the authority to downgrade these bug reports if they need to'. Unless I've missed something and we're planning on having a multi winner vote, That does not seem to make sense. Either you have 'none of this non-free crap in the archive ever' or you have 'the release team downgrades these bugs and includes non-free crap' Not both. Which is why they are on the same ballot. Frankly, at this point, we are trying to get the issue of Lenny release with or without firmware resolved. All the options do that, in one way or the other. Some options are temporary displensations, other are far wider ranging than that. Arguably, we might want the wider ranging changes _anyway_, but that might not happen if we can get lenny released by an other option. In that case, we can re-raise the issue post lenny, independently, and not get the vote get all tangled up with trying to release lenny. If we are trying to change foundation documents not in the context of releasing lenny, I think we need a good debate on the merits of each proposal, not an accelerated one trying to resolve the lenny issue. But all the related proposals will solve the lenny release, so I think it is justified to put them on the ballot about what to do with lenny. manoj -- Success in management--at any level--depends on the ability to pick the right people for the right jobs. 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: Re-thinking Debian membership
Hi, One of the issues I have with this proposal is that there seems to be, by design, absolutely no consideration about skill levels or quality of developers. I'll concede that the current process might not do a great job of assessing quality of contribution, but it tries. The new process does not seem to have any such effort. Given human nature, seems like it is likely for folks to vote in their buddies, not based on merit, but on liking them (do you know how hard it is for people to not add friends to their social network sites?) I also acknowledge that testing for quality is a Hard Problem. And that it is hard not to have a process with the kind of bias that inclusion by popularity contest (which the new process would have a proclivity to being) does. But there is an effort towwards that in the current process that is being thrown out with the bath water. manoj -- The Arkansas legislature passed a law that states that the Arkansas River can rise no higher than to the Main Street bridge in Little Rock. 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: Re-thinking Debian membership
On Sat, Oct 25 2008, Andrei Popescu wrote: On Sat,25.Oct.08, 00:36:06, Aurelien Jarno wrote: My point is that if your only activity in Debian is periodically answering an automated email, I don't see the point of staying member of the project. How about this: every Debian Member chooses his own method of stating I am active in the Project. For a packager this could be an upload, for a translator it could be a new/updated translation (either by commit to a VCS or by sending it to some public mailing list),... whatever makes him so important for the Debian Project as to retain his membership. No. Activity must mean something concrete, Just sending email is not concrete evidence of actually doing something. Since liw defined voting and package uploads as defining characteristics of a developer, I posit that those activities are the only things that make sense about maintaining an active status in the project. If you are not voting or uploading packages, everythign else you do can be done without a maintainers hat on, so you do not need to be a DD. manoj -- Mr. Spock succumbs to a powerful mating urge and nearly kills Captain Kirk. TV Guide, describing the Star Trek episode _Amok_Time_ 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: Re-thinking Debian membership
On Sat, Oct 25 2008, Josselin Mouette wrote: Le samedi 25 octobre 2008 à 01:12 -0500, Manoj Srivastava a écrit : One of the issues I have with this proposal is that there seems to be, by design, absolutely no consideration about skill levels or quality of developers. I'll concede that the current process might not do a great job of assessing quality of contribution, but it tries. The new process does not seem to have any such effort. On the contrary, peer review is the only process we have today that correctly asses quality. Require DD endorsement to be justified, as well as the veto, and you’ll get a picture of the skills of the candidate. Then I would like to see some language like this added to the proposal. If for nothing else, then to dispell the spectre of a bunch (cabal, if you prefer) DD's just inviting their cronies into Debian, by lowering the bar on skill levels. I also think there might be the facebook/social site effect: without the active requirements on advocacy (the justification you talk about), people can feel pressurred to advocate (I get all these link request on linked in. some from people I have no idea about. I have rejected two or three of these things, but usually I just vote to let them in into my circle of friends. Why? because the cost of saying yes is so low, and I do not want to piss off someone who might later be in a position to help me [think DAM]). Now, I might be getting too paranoid about potential for cronyism (am I channeling Clint?), but I do think some language should be added about the voting. There should be, for example, required sections about skill sets, and how the advocate personally knows about it, sections on previous work done for debian, and a section on collegiality (he gets along well, does not blow his top). I think such clarifications on the justification for voting in or vetoing would improve this proposal. manoj -- Ed Sullivan will be around as long as someone else has talent. Fred Allen 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: 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: Re-thinking Debian membership
On Fri, Oct 24 2008, Michael Hanke wrote: The keyring does not have to be exposed directly. It could work via a delaying queue or stanging area. Changes commited to be applied to the keyring could be made publicly available for peer-review. This would make it possible that any change could be veto'ed by any other project member during the delay period. Who takes the action to expose the modified keyring? If it is still the DAM. then this is not very different from sending email, and letting DAM take the action of updating the exposed keyring. The changes, then, are: a) other people may undertake the task of modifying the keyring. This could be a good thing, in reducing the load on the DAM, and it can be a bad thing, if less experinced folks flub the change and mess up the keyring. b) Everyone can see what the pending changes are. c) It would perhaps make it harder for the DAM to cherry pick the changes people have made. manoj -- What the scientists have in their briefcases is terrifying. Nikita Khrushchev 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: Re-thinking Debian membership
On Fri, Oct 24 2008, Lars Wirzenius wrote: I believe, very strongly, that the important distinction between someone who is a member of Debian and someone who is not is that the member may vote in Debian matters. Further, I do believe that being able to upload packages is another very fundamental right for a member in the Debian project: our operating system is divided into packages, and development of the system is what we do. * Membership in the project gives both voting and upload rights. * Membership ends 24 months after they're given, or after the latest participation in a vote arranged by the project's Secretary. Members may retire themselves earlier, of course. Given the above, retention of membership should be dependent on a vote and/or package uploads, since those are the defining characteristics of a developer. Sending an email should not count, since anyone may send emails, and if you are not exercising your rights as a DD, you do not need to be one. * Members may be expelled via the normal General Resolution process, with a simple majority. Ftpmasters may temporarily limit upload rights in an emergency. So expulsion by DAM's is a power you are proposing to remove? Or is this in addition? manoj -- Football is a game designed to keep coalminers off the streets. Jimmy Breslin 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, 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 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: NEW queue
On Thu, Oct 23 2008, Clint Adams wrote: In my opinion, however, you have this backwards. The release team members (and this goes for any other core team as well) have privileges which are withheld from the other developers for whatever reason, and they have been granted such privileges presumably to serve the project, not as some kind of reward or recognition for merit or industrious service or brownnosing. I imagine that these people have either explicitly pursued this power or that it has been offered to them and they have explicitly accepted. Such conscious and willful acts should have been coupled with conscious and willful acceptance that with this power comes great responsibility. This responsibility is not as a parent or caretaker for misbehaving ingrates, but to serve every single DD who lacks those powers. The This is where you got this wrong. The responsibility is to serve the project, and the foundations on which the project is built, to the best of our ability. Me undertaking to do more work (mostly thankless) is not to become the servant of people who opt to do less, but to ensure that the project benefits. feelings of the privileged people should be secondary to the feelings of the unprivileged people. Their actions should be extremely transparent and subject to review. This includes not having secret back-room discussions about project business. This would hurt the project, so I am not going to do it. I have gained a lot of advice from seeking out experts, and having a one one one discussion focussed on improving the work I do for Debian, to forgo the quiet discussions and advice seeking for tasks that I perform for Debian. Some of these flow naturall while socializing, and I will not eschew discussions about Debian as I meet fellow DDs over a beer. Now if you were suggesting that we should all be civil to one another, I would have a different argument, but what I infer from your words is that we owe the release team more because of the work that they do. The inverse is true: the release team owes us more because they CAN do the work. I think that is nonsense. In my mind I can't conceive of why they would have willingly accepted power if they weren't prepared to face the highest scrutiny and criticisms. Can you? I have no intention of dealing with harsh and unpleasant language, if people can't converse with me civilly, I have the recourse of a score file. I don't _have_ to do anything; inclusing listening to rude ingrates (:=)). So, if the DAM or the RM's are not doing their job as You want them to do it, you have a few options: a) convince the DPL to delegate you instead of them b) to more work, and get into a position where the work you do makes people lsiten to you instead, c) pay them to listen to you d) find enough like minded people to override them via a GR manoj -- He laughs at every joke three times... once when it's told, once when it's explained, and once when he understands it. 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: NEW queue
On Thu, Oct 23 2008, Pierre Habouzit wrote: On Thu, Oct 23, 2008 at 02:09:23PM +, Manoj Srivastava wrote: This is where you got this wrong. The responsibility is to serve the project, and the foundations on which the project is built, to the best of our ability. Me undertaking to do more work (mostly thankless) is not to become the servant of people who opt to do less, but to ensure that the project benefits. I disagree. You imply that people outside of teams are doing nothing, and beside that it's quite interesting that you think so in itself, it's wrong. There are many people doing a lot for Debian, that have no access to the powers that the release team have, and we do have to make sure we don't impede those people's work. I did not say that, and your deducing that was my implication is jumping to unwarranted conclusions. So people are doing things for Debian that I am not. That does not give me the right to tell them what more they can do. And vice versa. While no one else has the right to tell me how I spend my time, or do my work, I do not have the right to tell them how not to do things. If I vett my plan of work with some people, that is not wrong. If I am talking to people about how to convert policy docs to docbook, and what works, and what does not, it is not wrong. When I write code for devotee, I make the design decisions. I would be silly not to seek and listen to feedback, but that does not mean I cede the coherent design decision making to the hordes. manoj -- Reputation, adj.: What others are not thinking about you. 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 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: Developer Status
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. 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. manoj -- Just about every computer on the market today runs Unix, except the Mac (and nobody cares about it). -- Bill Joy 6/21/85 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: Request for data about development
On Wed, Oct 08 2008, Katharine Anderson wrote: Hi-- My name is Katharine Anderson, and I'm a researcher at the University of Michigan, in Ann Arbor. My work looks at collaboration and problem solving. I'm currently working on a paper that looks at the structure of collaboration networks. I'm looking at how people with diverse skills group together when solving problems, and it occurred to me that the open-source software community is a perfect example of the phenomenon that I'm interested in. I was wondering if there was any way that I could get data on participation in development groups? Is there someone who I could talk to about that? Most of the development efforts are on the mailing lists: http://lists.debian.org/ The lists are divided by the areas of activity. You can look at the archives of the mailing lists there as well. You might also want to look at http://wiki.debian.org/, which holds some other aspects of the collaborative work. Hope that helps. manoj -- It's hard to keep your shirt on when you're getting something off your chest. 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: Debian and non-free
On Wed, Sep 17 2008, Bas Wijnen wrote: On Wed, Sep 17, 2008 at 10:38:21AM -0700, John H. Robinson, IV wrote: Michael Banck wrote: On Wed, Sep 17, 2008 at 08:24:52AM +0200, Martin Schulze wrote: Non-free is for GNU documentation. I think we should consider (post-lenny) splitting up non-free in a couple of sub-categories. Personally, I'd prefer fsf-free, but non-free-docs would be just as good, besides non-free-firmware and non-free for the rest. I like this idea, but without mentioning FSF directly. More entities than just the FSF use the GNU FDL for licensing. I would much prefer to mention the FSF directly, actually. Not because it's about their software (or documentation), but because it's about their opinion about what is free. So we get: - main (dfsg-free) - fsf-free (non-dfsg-free, but free according to fsf) - non-free-firmware - non-free (for all other classes) I think that dilutes the message that those packages are non-free, and reduces pressure on the authors to release the documentation under a free license. main non-free programs documents firmware art-work games manoj -- If a man has done evil, let him not keep on doing it. Let him not create an inclination to it. The accumulation of evil means suffering. 117 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: DEP1: how to do an NMU
On Sat, 31 May 2008 12:20:55 +0200, Lucas Nussbaum [EMAIL PROTECTED] said: Steve, Manoj, Charles, Richard, does this address your concerns? If not, can you propose some additional changes? This new version does sound a lot better. manoj -- If voting could really change things, it would be illegal. Revolution Books. New York, New York. 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: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Sat, 31 May 2008 09:13:43 +0200, Lucas Nussbaum [EMAIL PROTECTED] said: On 30/05/08 at 17:28 -0500, Manoj Srivastava wrote: For the record, I don't think that we should remove the language about informing the maintainer with a mail message; and no, I don't think we quite have a consensus on this yet. The DEP currently addresses communication like that: When doing an NMU, you must always send a patch with the differences between the current package and your NMU to the BTS. If the bug you are fixing isn't reported yet, you must do that as well. I have several questions about the requirement for communication that you want to add: - Do you want to require two-way communication? There should be some time for a response to come in, but I don't think I want the NMU to have to wait on the maintainer. But apart from the patch, there should be a clear indication of an intent to NMU. - If the maintainer doesn't answer, how much time should the NMUer wait for the maintainer, in your opinion? I think the maintainer should be given a reasonable time to respond, for some value of reasonable. All this also depends on whether the maintainer is active or MIA, and how sever the bug is, and how complex the fix would be. You are aiming for not lower the enthusiasm of the NMU'er by adding delays, but I think we should also be looking at quality of NMU's, and consulting and cooperating with the maintainer, who probably has more experience with the package, rather than just getting the NMU in. Perhaps my experience is soured by a recent pointless *sponsored* NMU to one of my packages (admittedly for a RC bug), with no mail, no patch to the BTS, and one which failed to fix the problem (so there was no testing done, faugh). - Are the delays that are strongly recommended in the DEP really too short, in your opinion? I think so. When I have NMU'd a package, it has been with a lot of thought, consulting with the maintainer, offering to help, and then it still took a week or so to familiarize myself with the package to do a goods job of testing. And then I was fully subscribed to the package, and felt responsible for any bug opened until the next upload. I think that is the right option; hurrying changes into the archive for enthusiasm does not feel right. The activity level of the maintainer, th degree of familiarity with the package by the NMUer. the complexity of the bug/solution, should also be factored in. Even if we can not give a numerical value to the effect these have, we can add language that says that the NMUer should take those factors in consideration before deciding to pitch right in or not. The current wording requires a notification (by sending a mail to the BTS). I don't think that it's a good idea to additionally require that this mail should be sent to the maintainer's private email address, because that doesn't work well with co-maintainance. A mail with an intent-NMU made clear would work, I think. Not just a patch; The current wording doesn't require the NMUer to wait for an acknowledgement. Instead, it strongly recommends to give some time to the maintainer, which doesn't make a big difference ... I think I would state it that the maintainer must be given time to respond, but there can be extenuating circumstances (security fixes, etc), and the severity of the bug and the simplicity of the fix can have the window slide shorter or wider. The bottom line, of course, is the quality of the distribution; and the trade off between getting fixes in, versus getting the fixes in vetted by someone experienced with the package -- and weighing in whether the NMUer has experience with the are or not. (joeyh can NMU my packages any time, with or without any notice; the people who NMU'd my package recently should refrain from touching my packages until they get a response from me). manoj Not everything is Black or White -- A child miseducated is a child lost. -- John F. Kennedy 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: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Fri, 30 May 2008 08:25:34 +0200, Lucas Nussbaum [EMAIL PROTECTED] said: On 29/05/08 at 17:47 -0700, Richard Hecker wrote: The goal of the DEP is precisely to replace this section 5.11, and change the usual NMU rules. That's why it's submitted as a DEP (to allow broad discussion), not as an obscure patch to devref :-) I think that not communicating with the maintainer is not a desirable change to the document. Some people will prepare a NMU without even sending an email to the maintainer. They will claim that this was 'done by the book.' As long as the NMUer sends all the information to the BTS, I'm perfectly fine with the NMUer not sending a private email to the maintainer. (and I think that there's consensus about that) For the record, I don't think that we should remove the language about informing the maintainer with a mail message; and no, I don't think we quite have a consensus on this yet. manoj -- If you waste your time cooking, you'll miss the next meal. 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]
Debian Project Leader Election 2008
Hi folks, It is almost that time of the year again. Indeed, it is later this year, since we had a GR last year shortening the time intervals for the election -- nomination 1 week, campaign/discuss 3 weeks, and vote 2 weeks. Here is the tentative time line: | Period | Start| End | |+--+--| | Nomination | Sunday, March 2nd, 2008 | Sunday, March 9th, 2008 | | Campaign | Sunday, March 9th, 2008 | Sunday, March 30th, 2008 | | Vote | Sunday, March 30th, 2008 | Sunday, April 13th, 2008 | Given that we have a short nomination period, I'd suggest that potential DPL candidates start getting their platform ready, and that the submission date for the platform be early in March, since the platforms and rebuttals should be in place before the debate. So I would suggest the platforms be turned in on Sunday, March 9th, and the rebuttals a week later on Sunday March 16th. Also, people who are willing to conduct the annual Debates will have less time to coordinate and plan, since the nomination period has been shortened, and the debate would need to be held in the later part of march. manoj -- VMS is like a nightmare about RXS-11M. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpyIwoU5SP7l.pgp Description: PGP signature
Re: About spam in the list archive
On Mon, 12 Nov 2007 00:24:19 +0100, Thomas Viehmann [EMAIL PROTECTED] said: Hi, if people are interested to spam-removal happen, I am looking for help testing how this would work. You need - a GPG key that is somewhat close to the Debian keyring, - to look at hundreds of messages that induced people to click on this is spam button and sort them into spam, not spam, misguided (e.g. unsubscribe requests and vacation messages), and unsure with a bias towards not spam and unsure, - python2.5 installed (available in stable/testing/unstable). You get - a (probably buggy) console program to show you mails and ask for your opinion, - a largish mbox file (for debian-project it is 6M uncompressed / 2M compressed) with the messages, - a chance to do something about the spam in our web archive. Maybe we could start with debian-project at the present and go back in time from there until we get bored, but I'm open to suggestions. Hmm. I'll be happy to help automate some of the decision making using my Spam classification mechanisms; please look at http://www.golden-gryphon.com/software/spam/crm114_accuracy.html to see the lower bound on accuracy I get from (mostly) Debian email. Adding SA to the CRM114 results above gives about 99.92% accuracy overall -- and crm114 has had 100% accuracy in identifying Spam in the last two years I have been using it. It would be interesting to see how many messages escape my filters, and give me an opportunity to further train them. All I need would be the mbox file; and for me to setup a process to feed the email to the filters, and classify the result -- and then send back the message ID's of Ham and Spam back to Debian. manoj -- Beware of a dark-haired man with a loud tie. 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: About spam in the list archive
On Wed, 14 Nov 2007 16:51:42 +0100, Thomas Viehmann [EMAIL PROTECTED] said: Hi Manoj, If you have suggestions how automatic testing can be incorporated into the a spam-removal process in a way that is acceptable to the project, I'd be very happy to seem them discussed here. However I'm not sure that the bias that we (there are six people currently seeing how things work) currently impose in our manual review can be very well implemented in software. What to do with sponsorship request spam from people claiming to be students or clans, what to do with foreign language spam that people reply to with translation and the explanation ignore, this is spam, what to do with the reply? If you can get a corpus of past messages from people claiming to be students or clans, we can fine tune a crm114 filter to identify these mails. Given the narrow range of the messages we are classifying, I am pretty sure that the number of unsure/retrain messages that humans need to ponder over can be reduced by 2-3 orders of magnitude. There is no reason to only have one filtering pass; especially since we are not dealing with a streaming incoming mail. My take on this is that we automate the process by passing the unknown mbox through the crm114+SA filter, and classify the mail into Ham, Unsure, and Spam. The Unsure would be manually inspected, and used to further train the filters; as well as any erroneous classification (TOE). Periodically, we TUNE (Train Until No Error) the Corpus. Hey, if this works as well for list mail as it does for me (and my email is mostly Debian list mail), it might even work to filter incoming mail. But we'll see. It would be interesting to see how many messages escape my filters, and give me an opportunity to further train them. All I need would be the mbox file; and for me to setup a process to feed the email to the filters, and classify the result -- and then send back the message ID's of Ham and Spam back to Debian. There is a couple of almost-mboxes linked from [1]. Before the first From there is a mbox-like header but from there on it is a regular mbox archive consisting of the nominations. Preliminary results indicate that around 2/3 of the submissions for debian-project are actually removal candidates (based on review by pabs and me, there are others looking at the same things). The information in the initial headers should be fairly self-explanatory, the number besides year, month, and message number is the number of times this a message was reported as spam. I can easily put up more of these, of course, just tell me what you want. (There are ca. 9 nominated messages, it is unclear to me whether old data is equally usable as newer.) I can try setting up infrastructure to classify a mbox (create a new user, write a simple script to parse mbox, feed mails to crm114+SA, and use mailagent to filter into ham, Spam, and unsure). I have a dog-and-pony show coming up Dec 3rd, so I might not be very responsive, at least until I am sure my software is working, but I'll grab a mbox and see what the results look like. If the setup is mostly working, future mbox's can be handled mostly automatically. If you have a human scanned set of list mails known to be Spam, or known to be ham, etc, I can use those either to augment my Corpus, or to use in place of my personal Corpus, to better reflect your judgement of what is or is not Spam. manoj -- Time flies like an arrow, fruit flies like a banana. Frequently attributed to Groucho Marx 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: Planet policy?
On Wed, 08 Aug 2007 05:33:22 +, Lars Wirzenius [EMAIL PROTECTED] said: It strikes me, though, that if there's interest, setting up an pure.debian.net with feeds strictly restricted to those that discuss Debian matters only, should be pretty easy. Anybody interested in subscribing to it? Not really. I already read -devel, -project, and a bunch of other lists, and have a surfeit of Debian content. Getting to know the people who bring us Debian, ah, that's far more valuable. manoj -- Don't you wish that all the people who sincerely want to help you could agree with each other? 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: Planet policy?
On Sat, 04 Aug 2007 14:16:05 -0300, Otavio Salvador [EMAIL PROTECTED] said: Steve McIntyre [EMAIL PROTECTED] writes: Did we ever agree a policy about what's acceptable/reasonable for blog feeds linked from planet.d.o? I'm very tempted to disable Ian Murdock's Solaris propaganda, for example... Thoughts? I agree on disabling his blog since it has nothing related to Debian on it, anymore. Why are we concentrating on Ian? Why is no one complaining about Clint's blog, which far from having anything to do with Debian, is not actually related to anything in this universe, as far as I can tell? Or any of a number of other people who are blogging about their lives, and often, Debian is a small portion of their lives (aka people with real lives)? If people want to read posting about technical issues or Debian itself, I suggest they subscribe to [EMAIL PROTECTED] The Planet exists to let us see into the lives of people important to Debian, not to be a monologue replacement of -devel. manoj -- Eternity is a terrible thought. I mean, where's it going to end? Tom Stoppard 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: Need of non-germany-tree in Debian?
On Fri, 06 Jul 2007 19:26:44 +0200, Malte Hahlbeck [EMAIL PROTECTED] said: What would be the consequence? Will there be the need of a non-germany-tree in the Debian Repositories? I think this should only affect german mirrors, which could filter out those packages. The reason we needed a non-us machine was that master lives in the US, and has to adhere to US law; and so a simple filter would not have worked. While this is an unfortunate development, I do not think it requires the formulation of a non-german hierarchy. manoj -- When you say 'I wrote a program that crashed Windows', people just stare at you blankly and say 'Hey, I got those with the system, *for free*'. -- Linus Torvalds 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: soc-ctte discussion at DebConf7
On Sun, 1 Jul 2007 22:54:53 +0200 (CEST), Andreas Tille [EMAIL PROTECTED] said: On Sun, 1 Jul 2007, Manoj Srivastava wrote: I am not talking about _not_ having a soc-ctte. I am talking about whether or not the selection criteria for ctte members needs to be looked at with due consideration to the cultural diversity. I'm afraid that we will have not enough volunteers from different cultures. This might well be the case. But I can see where an informed electorate can make a different decision for party selection if they keep cultural diversity in mind. So the practical solution might be as simple as adding a note to the charter of the soc ctte admonisng them to be aware of these issues; and for the entity selecting members to also be aware as well. Moreover it is hard to separate between different cultures. There is no sharp borderline between cultures and there are people who belong to more than one culture. While boundaries might be blurred, let me assure you that the cultural background in Tennessee is distinctly different from that in the Scottish highlands, and palpably so; and both are a world apart from the culture of nothern India. So this is a quite weak criterium to choose members for a soc-ctte from. I dunno. I think there is a wide diversity in cultural norms and expectations (the news headlines scream with the effects); and just because there are crossovers and individuals and families who straddle the divide is no reason to pretend that the differences do not exist, or can not be catered to. I think I understood perfectly your concerns - but I see no practical solution. I just hope that a soc-ctte that is elected according to the rules we mentioned will be able to understand social aspects that are brought up by a person who has the kind of trouble you have in mind. Well, the re are practical solutions, and there are practical solutions. Let not the perfect be the enemy of an adequate solution. While we might never be able to get a perfectly unbiased, culture neutral and yet culture sensitive soc ctte, as you rightly fear; we can still add language to the charter of the soc ctte to remind the members of this aspect of their duty long after this conversation has been forgotten. Based on recent conversation in the list, I would suggest that the proportionality criteria for party list selection be given emhpasis for electing the members, so the minority cultures do not fail to have representation on the ctte, drowned our by the dominant cultural subgroups. Just for the sake of interest: What would you say to which cultural group you would belong? Me? I belong to the modern diaspora of migrants stuck between diverse cultures, belonging perfectly to neither. I think modern migrants like me are often better at recognizing two vastly different, and often opposed, but equally valid takes on issues that our social and cultural sets take. And no, you do not want me on your soc ctte. manoj -- He whose path devas, spirits and men cannot know, whose inflowing thoughts are ended, a saint - that is what I call a brahmin. 420 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: soc-ctte discussion at DebConf7
On Sun, 01 Jul 2007 13:28:00 +0300, Kalle Kivimaa [EMAIL PROTECTED] said: Josip Rodin [EMAIL PROTECTED] writes: + li If the election requires multiple winners, the list of winners is + created by sorting the list of options by ascending strength. Why couldn't we just use some STV method for such elections? STV is a tried and proved method, no need for us to start inventing new methods. Most traditional STV methods suffer from free riding (in which strategic voting as in not voting for people who you want to vote for, but who will, in your opinion, win anyway) and vote management. There is a modified STV method, that also satisfies the condorcet method, and falls back to our current mechanism for a single winner. Our current method has been demonstrated to satisfy Pareto, monotonicity, resolvability, independence of clones, reversal symmetry, Smith-IIA, Schwartz, Woodall's plurality criterion, and Woodall's CDTT criterion, etc. I think we should consider the paper pointed out by Antti-Juhani Kaijanaho, found at http://m-schulze.webhop.net/schulze2.pdf manoj -- There are no saints, only unrecognized villains. 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: soc-ctte discussion at DebConf7
On Sat, 30 Jun 2007 22:17:27 +0200 (CEST), Andreas Tille [EMAIL PROTECTED] said: On Fri, 29 Jun 2007, Manoj Srivastava wrote: In other words, we share a common technical culture. This is not the case for social culture of the community; and this distinction would tend to make a difference, in my opinion. Well, we discussed it in private at DebConf (when I lost my live in an assassin attack ;-)). I wonder in how far you think different cultural aspects are regarded if there is no social committee at all. Not very much, if at all, I would imagine. So we have the choice to do either nothing against social problems in Debian or just give a soc-ctte a chance to try - your comments about the cultural diversion might be a helpful guideline here - but in my opinion no argument against a soc-ctte. Why does everyone see any discussion at all in the mailing list a binary, either-or, confrontational debate? I am not talking about _not_ having a soc-ctte. I am talking about whether or not the selection criteria for ctte members needs to be looked at with due consideration to the cultural diversity. Based on recent conversation in the list, I would suggest that the proportionality criteria for party list selection be given emhpasis for electing the members, so the minority cultures do not fail to have representation on the ctte, drowned our by the dominant cultural subgroups. manoj ps: is it so hard to believe that people who actually want to improve a proposal are not all rah-rah cheer leaders for the idea? Or that all skeptics are not locked in a life-or-death struggle to scuttle the proposal? -- Experiments must be reproducible; they should all fail in the same way. 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: Multi-winner elections, soc-ctte
On Sat, 30 Jun 2007 16:16:40 +0100, Anthony Towns [EMAIL PROTECTED] said: On Sat, Jun 30, 2007 at 10:00:47AM +0300, Antti-Juhani Kaijanaho wrote: On Fri, Jun 29, 2007 at 02:43:24PM -0500, Manoj Srivastava wrote: It should be relatively straight forward for Devotee to find the winner, take the winner out of contention the next round, find the next winner (ignoring any pairwise contests dealing with any candidate no longer in the contest), and continue until the number of candidates desired has been reached. This is no doubt true. As I mentioned in another mail, this procedure does have the problem of not delivering proprtional results. A scenario. A simpler scenario. OK, color me convinced. I am now trying to wrap my head around the stuff found at http://m-schulze.webhop.net/, and see if I can implement some of the methods mentioned there. I haven't had to plough through so much math since grad school. manoj -- I'd love to go out with you, but I did my own thing and now I've got to undo it. 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]
