Bug#461883: ITP: venus -- aggregate feed generator
Package: wnpp Severity: wishlist Owner: Noah Slater <[EMAIL PROTECTED]> * Package name: venus Version : 0.1 Upstream Author : Sam Ruby <[EMAIL PROTECTED]> * URL : http://www.intertwingly.net/code/venus/ * License : PSF Programming Lang: Python Description : aggregate feed generator Planet Venus is an awesome "river of news" feed reader. It downloads news feeds published by web sites and aggregates their content together into a single combined feed, latest news first. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.20.3-bytemark-uml-2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Noah Slater <http://bytesexual.org/> "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#461883: ITP: venus -- aggregate feed generator
On Mon, Jan 21, 2008 at 01:38:03PM +0100, Laurent Fousse wrote: > What's "awesome" about it? I think we need less (gratuitously?) > inflated description in debian. I lifted this description directly from the homepage: http://www.intertwingly.net/code/venus/ I completely agree with your point and was intending to edit and expand the description for the actual package. Appologies if you feel I should have done this for the ITP. -- Noah Slater <http://bytesexual.org/> "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461915: ITP: lockrun -- cron job overrun protection utility
Package: wnpp Severity: wishlist Owner: Noah Slater <[EMAIL PROTECTED]> * Package name: lockrun Version : 20080121 Upstream Author : Stephen J. Friedl <[EMAIL PROTECTED]> * URL : http://www.unixwiz.net/tools/lockrun.html * License : Public Domain Programming Lang: C Description : cron job overrun protection utility The lockrun utility serves as a protective wrapper around a standard cron job preventing it from overrunning with any previous invocation. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.20.3-bytemark-uml-2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Noah Slater <http://bytesexual.org/> "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463806: ITP: pgtop -- display PostgreSQL performance information like top
Package: wnpp Severity: wishlist Owner: Noah Slater <[EMAIL PROTECTED]> * Package name: pgtop Version : 0.04 Upstream Author : Jeremy D. Zawodny <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~cosimo/pgtop-0.04/pgtop * License : GPL Programming Lang: Perl Description : display PostgreSQL performance information like top pgtop is a console-based tool for monitoring queries and overall performance of a PostgreSQL database. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.20.3-bytemark-uml-2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Noah Slater <http://bytesexual.org/> "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#463806: ITP: pgtop -- display PostgreSQL performance information like top
On Sun, Feb 03, 2008 at 04:52:03PM +0100, Christian Perrier wrote: > I'd suggest to phrase this "PostgreSQL performance monitoring tool" or > any other way to avoid a verb sentence... Sure thing, sounds sensible. How about: PostgreSQL performance monitoring tool akin to top -- Noah Slater <http://bytesexual.org/> "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466368: ITP: cwm -- general-purpose data processor for the semantic web
Package: wnpp Severity: wishlist Owner: Noah Slater <[EMAIL PROTECTED]> * Package name: cwm Version : 1.2.0a2 Upstream Author : Yosi Scharf <[EMAIL PROTECTED]> * URL : http://www.w3.org/2000/10/swap/doc/cwm * License : W3C Programming Lang: Python Description : general-purpose data processor for the semantic web Cwm (pronounced coom) is a general-purpose data processor for the semantic web, somewhat like sed, awk, etc. for text files or XSLT for XML. It is a forward chaining reasoner which can be used for querying, checking, transforming and filtering information. Its core language is RDF, extended to include rules, and it uses RDF/XML or RDF/N3 serializations as required. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20.3-bytemark-uml-2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Noah Slater <http://bytesexual.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466728: ITP: python-trio -- RDF utilities
Package: wnpp Severity: wishlist Owner: Noah Slater <[EMAIL PROTECTED]> * Package name: python-trio Version : 20080204 Upstream Author : Sean B. Palmer <[EMAIL PROTECTED]> * URL : http://inamidst.com/sw/trio/ * License : Eiffel Forum License 2 Programming Lang: Python Description : RDF utilities Trio is a set of Python utilities for handling RDF. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20.3-bytemark-uml-2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Noah Slater <http://bytesexual.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#466728: ITP: python-trio -- RDF utilities
On Thu, Feb 21, 2008 at 08:44:00AM +0100, Christian Perrier wrote: > Sorry, this is precisely rationale I fight against. Just saying "if you > don't know what this is, you don't need this" defeats the purpose of > packages descriptions. In the general case maybe but for this I disagree. For highly specialised development tools such as RDF there is really no need to be verbose about what the name actually means because those who would be interested already know. I took a look at the current state of affairs w/r to RDF: [EMAIL PROTECTED]: ~ $ apt-cache search rdf | grep rdf liblrdf0 - a library to manipulate RDF files describing LADSPA plugins liblrdf0-dev - liblrdf0 development files librdf-perl - Perl language bindings for the Redland RDF library librdf-ruby - Ruby 1.8 language bindings for the Redland RDF library librdf0 - Redland Resource Description Framework (RDF) library librdf0-dev - Redland RDF library development libraries and headers php5-librdf - PHP5 language bindings for the Redland RDF library python-librdf - Python language bindings for the Redland RDF library python-rdflib - RDF library containing an RDF triple store and RDF/XML parser/serializer Only one of these packages is expanding the acronym RDF. I really don't see the use case here. -- Noah Slater <http://bytesexual.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#466728: ITP: python-trio -- RDF utilities
> I'd suggest expanding what RDF is, at least in the long description. Even > better would be expanding it in the synopsis of course. I disargree with you on this point. If the user doesn't know what RDF is they certainly don't want to install the package and knowing the definition isn't going to change much. Similarly, you wouldn't expand GTK or HTTP or NFS if the package was providing a developer library to deal wich such things. I agree that the description could be longer. The homepage is pretty terse and I was planning on contacting upstream for suggestions for extended description. -- Noah Slater <http://bytesexual.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What about use xml for descriptions of packages?
On Sun, May 25, 2008 at 08:46:22AM -0400, Roberto C. Sánchez wrote: > On Sun, May 25, 2008 at 02:40:07PM +0200, Fernando Cerezal wrote: > > I'm thinking about advantages and disadvantages of write the > > description of the packages using XML. > > Personally, I would hate this. I've written too many ant build.xml > scripts to think that writing XML by hand is even a remotely sane thing > to do. Same here. A lot of people when faced with a problem think "I know, I'll use XML!" Now they have two problems. Seriously though, XML is often used for no apparent reason other than it being "trendy" or "cool" or whatnot. I think this is one of those times. Some initial problems I can think of: * You can't "just" use XML, you have to use a dialect. Dialects require schemas and schemas are Hard. * XML is hard to edit and prone to errors when done by hand. * XML would be very hard to format by hand when embedded within RFC 2822, the format of the debian/control file. * XML is great for complex content that requires many degrees of freedom and processing possibilities, non of which really apply to package descriptions. * XML even when used is usually better when derived from some other format, such as a light text based markup language. Think AsciiDoc, Markdown or REsT. Some initial questions I can think of: * What would XML buy us that plain text doesn't? * Do those benefits outweigh all the negative issues. * Could something more light weight be chosen instead? Best, -- Noah Slater - Bytesexual <http://bytesexual.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495940: ITP: feedvalidator -- advanced feed validator
Package: wnpp Severity: wishlist Owner: Noah Slater <[EMAIL PROTECTED]> * Package name: feedvalidator Version : 0 Upstream Author : Sam Ruby <[EMAIL PROTECTED]> * URL : http://feedvalidator.org/ * License : MIT Programming Lang: Python Description : advanced feed validator An advanced syndication feed validator that works with RSS, Atom and KML. Usable as a command line tool or web service. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packaging team best practice
Hello, I have been having some discussion with a member of the Erlang packaging team about best practice and comparing this with the Python Modules packaging team. The two teams approach things slightly differently... Python Modules * The focus is on individual maintainership * Uploaders is always set to the team email address * Maintainer is generally set to the email address of the primary person maintaining the package even though as a team the package is sometimes edited by other people * The entire team's packages can be seen using: http://qa.debian.org/[EMAIL PROTECTED] * Example package, sponsored upload: http://packages.qa.debian.org/p/python-couchdb.html Erlang: * The focus is on collaborative maintainership * Uploaders is always set to the developer(s) uploading/sponsoring the package * Maintainer is generally set to the team address for the core packages even though only certain members of the team may be actively maintaining it * Maintainer is set to the email address of the primary person maintaining the package for non-core packages even though as a team the package is sometimes edited by other people * Consequentially, only some of the packages can be seen using: http://qa.debian.org/[EMAIL PROTECTED] * Example core package, non-sponsored upload: http://packages.qa.debian.org/e/erlang.html * Example non-core package, sponsored upload: http://packages.qa.debian.org/c/couchdb.html Clearly some teams will organise differently, and that's fine, but it would be nice if we could agree a set of guidelines for using the Maintainer/Uploaders fields consistently across teams. This would, at least, make using the Quality Assurance reports more useful. The closest thing I could find to a set of packaging team guidelines is: http://wiki.debian.org/Teams/Guidelines Nothing is mentioned in relation to this issue. Thoughts? Feedback? Am I missing some existing documentation? Many thanks, -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging team best practice
On Tue, Aug 26, 2008 at 03:47:55PM +0200, Sandro Tosi wrote: > This is not entirely true: each one can choose to set maintainer as the team > or a "real person"; for example, take a look to every module I package[1] in > the team: the Maintainer field is always set to the team. I see, that's very similar to how the Erlang team are doing it. > I think I'm not seeing the issue here: Maybe I misrepresented my self in the original email, I don't see a MAJOR issue with the status quo, nor do I feel that anything should be imposed on the existing teams. I was more hoping for feedback on the reasons for the subtly different ways of using the Maintainer/Uploaders fields within the context of a packaging team with a view to codifying some best practices. On Tue, Aug 26, 2008 at 03:40:53PM +0200, Norbert Preining wrote: > On Di, 26 Aug 2008, Noah Slater wrote: > > Clearly some teams will organise differently, and that's fine, but it would > > be > > nice if we could agree a set of guidelines for using the > > Maintainer/Uploaders > > fields consistently across teams. > > I disagree. Teams work differently and thus the Maintainer/Uploader usage > differs. What is the problem. >From some of the private conversations I have had I am aware that some people >do not feel it is appropriate to list a team's email address in the Uploaders field under any circumstances and others probably feel the same way about the Maintainer field. Having some community guideline that says what is and isn't okay either way would be nice, even if it just says "do whatever." Best, -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging team best practice
On Tue, Aug 26, 2008 at 03:32:25PM +0100, Noah Slater wrote: > From some of the private conversations I have had I am aware that some people > do not feel it is appropriate to list a team's email address in the Uploaders > field under any circumstances and others probably feel the same way about the > Maintainer field. Having some community guideline that says what is and isn't > okay either way would be nice, even if it just says "do whatever." Along these lines, we have this from the thread you cited: http://lists.debian.org/debian-python/2008/03/msg00016.html This is exactly the kind of thing (ignoring the correctness of Piotr's personal policy which I don't feel qualified to comment on either way) that would be useful as a codified set of best practices. Best, -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Anyone looked at Chromium for Debian yet?
Hey, Has anyone looked at packaging Chromium for Debian yet? http://code.google.com/chromium/ http://dev.chromium.org/developers/ http://src.chromium.org/svn/trunk/src/chrome/ Looks like a 3-clause BSD, was going to check out the code and scour it for potential DFSG issues but my downlink was slow. >From what I gather, a GNU/Linux build might be possible, with a bit of >massaging here and there... though I obviously haven't done much research into this yet. I notice that as of yesterday evening, no one had filed an ITP. Best, -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anyone looked at Chromium for Debian yet?
On Wed, Sep 03, 2008 at 10:32:12AM -0300, Marco Túlio Gontijo e Silva wrote: > A friend of mine reported[0] a successful build in Debian. [...] > https://listas.dcc.ufmg.br/pipermail/grad041/2008-September/022464.html > It sais: I compiled it here nicely in Debian. I had only to change a > little bit in the source of __tt_main_proc.c, which made a native call > to Windows' systray. Ah yes, I was sure I had seen something about it working... I concur that we have bigger things to be worrying about right now, was just interested in a quick canvas of opinions, thoughts &c. -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#502959: general: raff.debian.org uses non-free software
On Tue, Oct 21, 2008 at 07:23:35PM -0700, Kelly Clowers wrote: > As a mere user I very glad that Debian stands where it does on the > spectrum of caring about users vs caring about freedom. It is one of > the major reasons I am a user of Debian. Seconded. -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Mon, Nov 10, 2008 at 03:16:06PM +0100, Guus Sliepen wrote: > Please do not reduce images in size. The screenshots of, for example, dillo > and > amiwm are horrible. If you have a guideline of having a maximum size of > 800x600 pixels, just give an error when someone uploads a screenshot that is > larger than that. Why impose such a barrier to entry for contributers? I think resizing images is a fantastic thing to provide. I do think the page lengths, or result count per page, could be increased. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Tue, Nov 11, 2008 at 10:38:44AM +0100, Stefano Zacchiroli wrote: > I believe the answer is that in the future there will be more > screenshot, but what about giving the ability of seeing one (maybe the > "most popular") screenshot directly from the result page? Good idea. 110x80 would be a nice size for the thumbnails. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: screenshots.debian.net goes beta
On Tue, Nov 11, 2008 at 09:24:18PM +0100, Stefano Zacchiroli wrote: > On Tue, Nov 11, 2008 at 08:54:07PM +0100, Miriam Ruiz wrote: > > >> I think it would be better to try to keep a 4:3 ratio. > > > I disagree; the aspect ratio of the screenshot would be correct. > > Conventional screens are 4:3 or 16:9, and most usual resolutions keep > > 4:3 ratio (640x480, 800x600, 1024x768...) > > Isn't the two of you assuming that screenshots are always took in > fullscreen mode? That isn't neither stated in screenshot.d.n > guidelines, nor reasonable. > > So it can be that your disagreement is not that relevant :) Not at all, I was assuming that no matter what size the uploaded image is, it would be scaled down to fit inside a bounding box and placed in the centre of a white canvas. So the question remains, how large to make the canvas. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SmellyWerewolf.com perfume & make-up discount
On Sun, Nov 23, 2008 at 01:57:28PM -0600, Manoj Srivastava wrote: > Since when have sexist remarks come under being "humour"? If you > think locker room conversations and objectification of women are funny, Maybe I'm missing something. Which parts of the original email, specifically, were sexist or objectifying of women? Can you explain why? I am genuinely confused. Just as an advert for a men's perfume in real life would advertise that it attracted women to you, it is reasonable to assume that a parody of a perfume company would use the same advertising. Do you consider all perfume companies to be sexist? Even the perfume companies for women? Or is it the word "chick" that has upset people? If so, why? Is this any different from "dude"? Thanks, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SmellyWerewolf.com perfume & make-up discount
On Sun, Nov 23, 2008 at 10:35:10PM +0100, Miriam Ruiz wrote: > 2008/11/23 Noah Slater <[EMAIL PROTECTED]>: > > On Sun, Nov 23, 2008 at 01:57:28PM -0600, Manoj Srivastava wrote: > >> Since when have sexist remarks come under being "humour"? If you > >> think locker room conversations and objectification of women are funny, > > > > Maybe I'm missing something. Which parts of the original email, > > specifically, > > were sexist or objectifying of women? > > Are you serious in this? I thought we had already overcome that, but > if you really mean it and it's not just trolling, we can start > explaining it all again from the beginning, maybe it's needed after > all. Yes, very serious, and not trolling. Please quote from the original email explaining to me how it is sexist. Note, I am not saying it is not sexist, only that I can't see it. If you show something to me that I have overlooked I am more than likely to say "aah, I see now", but I genuinely don't see what the problem is. Was it the language used? If so, how? The allusions made? If so, what allusions? The use of perfume or the implication that Debian developers are male? If so, can you explain a little? -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SmellyWerewolf.com perfume & make-up discount
On Sun, Nov 23, 2008 at 03:17:09PM -0600, Manoj Srivastava wrote: > hen you are a retrograde, beetle browed moron. Ah, the discussion has descended into name calling! Superb! -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SmellyWerewolf.com perfume & make-up discount
On Mon, Nov 24, 2008 at 09:01:32AM +0100, Rafael Laboissiere wrote: > * Noah Slater <[EMAIL PROTECTED]> [2008-11-23 22:07]: > > Please quote from the original email explaining to me how it is sexist. > > Well, I found the parody very offensive to men, in general. Heh, heh. Parody, satire, and pastiche humour are designed to take a view point, such as racism or sexism, an activity, such as golf or football, or something else such as advertising standards, and exaggerate it to the point of ridicule. We are meant to point at this stuff and say "oh my, how inappropriate this would be! thank goodness this is humour" and then laugh a little. An intelligently crafted parody of racism is funny precisely because racism is horrible and the joke is poking fun at the people who are genuinely racist. To proclaim that it is racist is to entirely, and horrendously, miss the point. The same thing goes for sexism, political policies, sports, news, &c > At any rate, given the precedent with Andrew Suffield and the kissing > lesbians, sending the joke to d-d-a was certainly a faux-pas. Absolutely. Parody carries with it the unfortunate consequence of misunderstanding. When this happens, people are generally offended. This type of humour should not have been sent to a place where people could have misunderstood it and I think we can all agree on that point. Can we please just leave it at that though, instead of perpetuating a terrible misunderstanding of the mechanics involved in parody and satire. The email wasn't sexist, but it was inappropriate. Slapped wrists, &c. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#507447: ITP: python-simplecouchdb -- simple library for working with Apache CouchDB
Package: wnpp Severity: wishlist Owner: Noah Slater <[EMAIL PROTECTED]> * Package name: python-simplecouchdb Version : 0.9.1 Upstream Author : Benoit Chesneau <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : Apache 2.0 Programming Lang: Python Description : simple library for working with Apache CouchDB Provides a simple high-level client library for Apache CouchDB, allowing you to model documents as Python classes. . Apache CouchDB is a distributed document database system with bi-directional replication. It makes it simple to build collaborative applications that can be replicated offline by users, with full interactivity (query, add, update, delete), and later "synced up" with everyone else's changes when back online. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format
Hey, On Wed, Dec 03, 2008 at 12:25:20PM +0100, Simon Josefsson wrote: > Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > > > The solution to your problem already exists (actually, it has been > > *designed* for that): http://wiki.debian.org/Proposals/CopyrightFormat > > , it "just" needs someone with the energy of finalizing the proposal > > (most likely via a DEP), so that is stops being an ever changing wiki > > page. > > This seems like an excellent idea, and seems in line with the comment at the > top of the current wiki page too. I volunteer to help on this. Maybe we can > set up a vc repository to start working on the DEP? The wiki page can be used > as a starting point, assuming the license is acceptable. As one of the primary contributers to the copyright proposal I would obviously like to be involved in its ratification. I am guessing some of the other main contributers would like to be involved too. To get this started we need a mailing list and a repository, then we can place a notice on the wiki directing people to the mailing list and make the wiki page immutable so that there is no confusion. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format
On Wed, Dec 03, 2008 at 01:05:56PM +0100, Stefano Zacchiroli wrote: > On Wed, Dec 03, 2008 at 11:49:25AM +0000, Noah Slater wrote: > > To get this started we need a mailing list and a repository, then we > > can place a notice on the wiki directing people to the mailing list > > and make the wiki page immutable so that there is no confusion. > > Come on, do you really need all this for just the DEP drivers? > > The idea behind DEPs is to have a small (2-3 typically) number of drivers, > which can easily discuss among them via private mail, just for the sake of > shaping the work. Then, for the various intermediate steps (draft, ...) the > discussion will be public anyhow, and it is assumed to take part on the most > appropriate mailing list (I'd say -devel for this particular DEP, in other > cases can be -project). Oh, okay, that makes sense. How should we go about collecting to the contributers? Should I post a note to the wiki (alerting the subscribers) about this, and if so, where to direct people for collaboration? > As a repository if we want we have the DEP repository which can be used by > that, but you are free also to use the wiki page (maybe a new, temporarily > private one) or a personal repo of yours. The existing DEP repository should be fine. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format
On Wed, Dec 03, 2008 at 12:57:33PM +0100, Simon Josefsson wrote: > > As one of the primary contributers to the copyright proposal I would > > obviously like to be involved in its ratification. I am guessing some of the > > other main contributers would like to be involved too. > > Great, then maybe finding volunteers isn't actually a problem, as the subject > line implied. The current contributers are pretty active, which is great. > Good idea. Can't debian-legal be used for discussion though? Alternatively, > if a list is set up to discuss any DEP proposals. A list to discuss just the > copyright file format specifications seems somewhat overkill. But maybe I'm > wrong and the format will be discussed forever and ever. Well, as is always the case with these things, without any direction this proposal could be discussed until the heat death of the Universe and in fact we have already witnessed the same things come up time and time again. Moving this to a more formal channel and spending a bit of time getting some consensus before wrapping it up is absolutely the right move. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format
On Wed, Dec 03, 2008 at 01:50:22PM +0100, Stefano Zacchiroli wrote: > On Wed, Dec 03, 2008 at 12:26:03PM +0000, Noah Slater wrote: > > How should we go about collecting to the contributers? Should I post > > a note to the wiki (alerting the subscribers) about this, and if so, > > where to direct people for collaboration? > > It is up to you. From a management point of view, I don't think you should > look for many people as the drivers. We already have two people in this thread > which volunteered for that (you are one of the two). I suggest you start > together to shape the first draft and see how to make the work fit in the DEP > process (remember that Sam proposed the copyright stuff before we had DEPs). Okay, sure. Well, it has already been requested that this be delayed until after Lenny and I think that sounds like a good idea. Once we have that out of the way I will being to push this forward as a DEP. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format
On Wed, Dec 03, 2008 at 10:52:39AM -0800, Steve Langasek wrote: > On Wed, Dec 03, 2008 at 11:49:25AM +0000, Noah Slater wrote: > > As one of the primary contributers to the copyright proposal I would > > obviously > > like to be involved in its ratification. I am guessing some of the other > > main > > contributers would like to be involved too. > > > To get this started we need a mailing list and a repository, then we can > > place a > > notice on the wiki directing people to the mailing list and make the wiki > > page > > immutable so that there is no confusion. > > Why do you need a separate mailing list for a single proposal? Please > discuss this on debian-devel or debian-project, which are already perfectly > adequate lists for this. We have struggled enough with the proposal as it is. My fear is that discussing it on debian-devel will open it up to "fire-and-forget" criticism that lacks context of previous discussions, is poorly thought out, results in spiralling threads and contributes little to the effort. If there was some dedicated forum for discussing this, even if this was simply a DEP mailing list, I think it would encourage thoughtful and committed contributions from all involved. > (Not on debian-legal, which is these days beset with wankers with no technical > experience in Debian who don't need to be allowed to leave their stink on > proposals that affect the contents of every Debian package.) Is this language entirely appropriate or constructive? -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format
On Thu, Dec 04, 2008 at 09:50:15AM +0900, Charles Plessy wrote: > Rendez-vous after Lenny release on -devel :) Heh heh. Sure thing, Charles. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with the concept of unstable -> testing
On Mon, Dec 15, 2008 at 09:30:33PM +0100, Julien BLACHE wrote: > You mean, something like experimental? > > You failed "Basic research 101". And it was as simple as going to > <http://release.debian.org> and read the Lenny freeze announcement > <http://lists.debian.org/debian-devel-announce/2008/07/msg7.html> that is > linked under the "Lenny frozen" title. Is there any need for such rude condescension? -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Tue, Dec 16, 2008 at 06:48:08PM +0100, Thomas Viehmann wrote: > Bastian, this is a brilliant idea!! Debian needs those excellent people like > you who have splendid ideas and all ready to implement them!!! You are the > most valuable person in Debian right now! Because you contribute a > lot!!! You should start this super-unstable today!!! When it works > out later, Debian should integrate it as official repository! Do > not delay starting it! No one else in Debian has your brains, > so no one else can do this!!! The strength of a community rests in its ability to work together as a group. I wish we could all show a bit more respect for each other on the mailing lists. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Tue, Dec 16, 2008 at 08:30:22PM +0100, Thomas Viehmann wrote: > But while you bring it up: I want a Debian where every Developer can cough up > a minimal commitment to help with releasing. That is what "Have you fixed an > RC bug today is about?". If all developers had fixed one RC bug in the months > that we have been frozen, we would have run out. Regardless of your wishes, the attitude you displayed in your previous email is actually detrimental to Debian and the community that other people work so hard to foster. I cannot see how you would think one justifies the other. > The other way round works, too: Removing people who don't have that minimal > commitment from the project and their packages from the archive would also > allow us to release (a lot less) in a timely fashion. I think you need to read some of the stuff by Clay Shirky. He demonstrates that the power of new media and Internet based organisations such as the Linux developers, Debian, Flickr, Digg, and Wikipedia actually gain their massive organisational power by having close to zero barrier to entry for contributions from occasional users. When you look at the statistics for these groups you see majority overwhelming amount of work consists of one-time contributions, and the frequency of contribution increases in ever smaller amounts. By trying to artificially raise the barrier to entry for contributions to Debian, you would be inadvertently crippling one of the most crucial parts to its continued success. > Bastian's contributions have a theme of telling other people how to do work > that he does not want to do: What information they should want in their bug > reports, how to release, how negligent the assistant secretary is and why he > is even doing the secretary's, and now what to do with unstable in the > meantime (as other's have pointed out, not a new idea, so the contribution is > rehasing of the idea). To be honest, I'd prefer if Bastian applied his skills > to helping a project I'm not a member of. I am not going to comment on his behaviour, your comments may very well be justified. But I do think it would do the project some good if we all learnt to embrace each others commitment levels, attitudes and opinions -- without resorting to rudeness, unkindness, or personal attacks. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Tue, Dec 16, 2008 at 10:17:13PM +0100, Michael Banck wrote: > On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: > > Actually, I don't know since I'm not long enough involved to know what > > happened "back then". > > It's called research. It's called manners. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Tue, Dec 16, 2008 at 09:57:15PM +, Neil Williams wrote: > On Tue, 16 Dec 2008 21:41:58 + > Noah Slater wrote: > > > On Tue, Dec 16, 2008 at 10:17:13PM +0100, Michael Banck wrote: > > > On Tue, Dec 16, 2008 at 09:27:55PM +0100, Bastian Venthur wrote: > > > > Actually, I don't know since I'm not long enough involved to know > > > > what happened "back then". > > > > > > It's called research. > > > > It's called manners. > > Yes, manners relating to actually thinking whether the idea has been > considered before and typing something into Google? How hard is that? Manners > involves consideration for others - that includes what is likely to have > happened before some arbitrary point in time and considering that people more > knowledgeable than yourself may just have considered the problem at some point > before you became aware of the problem, maybe? Of course! I'm not going to argue with that. However, just because one person has made a faux pas, does not give blanket permission for other people to follow suit. This inevitably causes a chain reaction of rudeness and flames. As a community, we would do well to be a little more tolerant of others, and that includes their mistakes. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Tue, Dec 16, 2008 at 09:53:58PM +, Neil Williams wrote: > I get criticised for being rude or direct - well here's the news: I don't care > if people think I'm rude, deal with it. At least I do what I can to fix stuff, > I apologise when I do make mistakes and I do not recommend something I have > not done myself. Would that more "contributors" were as active. I think you should care about upsetting people, and so should others. When you work for an organisation like Debian, the community is the most valuable asset it has going for it. Rude and abrasive characters who contribute a lot of code, but who upset the community, waste time by drawing fire or starting flame wars, or scare away new contributers do not deserve to be excused for such behaviour. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
On Thu, Dec 18, 2008 at 04:45:07PM +0100, Mohammed Adnène Trojette wrote: > On Thu, Dec 18, 2008, Russell Coker wrote: > > He has stated that he intends to keep offending people. His aim seems > > to be the censorship of people who disagree with him by continually > > offending them until they stop disagreeing. > > Come on, you're defacing reality and Josselin's statements... > > What he said is clear: he'll continue expressing himself freely (as in > free speech, remember?) even though some people feel offended. That's a > proof a courage, as long as he doesn't fall into illegality. > > Quite different, isn't it? Not only that, but "I will continue shocking people" could be taken as an intent or a prediction of people's reactions. Either he intends to shock people purposefully or he fully expects people to continue to be shocked. You really have put words into his mouth, and I don't think that's right. Also a bit funny that you intend to solve "censorship" (not that I agree) with more censorship. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
On Fri, Dec 19, 2008 at 06:13:57PM +0100, Michael Banck wrote: > Dear Norbert, > > On Fri, Dec 19, 2008 at 01:18:21AM +0100, Norbert Preining wrote: > > So if *anyone* here thinks he is up to define ethical, political > > correct, anti-sexist and all the bullshit, please do so, but somewhere > > else. > > Please use gender-neutral language when addressing a diverse audience. Oh come on, this thread has been going on enough as it is. I'm tired of having to delete all the emails! We hardly need people trying to correct other people's usage of a language that doesn't properly provide for gender neutral constructions in the first place. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Debian women may leave due to 'sexist' post"
Troll. Troll. Troll. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Debian women may leave due to 'sexist' post"
On Mon, Dec 22, 2008 at 05:59:30AM +, Sam Kuper wrote: > 2008/12/22 Noah Slater : > > Troll. Troll. Troll. > > I hope that's not referring to John's email. Are you kidding? On Sun, Dec 21, 2008 at 11:36:05PM -0500, John Wiggles wrote: > I am not a dev or woman but I believe that sexism,racism and any other ism > you want to add is wrong and should be dealt with accordingly and swiftly. This implies that someone disagrees with him. > Shame on the Debian Project leaders Pointing his finger to individuals. > for not coming out against these people > who think that making jokes that degrade,insult Opening old discussions, with no context. Unnecessary. > and basically hurt the > feelings of > other HUMAN beings who work hard for FREE so we can all have a great > operating system. Needlessly emotive, we all know this. > My feelings are hurt for the women of and the men who don't feel like > these...let's just say it, STUPID LITTLE MINDED PEOPLE! Stupid little minded people? Oh come on. Intentional inflammation. The whole email was uncalled for, and I believe purposefully designed to re-ignite the biter flame wars and arguments that have been tearing apart these lists for the past couple of months. We've been through all of this, and we have important work to be concentrating on. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Debian women may leave due to 'sexist' post"
On Sun, Dec 28, 2008 at 09:04:24PM +0100, Norbert Preining wrote: > I didn't get the original email of Lisi because it was not sent to d-d. > > > 2008/12/28 Lisi Reisz : > > > this topic is idiotic. For those of us who are old enough to have > > > been officially and by law down-moted to second class citizenship when > > > we married; by law lumped in with children, and not in with men. > > Bummer, please stop that bullshit. I don't know your origin, but Lisi > Reisz doesn't sound like an Arabic, nor Indian, nor African name, so > probably your marriage was not arranged. > > If it was indeed, sorry for the "bullshit" above. > > If it wasn't, what the hell are you talking??? Get a life! CAN WE STOP THIS THREAD NOW PLEASE? This thread started off as a troll and has only got more and more absurd as time has progressed. We're so far away from sensibly discussing DEBIAN here it's becoming unintentional self-parody. Please, can people just stop replying. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Debian women may leave due to 'sexist' post"
On Mon, Dec 29, 2008 at 10:39:50AM +0100, Peter Tuhársky wrote: > For me, the answer is quite simple. The computing is almost technical > industry, and therefore it is naturally more suitable for men, who are > naturally strog in technical thinking and achieving the task milestones. > Just like there are much more women in people-contact positions, because > women are naturally better equipped for social contact, empathy, > caregiving... Althought I think it is time now, that much of technical > issues are being solved or solved already, and there is need to make the > computing experienca "more human". This is total horseshit. It is anecdotal gender profiling that causes women and men to choose certain paths through life in the first place, and is hence one of the root causes of the very problem we're trying to solve. > A man would usually be a terrible personal assistant (secretary) or > kindergarden nurse, because men are weak in paralell-tasking, where women are > strong. [citation needed] > I found these things to be natural -woman is just naturally better equipped > for the household and children care, not because "man poses her to that pose", > but because she really CAN effectively cope with multiple tasks at time, > e.q. she can cook and guard a child at the same time, with ease. [citation needed] > Man cannot do that, or only with extreme stress. Give him three tasks, he > would overburn. [citation needed] > Other hand, it is usually harder for a woman to keep track for long-term > goals, concentrate to single task, etc. [citation needed] > Admitting this knowledge, we can use our strong attributes for a great > benefit, rather than suppressing the difference, that would also suppress our > potential. Don't fool your self, this isn't knowledge. It's anecdotal superstition. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Debian women may leave due to 'sexist' post"
On Mon, Dec 29, 2008 at 10:55:54AM +0100, Peter Tuhársky wrote: > There are many things people did and do wrong. Enslaving anyone if bad. > Irrespectedly of gender. However, the feminism of its current shape, in > countries where no discrimination is pushed on women, is making the same > mistake, just in other direction. You know, apartheid has been cancelled not > so long ago, and what took place then? Reversed apartheid. It is well-pictured > in the Babylon 5 series, the Narn-Centauri neverending conflict. Bad for > anyone, both sides just revenging the old sins, ad infinitum. Wait, what? > It is well-pictured in the Babylon 5 series Tell me you didn't just cite a fictional universe... -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: percentage of popcon submitters
On Thu, Jan 15, 2009 at 10:00:04PM +0100, markus schnalke wrote: > I know it is not possible to _know_ the real percentage of uses which > submit popcon stats of all users. But I want to ask for guesses, > because more oppinions do likely improve the result. This question of trying to figure out whether a book is good or bad by looking at it carefully or by taking the reports of a lot of people who looked at it carelessly is like this famous old problem: Nobody was permitted to see the Emperor of China, and the question was, What is the length of the Emperor of China's nose? To find out, you go all over the country asking people what they think the length of the Emperor of China's nose is, and you average it. And that would be very "accurate" because you averaged so many people. But it's no way to find anything out; when you have a very wide range of people who contribute without looking carefully at it, you don't improve your knowledge of the situation by averaging. -- Richard P. Feynman, Surely You're Joking, Mr. Feynman! -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Modifying debian/changelog entries
Hey, I have two separate, but related, questions not covered by policy: * If you are the only person mentioned in a changelog and you change your email address, when you do a new upload, is it okay to modify all of the old changelog entries to use the new email address? * Is it okay to occasionally modify old changelog entries for clarity and style, typos and such like, as long as you don't change the semantics? Thanks, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modifying debian/changelog entries
On Mon, Jan 19, 2009 at 01:06:53PM +0100, Thijs Kinkhorst wrote: > On Mon, January 19, 2009 13:00, Noah Slater wrote: > > I have two separate, but related, questions not covered by policy: > > > > * If you are the only person mentioned in a changelog and you change your > > email address, when you do a new upload, is it okay to modify all of the > > old changelog entries to use the new email address? > > I see no harm but also no gain in this. Sure. Doing so satisfies my OCD need for consistency though. Heh heh. > > * Is it okay to occasionally modify old changelog entries for clarity and > > style, typos and such like, as long as you don't change the semantics? > > I would say that this is perfectly fine. The changelog is documentation of > which changes happened between version n and m. If you can improve that > documentation, I see no reason to leave it inferior. I agree completely. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modifying debian/changelog entries
On Tue, Jan 20, 2009 at 09:07:06AM +1100, Ben Finney wrote: > > Sure. Doing so satisfies my OCD need for consistency though. Heh > > heh. > > Surely consistency would argue *against* changing the historical > record? When those releases were made, the email address was as > recorded at the time. That it changed later should not alter the > existing factual record on earlier entries. No? Well, I guess it depends what your personal æsthetic is. I like per-file consistency over (arguably unimportant) historical correctness. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modifying debian/changelog entries
On Tue, Jan 20, 2009 at 01:19:44PM +0100, Adeodato Simó wrote: > Do you use version control systems? (Particularly any of the ones that > store your email address at the time of the commit.) You can't go > updating your address in old commits, and IMHO the changelog should be > treated just the same if possible. I am using Subversion for my packages and my username has not changed. In any case, choosing to highlight the limitations of an orthogonal system as justification for not being able to edit debian/changelog entries is a non sequitur as far as I'm concerned. > OTOH, OCD (which was mentioned in the discussion -- not sure if just > semi-seriously, which would be unfortunate) is different from aesthetics > as far as I'm concerned. Well, I only mentioned OCD as a humorous thing. I do have mild OCD, and along with my æsthetic taste, it comes into play when I'm being creative. I consider development to be a creative activity. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
What about providing a test target in debian/rules and hooking into this automatically with pdebuild. You should be able to run tests from within the chroot without having to modify your debian/control file. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Test suites after build and Build-Depends.
On Fri, Jan 23, 2009 at 08:24:41PM +0100, Vincent Bernat wrote: > > What about providing a test target in debian/rules and hooking into this > > automatically with pdebuild. You should be able to run tests from within the > > chroot without having to modify your debian/control file. > > One of the interests of those test suits is to be executed automatically > by buildd (on arch that you cannot easily test). Aha, thanks for the clarification. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Misc developer news (#13)
On Tue, Jan 27, 2009 at 01:04:51PM +1100, Paul Wise wrote: > On Sun, Jan 25, 2009 at 9:37 AM, Emilio Pozuelo Monfort > wrote: > > Ondrej Certik wrote: > >> This whohas command is awesome, great job! > > > > Yes. And the openSUSE URLs suck! > > Please file a bug. I'm surprised you sent that mail instead of filing a bug. In defence of the OP, it hardly looks like a Debian-fixable problem. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#458095: ITP: phenny -- extensible IRC bot written in Python
Package: wnpp Severity: wishlist Owner: Noah Slater <[EMAIL PROTECTED]> * Package name: phenny Version : 2007-12-20 Upstream Author : Sean B. Palmer <[EMAIL PROTECTED]> * URL : http://inamidst.com/phenny/ * License : TBD Programming Lang: Python Description : extensible IRC bot written in Python Phenny is a lightweight IRC bot with the usual facilities that one expects such as a Wordnet interface and thesaurus lookups. Modularly extensible with Python and can reload modules on the fly. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.20.3-bytemark-uml-2 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Noah Slater <http://bytesexual.org/> "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman signature.asc Description: Digital signature
Re: Bug#516659: ITP: w3bfukk0r -- scan webservers for hidden directories (forced browsing)
On Sun, Feb 22, 2009 at 05:18:39PM -0800, Asheesh Laroia wrote: > I think that the description explains that the purpose is to find hidden > directories on web servers, presumably either your own or other people's. Why would you need to find directories on your own server? -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#516659: ITP: w3bfukk0r -- scan webservers for hidden directories (forced browsing)
On Mon, Feb 23, 2009 at 01:06:38PM +0100, Bjørn Mork wrote: > Noah Slater writes: > > On Sun, Feb 22, 2009 at 05:18:39PM -0800, Asheesh Laroia wrote: > >> I think that the description explains that the purpose is to find hidden > >> directories on web servers, presumably either your own or other people's. > > > > Why would you need to find directories on your own server? > > Why would you need to buy a gadget like http://www.keyringer.com/ ? Because you can loose your keys. How can you loose a directory on a machine you have access to? -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#516659: ITP: w3bfukk0r -- scan webservers for hidden?directories (forced browsing)
On Tue, Feb 24, 2009 at 09:17:35PM +0100, Holger Levsen wrote: > > (As Noah Slater pointed out, it's hard to lose a directory on your > > own machine...) > > you can loose access to your machine... At which point you may as well call it someone else's machine. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 07:46:11AM +0100, Mike Hommey wrote: > > In shorter words: I think something should be done about the copyright > > file to encourage developers to actually perform an audit of the > > license status of files in their packages before they upload. The > > current copyright template doesn't really encourage this; I like the > > machine-parseable system because it makes it easy to organize such an > > audit. > > Try doing that on iceweasel or xulrunner. Hint: there are about 3 > files and a real lot of copyright holders. It behoves us as distributors to check, no matter how hard it is. If you think that sounds like too much work, maintain a different package. > On top of listing copyright holders, I must say listing the individual > files for each license in the copyright file is also a major PITA. While > wildcards can be used, a huge mix of license like webkit is makes it > really painful to update. OTOH, I really don't care what files are under > what licence. I *do* know that there is a mix of BSD-2, BSD-3 and LGPL > code, plus some extra libraries embedded, and that any addition to > webkit is licensed under BSD or LGPL because upstream does enforce that > (except, obviously, embedded libraries, but we already have to check if > any is added to avoid duplication and build against the system one > whenever possible) You might not care, but the package users might do. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 08:28:34AM +, Sune Vuorela wrote: > On 2009-03-20, Ben Finney wrote: > > All of what you've demonstrated is part of what Mike covered with > > ???one has to go through all of the source files anyway???, is it not? > > The point I got from his message is that, having *already* accepted > > the burden of going through all the files, one can then record the > > copyright status while doing that. > > So far, comaintainers of gnome, kde, webkit, xulrunner and firefox are > saying that this is a major extra burden. > > The kernel team seems to have a full waiver for listing copyright > holders. > > So please listen to the packagers of "big" packages what is a burden and > what is not. No one is saying it isn't a chore. As a maintainer, it is your duty to make sure that everything you upload is DFSG free, which means checking every single file. As you have to do this anyway, it makes sense to record that information in debian/copyright. If you maintain a very large package, then you should *expect* this to take a long time. If that's too much effort for your, get a co-maintainer or a different package. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Thu, Mar 19, 2009 at 09:41:36PM -0700, Russ Allbery wrote: > Ben Finney writes: > > > The point is that, since we can predict the need for this information, > > we have the choice of assuming the information is there when we > > distribute and never looking for it until the need arises in the face of > > such a threat, or looking for it in advance of distribution and hence in > > advance of exposure to that threat. I think it's clear that the latter > > option is preferable. > > Er, I'm certainly not going to pay any attention who the copyright holders > are for various files in something I'm packaging. I care about the > license; why should I care in the slightest whether the listed copyright > holder is one name or some other name? Of course, this isn't just about the legal issues. Including the copyright statement is a form of attribution, and is good manners. I also see that the copyright file is primarily useful to end users who may want a convenient way of browsing the copyright and licence information. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 01:07:44PM +0100, Josselin Mouette wrote: > Le vendredi 20 mars 2009 à 13:02 +0100, Romain Beauxis a écrit : > > Le Friday 20 March 2009 12:55:05 Josselin Mouette, vous avez écrit : > > > Fine. Do you have co-maintainers on sale? > > > > It is not about co-maintaining, but about co-reviewing which is a totally > > different task. > > Do you really think we can find an unlimited amount of volunteers > willing to continuously read thousands of files to find the list of > copyright holders? Nobody said anything about needing an unlimited amount of collaborators. However, it is required that we check every single file we upload to the Debian archives, so this task has to be done in some form or another. If you feel like your current packages are too much effort, maybe you should look for collaborators on them to ease the ask. If we cannot do this simple thing, maybe we shouldn't be distributing software. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote: > > It behoves us as distributors to check, no matter how hard it is. > > > > If you think that sounds like too much work, maintain a different package. > > If you don't stop writing crap like this, I really think I *will* stop > maintaining these packages. I don't see what your problem is. If we were suggesting some totally arbitrary and time consuming task, then I could understand your concerns. However, you should be checking each file as a part of your packaging, all that is being requested is that you document this for the FTP masters and our users. The focus here should be on producing quality software, with a rigorous and open process, so that people can be confident that what we're shipping is totally free software. Cutting corners to save a bit of time, simply because a package is large, does not seem to fit well with this goal. Hence my suggestion that if a package you are maintaining seems like too much work, perhaps it would make sense to collaboratively maintain it. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 03:13:29PM +0100, Mike Hommey wrote: > No, look at the text I quoted : you suggested to maintain a different package. Yes, out of several emails I sent to the list, you selected a single sentence. I apologise if you got the wrong message from what I had written, it was not meant as a personal attack. On the other hand, saying that maintaining packages can be time consuming seems like such an obvious thing, I wonder why people are bringing it up - unless they mean to suggest that we should cut corners when rigorously checking free software made available for distribution. > Now, as I said earlier in this thread, there have been several calls for > help on those big packages that *are* a problem to do the scan you would > like to see on all packages, yet, nobody joined teams as a result. I appreciate the difficulties you might be experiencing here. The distinction I was trying to draw is that this matter is totally unrelated to the copyright documentation we keep in the packages. Considering that it is already our mandate to check every single file, this is already a problem for you. Sure, you have a lot to deal with, and finding collaborators is hard, but using this as a flimsy reason to disregard the copyright proposal seems absurd. > Following your advice, we should stop maintaining openoffice, iceweasel, > xulrunner, kde, and who knows what other packages because nobody cares > enough to scan tens of thousands of source files for copyright holders. You selectively chose one thing I had written, please don't do that. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 03:14:36PM +0100, Josselin Mouette wrote: > Le vendredi 20 mars 2009 à 14:02 +0000, Noah Slater a écrit : > > If we were suggesting some totally arbitrary and time consuming task, then I > > could understand your concerns. However, you should be checking each file > > as a > > part of your packaging, all that is being requested is that you document > > this > > for the FTP masters and our users. > > > > The focus here should be on producing quality software, with a rigorous and > > open > > process, so that people can be confident that what we're shipping is totally > > free software. Cutting corners to save a bit of time, simply because a > > package > > is large, does not seem to fit well with this goal. Hence my suggestion > > that if > > a package you are maintaining seems like too much work, perhaps it would > > make > > sense to collaboratively maintain it. > > What is your problem? Do you want to see whether Mike can become violent > if you press him hard enough, or is it another kind of experiment? Why do you find it necessary to be so aggressive with me? I fail to see which part of my argument you think is inflammatory or ridiculous: * It is already your responsibility as a Debian package maintainer to thoroughly check each and every file for copyright and licensing issues. * If you maintain a large package, this must already be a burden for you. * Documenting this process in a text file does not seem like much extra work. * Complaining that you would have to check every single file implies that you don't already check every single file, which you should be doing. * Therefor, complaining that this is hard work and collaborators are hard to come by, seems like a completely orthogonal issue to the copyright proposal. This doesn't mean that I am doubting how much work the bigger packages are, or that it isn't hard finding collaborators. I have a lot of respect for the people who offer there time to get this job done. On the other hand, this rationally has nothing to do with the copyright proposal, presuming that everyone is already following policy. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 03:35:22PM +0100, Raphael Hertzog wrote: > On Fri, 20 Mar 2009, Noah Slater wrote: > > On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote: > > > > It behoves us as distributors to check, no matter how hard it is. > > > > > > > > If you think that sounds like too much work, maintain a different > > > > package. > > > > > > If you don't stop writing crap like this, I really think I *will* stop > > > maintaining these packages. > > > > I don't see what your problem is. > > You are requesting work from other volunteers and it's bad taste to do so. I accept your point, but I think that this is a bad framing. People have been complaining about the copyright proposal costing too much time. Aside from pointing out that this is presumably time you were already spending checking each file, a good solution is collaborative maintenance. Not sure what else you expect someone to respond with apart from throwing their hands up and conceding that we should adopt policy to conform with peoples wish to avoid additional work. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 01:46:51AM +1100, Ben Finney wrote: > > I don't see what your problem is. > > It seems that the problem is that “look for collaborators” is what > they're already doing, without apparent impact on the problem at hand > (the workload involved in copyright auuditing of the package), so > presenting it as a novel course of action isn't helpful. Well, that is great then. Obviously, I was not aware of this. My argument still stands though. This has nothing to do with the new copyright proposal. All this proposal does is cement what is already policy, and what packagers should already be doing. If the community thinks that policy is at fault, this should be discussed as a separate matter. As it stands, I see that people are effectively arguing that the copyright proposal should be abandoned because it is enforcing an aspect of policy that people don't wish to follow. All I am doing is suggesting that either we throw out this argument, or fix the policy. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 03:55:30PM +0100, Mike Hommey wrote: > That you actually felt stroing enough to type twice, which pissed me off. > See <20090320111658.gd7...@tumbolia.org> if you don't remember suggesting > to maintain a different package. Well, there are only three solutions, and I have suggested them all. If you find the current work a burden, you could maintain a different package, try to find collaborators, or lobby to get policy changed. I wasn't suggesting any were preferable, or that you hadn't tried. I really don't care either way. My goal was to draw the focus away from the copyright proposal, which is only codifying existing policy. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 04:01:56PM +0100, Mike Hommey wrote: > > * Complaining that you would have to check every single file implies that > > you > > don't already check every single file, which you should be doing. > > If all the above were true, no package of xulrunner, iceweasel, openoffice, > kde and others would have *EVER* entered the archive, since there has > *NEVER* been such work done on these packages, and until this funky new > copyright showed up, that did bother *NOONE*, including the ftpmasters. [...] > If you want those copyright files to be thourough, I invite you to download > one of the packages above's source, and start checking those tens of > thousands of files. See you in three months to see where you are at it, > and throw you some more new upstream releases. > > > This doesn't mean that I am doubting how much work the bigger packages are, > > or > > that it isn't hard finding collaborators. I have a lot of respect for the > > people > > who offer there time to get this job done. On the other hand, this > > rationally > > has nothing to do with the copyright proposal, presuming that everyone is > > already following policy. > > It has all to do with it, since you are suggesting that the copyright > proposal is sane even for big packages, changes nothing to the current > status quo, which, as I said above is far from being true, and that > $SOMEPEOPLE should do their homework or move to other packages. Actually, the copyright proposal is just a text format, not a policy document. If you're telling me that the FTP masters would be happy with blanket license statements for a package, what is stopping you from using the existing format to say something along the lines of: Files: * Copyright: Copyright 2008, Damien Katz Copyright 2008, Jan Lehnardt Copyright 2008, Christopher Lenz Copyright 2008, Noah Slater License: Apache-2.0 On Debian systems the full text of the Apache License (Version 2) can be found in the `/usr/share/common-licenses/Apache-2.0' file. Note, this is an actual snipped from the couchdb package. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 04:12:37PM +0100, Mike Hommey wrote: > Point me to the paragraph in the policy that says that the copyright file > must list all copyright holders and licensing info for all individual files > in the source package. > > Let me help you: there is no such paragraph. So what on earth has this to do with the copyright proposal? If you wish to make blanket statements using the copyright proposal, what is stopping you? All we wanted to do is develop a format so that copyright information was both machine and human readable. If the FTP masters are happy with your current work, there should be no reason why you can't express what you are already doing with the new copyright proposal. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 05:45:11PM +0100, Michael Banck wrote: > I guess people think the new copyright proposal mandates mentioning the > copyright holders etc. in a much more verbose way than Policy does so > far. > > So people consider it a regression with respect to their routine. Great, so it seems we have made progress! If the consensus is that broad-brush copyright information is suitable for Debian, we should make it clear in the copyright proposal that people are free to make that judgement call. I apologise if I came across as too aggressive, I was only disheartened by what seemed to be a conflation of separate issues. I see the copyright proposal as a format, not policy, document. If people want to formalise the granularity of our copyright information, then so be it, but let's do that as a separate effort. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 09:56:39AM -0700, Steve Langasek wrote: > No, it doesn't. > > If I have a good upstream and am confident that the work has been correctly > licensed, there's no reason for me to go through the software file-by-file > just to double-check this. As I have been corrected, so apologies are in order. However, there have been times when I have realised after some time that the copyright information in the upstream is woefully incomplete or inaccurate. I had similarly doing blanked declarations in debian/copyright which turned out to be wrong because I had not checked. When I found this, I sent the issue upstream: http://tinyurl.com/ctargs And I was fortunate that they did a massive overhaul and a re-release. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 11:33:32PM -0500, Manoj Srivastava wrote: > Now, some of the objections you have heard is because of the > hard line you have been taking in this discussion about looking for > and adding copyright holders is not, as far as I can see, reflected in > current policy. > > And telling people they are doing a bad job and need to either > shape up or change policy does not actually seem to be corroborated by > policy, unless I am missing chunks. Yeah, I apologise for this. This had been my understanding. Sorry. > BTW, to your list of solutions, I can add another one: > + realize this is busy work with little value in the common case, and >prefer to spend time otherwise improving the package. On the other hand, I think this needs to be clarified. I only maintain a small number of packages, but even then, I have regularly found files contained within those packages which were included for various reasons by upstream under a different license. In the case of planet-venus, I remove a not insignificant number of these for the DFSG. Clearly, some amount of checking each file is a good thing, so why not be explicit about what is required of a developer for this? Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 03:58:34PM +0100, Joerg Jaspert wrote: > Honestly, if you cant deal with listing the Authors/(C) holders - dont > maintain a package. It is not much work to list them. (It might be a lot > of work using the "new" format, but noone *requires* this format, especially > not ftpmaster. It has *no* gain for us at all, we couldnt care less if > you use it or not). I resent the implication in this remark. The copyright proposal is not complex, not verbose, and does not require any extra information from developers. The only thing it does is to mandate a machine readable format, in a similar vein as debian/control, for whatever information you might have already been using. This has clear advantages for being able to post-process, check, search, and navigate copyright information using whatever tools the community decides would be profitable. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 09:42:35AM -0500, Manoj Srivastava wrote: > Why do they have to? I know, the ftp team made it up. But there > is no reason in policy or in copyright law for such copying to > occur. But it would be nice to know why it is needed. I can think of a few desirable reasons: * To show the FTP masters that they have thoroughly checked the licensing. * To provide concise information for our users. > > We require, and have seen nothing to convince us otherwise, that Debian > > maintainers need to do the basic work of listing each copyright holder in > > debian/copyright, as seen in the source files and AUTHORS list or > > equivalent (if any). > > Why do you think this work is needed? You must have had some > rationale, since you made up this policy. Again, to document that they have, in fact, done what they are supposed to. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 12:15:00PM -0700, Russ Allbery wrote: > Is the reason that you feel most licenses require preservation of the > copyright notice and it's easier to enforce it uniformly for all copyright > files? Is there some other larger reason why is this important for the > project? (Please note that I'm not assuming that you have no reason. I > just don't understand, from the discussion so far, what it is. We can't > really have a meaningful discussion until we're all on the same page) Like I have said a few times previously, it serves as documentation that the package has been thoroughly checked for licensing issues. Because such a check must involve looking at the headers of each file, and any AUTHORS or similar file, there appears to be no reason why this should not be written down. It also provides a nice summary for our users. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 04:24:55PM +0100, Josselin Mouette wrote: > When you spend more time on administrative stuff that no one will ever > care about than on actual packaging stuff, something is very wrong. As I > have already explained, I won’t spend any more time doing that. If you > feel like REJECTing packages because of that, fine. We’ll surely find > some NMs to disgust by doing administrative trivia, and in the meantime > packages will be found on a repository on alioth. Again, while the documentation of individual licenses may not be policy, it is certainly policy for each package to be thoroughly checked for licensing issues. As this necessarily involves looking at each file, I don't see why it should be considered that much extra effort documenting the process. Ensuring DFSG compatibility is hardly administrative fluff. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 11:09:36PM +0100, Florian Weimer wrote: > * Tim Retout: > > > If you do want to check who has assigned copyright to what, ask a GNU > > maintainer who has access to the records on fencepost.gnu.org. > > This still doesn't tell us if the assignment is effective. > > (To clarify, I haven't seen the FSF records, but I've spoken to > several GNU contributors in potential work-for-hire scenarios and have > been told how the assignment process had been handled within their > organizations.) It is largely unimportant. The legal details of copyright assignment are not important here. If the package lists the copyright as belonging to the FSF, then it belongs to the FSF. If it does not, then it does not. This is coming from a GNU maintainer who has been through the process. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 08:07:23PM -0700, Russ Allbery wrote: > NEW rejections are even stronger than an RC bug. Apart from questions of > whether that's useful documentation for users, I have a hard time seeing > either of your reasons stated above as being RC-level bugs. You don't think that possible DFSG problems are RC bugs? :/ -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 08:09:56PM -0700, Russ Allbery wrote: > > The legal details of copyright assignment are not important here. If the > > package lists the copyright as belonging to the FSF, then it belongs to > > the FSF. If it does not, then it does not. > > I don't mean to be excessively blunt, but I'm afraid that this simply > isn't legally true. For our purposes it is more than sufficient. If a package lists a person as the copyright holder, we should accept it. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 04:31:58AM +0100, Josselin Mouette wrote: > Le dimanche 22 mars 2009 à 02:58 +0000, Noah Slater a écrit : > > Again, while the documentation of individual licenses may not be policy, it > > is > > certainly policy for each package to be thoroughly checked for licensing > > issues. > > As this necessarily involves looking at each file, I don't see why it > > should be > > considered that much extra effort documenting the process. > > > > Ensuring DFSG compatibility is hardly administrative fluff. > > Please read what people write, otherwise it’s getting pretty insulting. > > No one here is questioning the importance and the usefulness of the > licensing check. I don't understand the disconnect here. A license check must, by definition, involve each file in the package. As re-quoted from the quote you previously quoted: "I don't see why it should be considered that much extra effort documenting the process." Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 08:13:54PM +1300, Andrew McMillan wrote: > On Sun, 2009-03-22 at 03:34 +0000, Noah Slater wrote: > > On Sat, Mar 21, 2009 at 08:07:23PM -0700, Russ Allbery wrote: > > > NEW rejections are even stronger than an RC bug. Apart from questions of > > > whether that's useful documentation for users, I have a hard time seeing > > > either of your reasons stated above as being RC-level bugs. > > > > You don't think that possible DFSG problems are RC bugs? :/ > > Do you mean as in "guilty until proven innocent"? No, because that's a horrendous framing of the issue. However, with licensing and the DFSG, things are a little different. It is our responsibility to thoroughly check a package before we upload it, and that usually means checking every single file. I would like to think that no one is uploading packages with the *hope* that they are DFSG free. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 08:42:12PM -0700, Russ Allbery wrote: > Could you explain to me how the lack of those two things is a possible > DFSG problem? I assume that this is based on the first, but that seems > like quite a stretch to me. The same assurance, for what good there is in > it, could be drived from a statement in debian/copyright saying "I checked > every file in this package for DFSG licensing problems." Okay, just to get it straight. I have made it clear that the copyright proposal makes no pronouncements about how it should be used. We are only discussing the orthogonal topic of how much information to include in this file, regardless of whatever format the package uses. I am not convinced either way, because my packages are probably relatively small compared to some. This has been an interesting discussion primarily because we have had the opportunity to shake out arguments from both sides. Having said that, I am thinking that fully documenting the license of each file provides a handy way to ensure that developers are thoroughly checking the package for licensing problems. It is not inconceivable that we could add a lintian check which does some fuzzy guesswork to see if it can spot any probably missed files based on parsing the debian/copyright file. It could also prove handy to the FTP masters who wish to check the quality of work. > Also, no, I definitely do not think that a possible DFSG problem is an RC > bug. I think that an *actual* DFSG problem is an RC bug. A possible DFSG > problem is only a possible RC bug. Surely this is obvious? Sure thing. My point was that not checking every file seems like sloppy work to me, for a distribution that places such an emphasis on licensing, and can lead to many problems. I have been the unfortunate victim of my own laziness in this regard, so at least I am speaking from guilty experience. Regardless of format, caveat a machine readable format being available to lintian for some rudimentary checks, a requirement for developers to document the licensing checks in debian/copyright could (not would) go a long way towards preventing DFSG problems in future uploads. Preventative measures seem a lot better than reactionary ones in this regard. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 08:45:55PM -0700, Russ Allbery wrote: > Given that many people have already said that it is, perhaps this is the > point where you should just accept that they're not lying to you and > instead you're suffering from a failure of imagination? > > I know from personal experience (having done this as an experiment for > several packages of mine, including some fairly large ones) that it is > indeed quite a bit of extra effort. This is for several reasons, > including the simple fact that I read a lot faster than I type. Sure, I accept your points, and I apologise for my sloppy wording. Firmly in my mind is the cost/benefit of this extra effort. If we succeed in integrating debian/copyright checks into lintian, or dpkg and it's front-ends, it seems reasonable to imagine that this effort would be a good trade-off. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 11:35:02AM +, Neil Williams wrote: > IMHO it is about not getting hung up on the process but considering the > reasoning behind the process. AFAICT, there is no good reason to > document every single copyright holder but there are very good reasons > to document every applicable LICENCE. > > As a sponsor, I do *not* require that every single copyright holder is > listed in debian/copyright. I *do* require that every file in the > source package has been checked for the applicable LICENCE and that all > such LICENCES are declared in debian/copyright along with clear > identification of which files use which licence. Where there is a clear > division between copyright holders and licences, I would expect that > the sections of debian/copyright dealing with files under that licence > specify that the files are Copyright foo rather than Copyright bar > that applies elsewhere. If some names and / or email addresses fall > through the gaps, so be it. This seems entirely reasonable. If we can include copyright holder names without much trouble then I think we should out of courtesy, but I shouldn't imagine that it must be a requirement. There is no reason why you couldn't adopt this approach with the proposal. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 11:42:29AM +, Neil McGovern wrote: > I'm not quite clear as to why this is an advantage yet Currently, this > seems to have been designed to provide interfaces for future tools to > use, while not regarding whether or not people want those tools. > > Could you provide a use case or two to help clarify things? The main > one I see is for an end user to look at a packages copyright file and > say 'yes, I can use it for $foo', which is a case that's detracted from > in the proposal. Listing the licences (not necessarily copyright holders) in a machine readable format would allow lintian checks to be developed, and maybe even automatic license compatibility checks to be performed. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 11:54:49AM +, Neil Williams wrote: > Then reconsider the remark. The proposed format is more work for many > overworked maintainers, it presents no clear gain for those maintainers, > it overly complicates the file and file handling. There is no point > arguing about these facts, overworked maintainers have made their > feelings clear and no amount of bleating from those supporting the > proposal will now change their minds. Only a complete restart will be > acceptable. Remember that the format can be used however we decide is best for Debian, even if that includes the recent discussion on omitting full copyright holder details. As a machine readable format, that allows us to potentially integrate this into lintian, and any number of dpkg tools that might want to perform license compatibility checks. You seem to be arguing that most people dislike the format, perhaps as a concept and not in its current grotesque incarnation, which I would contend given it's large, and voluntary, uptake. > I, for one, would rather see the entire proposal backported to revision > 50 or thereabouts and left at that. I refuse to use later revisions as > a basis for my own packages and I will not sponsor packages that, in my > own view, overly complicate debian/copyright by using this proposal as > a template for their own packages. The proposal, as it stands, is > insane and anyone recommending it needs to review the reasons for > recommending such a grandiose waste of my time. Yes, the proposal is pretty absurd at the moment. I believe this has been mentioned already in this thread. At some point, the benefits of the wiki process were overshadowed by the problems it created coordinating the effort. As a result, many of the core drivers (myself included) backed away from doing any repair work, and have been waiting until after Lenny to restart the effort using a proper method and mailing list for communication. I too use an old version for my packages, because I dislike the current one. > No, the current proposal is overtly complex, unnecessarily verbose, > requires enormous amounts of extra time from maintainers, the proposal > itself still has no clear structure and is completely unusable. The > machine readable format is not human readable and bears no comparison > with the clarity of debian/control. I think this is going over the top, a little. But for the most part I agree. Like we've previous stated, we do not want the current proposal evaluated. We have plans to restart the effort, collaborating via reasoned discussion on some mailing list, and then present a polished version for wider discussion. The aim of this proposal, at least from my perspective, was achieving machine readability in a similar vein to debian/control in the least possible intrusive way. The current proposal falls short of this by a large margin. As you seem to have considered this in some depth, it would be great to get your collaboration when we take a hatchet to it for "version 2" as you put it. > The proposal has been drowned in pointless edits and is unworthy of > further consideration, IMHO. Either backport to a point where the idea > is once again deemed sane by those maintainers who would most benefit > from tools to support updates of debian/copyright or abandon the entire > proposal as a good idea gone bad. > > Maybe someone else can look at it after Squeeze and raise version 2.0 > from the ashes. It seems we are in violent agreement. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 03:47:39PM +0100, Romain Beauxis wrote: > Le Sunday 22 March 2009 14:45:18 Noah Slater, vous avez écrit : > > > Could you provide a use case or two to help clarify things? The main > > > one I see is for an end user to look at a packages copyright file and > > > say 'yes, I can use it for $foo', which is a case that's detracted from > > > in the proposal. > > > > Listing the licences (not necessarily copyright holders) in a machine > > readable format would allow lintian checks to be developed, and maybe even > > automatic license compatibility checks to be performed. > > I find it somehow ironic that you overlook the human trust between developpers > but would follow automated test done by a machine. Please don't put words into my mouth. I never said I overlooked anything, only that it might be nice to augment things. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 03:35:13PM +0100, Florian Weimer wrote: > Files: share/www/script/json.js > License: PD > In the public domain. > > This file does not exist. Yes, it seems the file is: share/www/script/jso2.js > The file NOTICE contains this hint: > > | This product includes software developed at > | The Apache Software Foundation (http://www.apache.org/). > > I'm wondering if this should be reflected in the copyright file (and > if the NOTICE file should be installed in the binary package, in case > the binary package ends up on different media than the sources). The ASF does not take copyright assignments, so it's unimportant. If you find problems in my packages, please file bugs. > I don't think this is a significant problem, but it probably means > that the machine-readable copyright file format is, in itself, not a > solution. I hardly see that me making a typo constitutes a failure of the format. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 02:13:20PM +, Neil McGovern wrote: > Perhaps this is where we're not quite seeing eye-to-eye. I know that > machine readable copyright files would allow lintian checks. But what > would those checks be, and what would be the point of them? I believe there has been so discussion of this already. I invite whomever has looked at this to speak up abut their plans. > All I've personally seen so far is 'it makes data mining easier', which > although could be a goal in itself, doesn't improve the quality of > packages. But could improve the quality/utility of Debian as a whole, right? -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 03:27:46PM +0100, Peter Palfrader wrote: > The way this process should work is that you (or somebody) writes those > tools. > > Then, if DDs see that those tools are useful they will convert their > debian/copyright files to take advantage of those tools all by > themselves. No one will have to force them. > > If people don't consider those new tools useful enough to invest the > work into converting then this means that those tools probably are not > of sufficient help and no amount of proof by authority or handwaving > will change this. Sounds like a fine idea to me. Please note, no one is suggesting that the copyright proposal be enforced either as it currently stands or immediately. The purpose of us rebooting the effort is to make the existing mess sane again, and to get some tooling developed around it exactly as you suggest. Only then would we put it forward for proper consideration. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 11:35:26AM -0700, Russ Allbery wrote: > I could see an argument that putting the contents of NOTICE into > debian/copyright satisfies the second possibility -- "within the ... > documentation, if provided along with the Derivative works" -- but I think > just installing the NOTICE file is more obviously safe. CouchDB should be doing a 0.9 this week, so I'll take a look. Thanks. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 07:10:46PM +, Sune Vuorela wrote: > > A license check must, by definition, involve each file in the package. > > > > As re-quoted from the quote you previously quoted: > > > > "I don't see why it should be considered that much extra effort > > documenting > > the process." > > > > Best, > > Please try it then. > > take the kdelibs source package, start with taking time on how long it > takes to verify that everything is gpl compatible and then afterwards > try list every single copyright holder and put it in the proposed > copyright file and also measure the time spent on that. Two errors here: * I didn't include the time of checking each file, which you should be doing anyway. No doubt this can take a long time sometimes. I was only talking about the additional work of noting each license down. * I have made it perfectly clear that noting copyright holders was not something I was talking about. Please do not mangle my position like this. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 12:29:37PM -0700, Russ Allbery wrote: > Noah Slater writes: > > > Having said that, I am thinking that fully documenting the license of > > each file provides a handy way to ensure that developers are thoroughly > > checking the package for licensing problems. > > Did you mean "copyright" here? No one is disputing the need to document > the license of every file that goes into forming the contents of the > binary package. No, I meant license. It seems people ARE disputing that licenses be fully documented. > I have a serious conceptual problem with requiring work in order to ensure > that people are doing some other piece of work that's only partly related. > The actual *requirement* here is that packages be audited for license > problems. For me at least, copying and pasting copyright notices to > create a collective notice for packages that track separate copyright for > all contributors takes at least three times longer than just checking each > file for unexpected licensing. I can more easily do the audit without > doing that work. I have already made it explicit that I was not talking about copyright holders. > I'm really not enthused at the idea of having to do a bunch of copy and > paste work just to prove to someone that I've looked at every file. It > feels like the sort of make-work assignment that I had to tolerate in > grade school. One nice thing about being an adult is that I don't have to > put up with that sort of thing any more. :) In the context of documenting licenses, it's more for our own sake than anything else. Like unit tests for code to make sure everything is in order. This would be more clear if we had developed lintian checks already. > In all of the packages for which I've implemented the new copyright > format, which is more than a dozen now, I've always used a catch-all > stanza with the main package license. I have a hard time imagining when I > ever *wouldn't* do that. This means that such a Lintian check is going to > be pretty worthless in practice, unless I'm missing some approach that's > more than just making sure each file in the source tree has a matching > stanza in copyright. Me too. Perhaps there is a way of catching boilerplate patterns and checking to see if they are matched in debian/copyright. It wouldn't be an exact science, but it might be helpful in some way. > > Sure thing. My point was that not checking every file seems like sloppy > > work to me, for a distribution that places such an emphasis on > > licensing, and can lead to many problems. I have been the unfortunate > > victim of my own laziness in this regard, so at least I am speaking from > > guilty experience. > > I'm finding it a bit frustrating that your wording here seems to treat > copying and pasting all the copyright files as if it's synonymous with > checking every file and seems to assume that people who don't do the > copying and pasting aren't checking every file. They truly are not the > same thing. I'm not sure I follow, sorry. > > Regardless of format, caveat a machine readable format being available > > to lintian for some rudimentary checks, a requirement for developers to > > document the licensing checks in debian/copyright could (not would) go a > > long way towards preventing DFSG problems in future uploads. > > We already *do* require that developers document the results of the > *license* audit. I don't think anyone is disputing that (although it's > painfully tedious for large packages, and it would be really nice if the > people who are deeply concerned that Debian always do this would volunteer > to help the Iceweasel, Linux kernel, KDE, and X maintainers, among others, > with doing this work). Well, there seems to be some confusion then. I have made it explicit in this thread that I don't really see it as necessary that each copyright holder be listed, and that we only do it where necessary. It is my understanding that people have still raised objections about documenting every license in debian/copyright, for example Autoconf and other generated files. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 12:55:58PM -0700, Russ Allbery wrote: > I think part of the problem right now is that people aren't sure what to > expect and are feeling like this review is somewhat unpredictable. This > is what I'm hoping to be able to help with by revising the Policy section. > If we can break this down into must, should, and best practice, then > people can understand that they'll get a reject for breaking a must, maybe > a reject for being particularly sloppy about shoulds, and just get notes > about best practices, as with most of the other things in NEW review. And once this is complete, the proposed copyright format would sit on top of that nicely, assuming it is accepted by the community. I want to keep all policy decisions away from the format proposal. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 01:02:22PM -0700, Russ Allbery wrote: > we can just copy that notice, ignoring the fact that ISC doesn't do > copyright assignment and the actual copyrights are held by way more > different people than are explicitly mentioned there. I don't think > there's any utility in duplicating the INN CONTRIBUTORS file in > debian/copyright. +1 -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 09:00:34PM +0100, Arthur de Jong wrote: > I can understand there may be benefits of a parsable format but I don't > directly see enough gain. On the other hand there seems to be a lot of > (perceived) cost involved (maintainer work). Implicit in your email is the idea that the copyright proposal is complicated. Files: * Licence: BSD I can imagine that being valid syntax for the final format. Hardly a chore! > This means that if you want to introduce a new format you have to > convince the maintainer of a package that there is some benefit, be it > in tools that make their life easier or some concrete benefit for our > users. Agreed. Clearly, given the successful uptake of the proposal given it's draft nature, people are already seeing value. Perhaps like me, one of those values is having a consistent way of laying out the file, without having to worry about inventing your own consistent formatting style. Maybe that's just my mild OCD speaking though. Heh. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 09:55:10PM +0100, Raphael Hertzog wrote: > He is monopolizing the discussion. He should let some time pass between > replies to take into account the opinions of others. Furthermore, by > replying too fast he is actively making the discussion non-followable by > many persons that don't want to spend an afternoon on this topic. Am I the cat's mother? I'm not sure which is more rude, replying to emails faster than other people or criticising someone's behaviour in a public forum. If you think I reply to emails too fast, please do so in private in the future. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 09:08:54PM +, Noah Slater wrote: > Am I the cat's mother? I'm not sure which is more rude, replying to emails > faster than other people or criticising someone's behaviour in a public forum. > If you think I reply to emails too fast, please do so in private in the > future. Please TELL me in private, heh. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 10:38:47AM +, Neil Williams wrote: > I'm still not convinced that machine-parseable formats are genuinely > useful or maintainable and I feel that machine-parseable > requirements inevitably impair human readability of copyright files. > That's not a win, AFAICT. Don't use it then, I guess. As Steve pointed out, we're working an a format that people can use voluntarily if they wish. We are not suggesting that this format become mandatory at this stage, at least not until it had seen widespread adoption. As someone who's been maintaining several packages with this format for over a year, I am pleased to tell you that I find it very useful and easily maintainable. YMMV, of course. > Is it really useful to have only a subset of packages using the format? > Isn't only going to be the small packages that have no particular > licence problems that would adopt it because it's almost trivial to do > so? Unless maintainers of complex packages or packages where licence > problems are likely (those that need exceptions added to the GPL etc.) > can implement the format cleanly, is there really any benefit? You are using the Nirvana Fallacy in your argument. Even if only one person finds the format helpful, there has been benefit. For every additional person who finds this format helpful, even more benefit is had, and each packages shares a consistent, readable, and parseable structure. > There are elements of the format that aid human readability but making > the format completely machine-parseable means making allowances for so > many ifs and buts that the copyright files become only readable by > machine. Of course, this is not true. What a peculiar thing to say. The format proposal follows debian/control, and is quite simple in structure. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 04:26:43PM -0500, Manoj Srivastava wrote: > At this stage? If you are not willing to listen to feedback, > that had better be never. If the intent is for this to be broadly > adopted, the specification should be fixed as early as possible, and we > should not adopt a flawed specification inder the guise that it is > currently "voluntary". Frankly, I think that the spec should have > optional parts, and parts we need, and we should try to come to an > consensus on the required part of the spec, and the optional parts > should be clearly outlined in the specification. We have been listening to feedback and commentary on the draft proposal for over a year now, responding and modifying things as appropriate. That process broke down some time ago, so we have opened dialogues on various mailing lists, and we are starting DEP 5 to gather feedback. > Nice sound bite. But a spec or a standard's big value comes if > it is fixed to be widely accepted, even if it means that some parts of > the standard are "optional". I hope that you will contribute your opinion when DEP 5 has a draft to review. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 05:50:26PM -0500, Manoj Srivastava wrote: > I am expressing my opinion now, on a mailing list devoted to > debian development. I have not been keeping up witht eh bureaucratic > rigmarole that seems to be being wrapped around discussions, not after > we got the notice that there was a topic to be discussed, but we should > not discuss it since the red-tape software was broken. You used to be project secretary, and I am only a humble new maintainer. Seems a bit weird to be criticising the Debian way of doing things like this. > Whoever is drafting the draft ought to be paying attention to > the feedback being generated now, and create a better draft to start > with. Of course we are. :) -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
