Re: Conflict escalation and discipline
On Wed, 2018-04-18 at 17:17 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("Re: Conflict escalation and discipline"):
> > "Debian emotional support group", maybe.
>
> I find this suggestion very surprising, possibly even insulting. At
> the very least I need to be much clearer.
Insulting? *sigh*
> This group would:
>
> * Receive reports of bad behaviour on the part of Debian
>contributors, in whatever forum or venue including in person.
You're seem to be talking about something entirely different than what I had in
mind. You're also proposing something that I find patronising
and sorely lacking in oversight.
>
signature.asc
Description: This is a digitally signed message part
Re: Conflict escalation and discipline
On Wed, 2018-04-18 at 15:51 +0100, Ian Jackson wrote:
> Lars Wirzenius writes ("Re: Conflict escalation and discipline"):
> > Most of the problems being discussed right now, and in general, seem
> > to be of the sort where feelings are hurt, but harassment isn't
> > happening. The situations seem to be "A did something, and B was
> > offended, how do we get A and B to understand each other, and resolve
> > any conflict, and get A and B to collaborate in the future?".
> >
> > This implies to me that, at the least, "anti-harassment" is the wrong
> > name for a team that deals with this.
>
> That's certainly true. I thought of these ideas:
"Debian emotional support group", maybe.
But maybe wait with the naming until there's a clear description of
what the group is reponsible for.
signature.asc
Description: This is a digitally signed message part
Re: Conflict escalation and discipline
On Wed, 2018-04-18 at 13:41 +0100, Martín Ferrari wrote: > I believe that a-h is the natural starting point for dealing with these > issues. Most of the problems being discussed right now, and in general, seem to be of the sort where feelings are hurt, but harassment isn't happening. The situations seem to be "A did something, and B was offended, how do we get A and B to understand each other, and resolve any conflict, and get A and B to collaborate in the future?". This implies to me that, at the least, "anti-harassment" is the wrong name for a team that deals with this. signature.asc Description: This is a digitally signed message part
Re: Automatic downloading of non-free software by stuff in main
On Thu, Dec 07, 2017 at 01:59:16PM +, Holger Levsen wrote: > On Thu, Dec 07, 2017 at 01:52:07PM +, Ian Jackson wrote: > > Furthermore, this "file is dangerous" attribute ought to be copied > > much more. > > no, it ought to be the default. all files should be considered harmful, > unless tagged otherwise. All files _should_ be considered potentially harmful. Even if tagged safe. A previously-safe file might become harmful because it happens to trigger a newly found security bug. Possibly a newly found security bug that did not exist when the file was tagged safe. In my opinion, tagging files safe or harmful is not a winning strategy. I don't think it gives enough benefit to be worth it, and it doesn't seem to me it actually protects our users very much. An xattrs tag, in particular, gets lost so very easily, and having it applied inconsistently means there's a lot of ways in which any protection based on such a tag gets accidentally or intentionally circumvented. If we have a "this is safe" tag, instead of "this may be harmful", then that's also going to get lost often, leading to users getting annoyed by unintended security warnings all the time. Obviously it's possible to handle this by treating it as a by every time a file is copied without its xattr flag. But even from limited experience, that's going to be a very large number of bugs. If my security depends on all programs individually doing all the right things, I won't be feeling very secure. I don't have a good solution, but I suspect something like QubesOS may be the way forward. In other worse, isolate all processes into containers (or virtual machines) of some sort and arrange it so that this doesn't become too cumbersome to the user. (Disclaimer: I haven't had time to actually try QubesOS myself, yet.) The advantage of that approach is that the security gets centralised into fewer system components. It's less important that, say, Firefox is secure, if it can't be exploited to do bad things, if the container stops Firefox from deleting or modifying local files, or making unexpected network connections, or using too much RAM or CPU or other local resources. (I'm describing an ideal here, not the state of current technology.) -- I want to build worthwhile things that might last. --joeyh
Re: should debian comment about the recent 'ransomware' malware.
On Tue, May 16, 2017 at 03:59:18AM +0530, shirish शिरीष wrote:
> while it was primarily targeted towards Windows machines, maybe we
> could tailor a response which shows how Debian is more secure and
> possibilities of such infections are low/non-existent .
Others have commented (correctly, I think) that making security claims
like that is not factually correct.
My take on this is that verbally attacking ("flaming") other systems
is bad form and we should avoid that. Gloating over problems in
Windows counts as verbally attacking them. It makes us look like
poopheads and doesn't have any benefits for us. Let's not.
Tearing down others doesn't make Debian better. Let's stick to being
positive and constructive and to making Debian better together.
We, the Debian project, don't need to make a statement on Wcry at all.
If we were to do so, it should be something that helps victims, or
those in danger of becoming victims, of this non-verbal attack. Maybe
something along the lines of keeping one's systems up to date with
security updates, and having good, secure backups that an attacker
can't destroy. But that advice is already being given by numerous
others so I'm sure it's worth Debian doing it too, if for no other
reason that very few Windows users pay any attention to Debian.
(I wrote an article on Linux advocacy 20 years ago. Things haven't
changed radically since. http://liw.fi/advocating-linux/)
--
I want to build worthwhile things that might last. --joeyh
signature.asc
Description: PGP signature
Re: producing, distributing, storing Debian t-shirts
On Sun, Apr 30, 2017 at 09:37:11PM +0200, Daniel Pocock wrote: > "Non-profit" means that Debian does not distribute surplus profits back > to people such as shareholders. It does not mean that Debian can not > make a profit on the sale of a t-shirt, as long as that profit is > re-invested in the organization. This will be highly dependent on the local laws for whatever trusted organisation the proxies it for Debian. On the other hand, I at least would prefer if Debian didn't put in money to have a stock of merchandise. Merchandise seems to happen anyway. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC
On Thu, Apr 06, 2017 at 01:30:19PM +0200, alberto fuentes wrote: > It comes down to know if planet is about debian or about debian developers From https://wiki.debian.org/PlanetDebian: What Can I Post On Planet? Planet Debian aims to aggregate the blog posts of people who are active in Debian and not only to aggregate the blog posts about Debian. The point is to provide a window into the community itself. Posts that are about Debian are a great idea and some people will choose to only syndicate "on topic" posts. But other posts are also welcome! We want to learn about the people, their life, opinions (even political) and doings. In short, it's about Debian contributors, not just Debian. Based on my memory, it has always been that way. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC
The meta issue here is who decides policy for Planet Debian, and how that is done. This is important for the current case as well: the controversial blog post is dates March 30, the change to require suitability for 12-year-olds is from March 31, and the wiki change was made by the author of the blog post. I'm not aware of any public discussion of the change, before the change happened, but perhaps I've just found it. I admit I have a hard time trusting a policy defined in a wiki page that anyone can change. It seems quite weird to me to apply the DebConf Code of Conduct to Planet Debian. I don't who said what to whom, when, or how, to make that be the conclusion. It would be good, I think, to have policy discssions on public mailing lists. I don't currently have a comment on the suitability for Planet Debian of the post in question. Russ raises excellent points. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Let's make Debian DPLess!?
On Sat, Mar 11, 2017 at 03:46:41PM +0100, Guillem Jover wrote: > From the current list of powers in the consitution §5.1.1—§5.1.5 are > IMO the strongest powers, and they are either very very seldomly used > or when used they are pretty much a rubber stamp. Whenever a DPL has > tried to be more proactive the project has been mired in controversy. I disagree on this. It's true we rarely have trouble with regards to, say, delegations, but it's taken a whole lot of effort to get here. In my opinion, it's a good thing to have someone whose responsibility it is to sort things out in case we ever do have have trouble again. Thus I think it'd be a mistake to get rid of the position we have with that responsibility. > Every and each year we have these pharaonic platforms where the > candidates present all those grandiose pyramid plans. Those never happen. > But I guess it's more interesting than writting a platform that states: > > * Will rubber-stamp delegations. > * Will be an ambassador for the project. > * Will be a minister of finances for minutia. If grandiose platforms are a problem, by all means fix that. As it happens, I think I agree (assuming I understand what you mean). Which is why I wrote a "not platform" along non-grandiose lines some time ago. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Let's make Debian DPLess!?
On Sat, Mar 11, 2017 at 12:50:19AM +0100, Guillem Jover wrote: > The truth is that even though the constitution grants _some_ powers to > the DPL, they are in general not used, because IMO the project would > not see those actions with good eyes. I'm not sure I agree with that. DPL powers include delegation and deciding how to spend project money. I'd say it's pretty uncontroversial that we want those things to happen. What powers specifically do you see that the project would prefer the DPL not use? -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)
On Tue, Dec 06, 2016 at 04:15:22PM +0100, Johannes Schauer wrote: > why would it be important to change that kind of information for a package in > stable? The audience interested in this field is interested in uploads to > unstable, so is it not sufficient if the information is up-to-date there? For example, there's corner cases that get tricky. A package might only be in stable, but the maintainer wants to declare it as LowThresholdAdoptable. That would require an upload to unstable only to change that bit of metadata. Or Debian might be in a freeze, and uploading a new package version would be frowned upon. It's a lot simpler to keep this metadata outside source package. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)
On Tue, Dec 06, 2016 at 03:50:12PM +0100, Johannes Schauer wrote: > Actually, this is a great argument for why this information should be in a > deb822 field in the source package itself. FWIW, I think this is the kind of information that should be kept out of the source package, since changing it would require an upload and that's not going to happen for stable. I'd prefer such information be kept somewhere it's easy to change. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers [and 1 more messages]
On Mon, Dec 05, 2016 at 08:02:27PM +0100, Laura Arjona Reina wrote: > I have just created the page: > > https://wiki.debian.org/LowThresholdAdoption > > and added myself to the list. I've added myself to the list. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Replace the TC power to depose maintainers [and 1 more messages]
We've had the "strong package ownership" concept be a problem in various ways. Many years ago people were afraid of making NMUs to fix bugs, even RC bugs, and I started the https://wiki.debian.org/LowThresholdNmu page. It's got over 300 maintainers now, and NMUs are quite normal, though I suspect zack's NMU campaigning helped more. I suggest a lighter approach than a GR for eroding the strong package ownership further is to start another page, "LowThresholdHijack" or something, listing maintainers who are OK if someone hijacks their package if the maintainer isn't taking good care of it. Would anyone else than I put themselves on that new page? (If you would, start the page on the wiki and announce it on this thread, and I'll add myself.) -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: Urgent call to get Jitsi in Debian 9
On Thu, Oct 06, 2016 at 10:27:58PM +0200, Frederique wrote: > What has to be done to get Jitsi pushed through to testing to have it Debian > 9 stable? It's not in Debian testing, because of reasons shown at https://qa.debian.org/excuses.php?package=jitsi, and you should help the Jitsi packaging team fix those reasons. -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Re: third-party packages adding apt sources
On Sat, May 21, 2016 at 10:07:43AM +0200, Martin Steigerwald wrote: > I wonder about a landing page for upstreams interested in working with the > Debian project to provide packages within the official Debian repos. Is https://wiki.debian.org/UpstreamGuide the kind of page you mean? It is not necessarily well known. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: third-party packages adding apt sources
On Sat, May 21, 2016 at 02:07:53PM +0800, Paul Wise wrote: > On Fri, May 20, 2016 at 1:34 PM, Vincent Bernat wrote: > > > Totally agree. Our standards are far too high for many upstreams. > > I don't understand the disconnect here. Are upstreams not interested > in software quality to the extent we are? I don't think it's that upstreams aren't interested in quality, but that Debian and (some) upstreams have different opinions on what aspects of quality are more important. * Debian: don't embed copies of libraries you use. It makes it harder to do security updates in the libraries, makes it harder to use the libraries on their own, and makes the Debian package archive unnecessarily larger. Some upstreams: we embed copies of libraries. It makes it easier to install our software, and guarantees us that the library doesn't change from underneath us, and that means we don't need to support many versions of the library. We're an active project, and if a library needs a security update, we do it quickly. * Debian: it's important to follow Debian Policy and the Debian workflow of uploading to unstable and letting packages flow from there to testing and stable, if they don't have bad bugs. There's thousands of people making packages and things will break if they all do the same thing differently. Some upstreams: it's OK to cut some corners and do things simply. We care about getting the software into the hands of its users as soon as possible, and we also don't have a lot of time to spend on packaging. From our point of view, packaging is a necessary evil that is much too difficult and takes much too much time from us. That's effort we could spend on making the software better instead. * Debian: it's important to have package versions that can be supported for many years. We produce a release every two years, and support it for at least three, and more if one counts the LTS project. Software that changes a lot, or that has an API that changes a lot, or that doesn't separate security updates and backport those to the version included in a Debian release, make this harder for us. We can't generally update to a new upstream release whenever there is a security problem, as it would negate the point of making Debian releases. For example, the new upstream version might require entirely new forests of dependencies, or newer versions of dependencies, all the way down to the kernel. For some packages that we deem sufficiently important to our users, we deal with that, but it is not something that generalises to all packages. Some upstreams: we don't support our old releases. We have only so much time to spend on this software, and supporting old releases would take a lot of effort we don't have time for. That's why we embed most of our dependencies into the installation packages we make, so that they can be installed onto the Debian releases, even if we decide to require more dependencies, or newer versions of them. Et cetera. Debian has one set of quality factors it particularly cares about, and some upstreams think differently. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh signature.asc Description: PGP signature
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
On Tue, Oct 14, 2014 at 09:17:27AM +0200, Kurt Roeckx wrote: If on -vote the required amount of seconds have been reached, I will announce that the GR process has been sarted on debian-devel-announce. Sure, and that's excellent. It would, though, in my opinion to be good to announce the proposed GRs even before the required number of seconds is reached, to make it easier for those interested in the topic to hear about them. That should, of course, be done by those proposing the GR, and debian-devel-announce is, I think, already an acceptable place for them. -- http://gtdfh.branchable.com/ -- GTD for hackers http://obnam.org/ -- HAVE YOU BACKED UP TODAY? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014075419.gg21...@exolobe1.liw.fi
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
On Mon, Oct 13, 2014 at 07:30:43PM +0100, Jonathan Dowland wrote: I think we should clearly indicate where GRs should be announced. (Should, I suppose I'm arguing, not must). I think we don't need to name the place in the constitution. I don't think we need a hard rule about where the announcement happens. I do, however, think it would be good to announce all proposed GRs on debian-devel-announce and debian-vote, with Reply-To to debian-vote. This would ensure all DDs hear about every proposed GR. There's not enough of them to cause a lot of d-d-a traffic. If the proposer of a GR forgets to do that, the secretary or some other DD could do it for them. -- http://gtdfh.branchable.com/ -- GTD for hackers http://obnam.org/ -- HAVE YOU BACKED UP TODAY? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013193235.gf21...@exolobe1.liw.fi
Re: GR proposal: code of conduct
On Tue, Feb 25, 2014 at 06:28:39PM +0800, Paul Wise wrote: On Tue, Feb 25, 2014 at 2:01 AM, Ian Jackson wrote: Is it really the case that making the logs available as public text files produces too much search engine exposure etc. (which is I guess the real concern) ? Several of our derivatives (at least Maemo, Ubuntu) have public logs of their IRC channels. Personally I think it would bring some much needed transparency to what is becoming one of the more essential Debian communication channels to be on. Just like we archive mailing lists and record DebConf talks/BoFs, we should publicly log IRC channels. I am generally in favour of more transparency. Logging official project IRC channels would fit well with that. However, I find that it's very difficult to extract useful information from voluminous IRC logs, and official channels are likely to be voluminous. The logs are hard to read, and there's so much irrelevant discussion mixed with the parts that one is looking for that it is much harder to find what one wants. IRC has no threading, so finding the related parts of a discussion is not easy. This is a stark contrast with, say, mailing lists. Thus I suspect that the logs won't be very useful. I would prefer a culture where IRC discussions are ephemeral, and any useful information should end up in debian/changelog, mailing lists, git commit messages, wiki.debian.org, or any of the other places where we already put information. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225190249.GF4722@holywood
Re: Should mailing list bans be published?
On Sun, Oct 27, 2013 at 09:00:20AM +0900, Charles Plessy wrote: Le Sat, Oct 26, 2013 at 10:46:41AM -0700, Steve Langasek a écrit : What do the rest of you think? Given how arbitrarly other bans have been proposed, I think that the outcome should stay private unless the banned person wishes so. I don't understand this at all. Are you saying Debian listmasters, who decide on bans, have been making arbitrary, and therefore badly justified, bans? In other words, are you saying that they have prevented, without sufficient justification, people from posting to Debian mailing lists? If that's what you're saying, could you give examples of this? I doubt it has happened, but if it has, that's an excellent reason make decisions about banning people from lists public. What's better? a) Someone gets banned from the lists, and nobody is told they have been or at least nobody is told publically. The person might deduce it from the fact that their mails never show up in the list archives, or that people stop responding to them, but that's not always very likely. Other people probably won't realise it at all. It's nearly impossible to argue against a ban you don't agree with, or the reasons for the ban, if everything is kept secret. b) Someone gets banned from the lists, and an explanation of why this happened is posted in public. Anyone can review the decision, and if it seems inappropriate, action can be taken. There is no room for insinuating that the listmasters are abusing their powers. If the ban was, in fact, inappropriate, it can be overturned, and the banned person's reputation is cleared. To me, b) is obviously the better choice. PS. I realise you phrased your objection such that a literal interpretation makes it be about the _proposed_ bans only. I understand that even less. People can, and do, propose bans willy-nilly regardless of how public the bans are. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131027075803.GV4353@holywood
Re: Should mailing list bans be published?
On Sat, Oct 26, 2013 at 10:46:41AM -0700, Steve Langasek wrote: This led to a philosophical debate about whether bans should be made public. Alexander expressed concern that having them published could be harmful to a person's reputation, since employers will google your name and see that you've been banned from a large project such as Debian. I think we should publish them, for several reasons: ... What do the rest of you think? I agree with you, Steve, on this issue, and for the reasons you express. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131026175724.GS4353@holywood
Re: Proposal #3: Upstream/Debian Project donations (was: PaySwarm-based donations)
On Tue, Jun 18, 2013 at 09:55:11PM -0400, Manu Sporny wrote: This is a highly re-worked proposal for performing upstream donations and donations to the Debian project. Major changes include: * Debian developers are not allowed to receive any direct monetary contribution or change the upstream DONATE file in any way. At this point, there is nothing here that is Debian specific, so I echo the suggestion that you take this to a cross-distro list, and/or the FSF, GNOME, and other big upstreams. I do, however, want to repeat my point that this kind of thing is likely to be quite divisive even outside one distro. Donations from end-users are highly likely to go mainly to highly visible projects, such as Firefox/Iceweasel and LibreOffice. Those projects are of course deserving the support, but it leaves all the less-visible but crucially important projects without the support. Which end user is going to realise that, say, freetype or GNU Make or, say, piuparts, even exists? I am, of course, biased, but I think piuparts is a nice example here, from at least two points of view. I wrote it originally, but I am no longer involved with it. How long should I still get a share of the donations? Further, piuparts is a testing tool only used by distro developers, and while it has a big impact on the quality of the distro, it's not something that will be installed on an end-user system. How will an end-user realise that they could donate to the piuparts developers as a thank you for all packages being installable, upgradeable, and removable? I thus continue to think that this whole approach of systematic, program-specific donations is misguided, and it'd be best if you dropped it. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130619065342.GH4278@havelock
Re: PaySwarm-based Debian donations (was: Re: KickStarter for Debian packages)
On Sat, Jun 15, 2013 at 11:20:47PM -0400, Manu Sporny wrote: Thanks to everyone that has participated in the discussion thus far. :) I think there have been a number of solid concerns and issues raised, which I'm going to try and wrap into a proposal below. I think it might help simplify the donations goal by framing it in the following way: Ultimately, where to send a donation is the decision of the person or organization doing the donation (the benefactor). Package maintainers, software developers, and project organizations can lobby for where they'd like to see the money go, but it's the benefactor that decides where they'd like to send the money in the end. Given that premise, all a package maintainer, software developer, or organization can do is make suggestions to the benefactor. I am afraid I find this whole approach not just questionable, but likely to distort, and damage, the free software development processes in general, and Debian development in particular. I suggest we, the Debian project, approach this very carefully. While the reality is slightly more complex, we are currently in a state where we make technical decisions mostly based on what is the right thing to do. We sometimes disagree on what the right thing is, but the disagreements are based on our interpretations of shared goals and values, and different evaluations of the various solutions, and different emphasis on various technical virtues. The more we introduce money into the development process, the higher the risk is that we get away from making decisions based on what the technically right thing is for us and for our users, and the more we will decide things based on how we can maximise our income. Be careful what you reward, because you will get more of it. Even if you don't actually want more of it. You suggest that package maintainers get to suggest where donations go. There's two glaring problems there. First, it disregards all the great things people do to make Debian better that are _not_ about packaging at all. We have translators, documentation writers, wiki gardeners, bug triagers, people who answer questions on the debian-user mailing lists in various languages, people who help staff Debian booths at various conferences, people who run user groups. And so on, and so forth. None of this work is highly visible, and it's really hard to target them with donations, yet it's often more work than maintaining packages. Second, even considering package maintainers only, targeted donations would unfairly favour those maintaining the most visible packages. If maintaining, say, Iceweasel or GNOME or Emacs results in getting money, that will certainly lessen the interest in maintaining, say, Make, coreutils, or Grub. If having your name on four hundred packages gives you ten times more money than maintaining one package well, what happens to average package quality? These are not unsolveable problems, I'm sure. However, I don't think your attitude to solving them will result in a good solution, and you may wreck things on the way. You push for a particular payment solution, and dismiss the experiences and concerns of your critics. I fear this is not a recipe for success. (Disclaimer: I used to have a consulting contract to improve the technical quality of Debian, which gave me a livelihood for about 1.5 years. The lasting result of that was piuparts.) -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616090548.GD31164@havelock
Re: Debating difficult development issues in essay form
On Wed, Jun 12, 2013 at 04:03:59PM +0200, Stefano Zacchiroli wrote: Sorry for the delay. I've now finished doing that: JessieReleaseProcess is now a subpage of Debate, and AlwaysReleasableTesting a subpage of JessieReleaseProcess, as recommended in /Debate. I've fixed all the links I've found, but redirect pages are in place, so nothing should be broken by the change. I've also created DebateTemplate, with the correct syntax for subpages. Thank you, Stefano. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130612140821.ga4...@mavolio.codethink.co.uk
Re: Revising the Code of Conduct
I suggest Enrico's Debian Community Guidelines would form a good base document for this discussion. http://people.debian.org/~enrico/dcg/ -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130521095500.ga5...@mavolio.codethink.co.uk
Re: Revising the Code of Conduct
On Tue, May 21, 2013 at 06:37:39PM +0900, Norbert Preining wrote: Hi all, On Di, 21 Mai 2013, Wouter Verhelst wrote: 1. Do not flame, use foul language, or in general be abusive or disrespectful towards other people on the mailinglists or elsewhere And who defines that? We do. Really. It's our code of conduct, and we, as a project and as a development community, get to define what it means. If you can give me a definition of foul language or abusive or disrespectful I would be happy. The old code of conduct was only containing foul, which also was already too much. Nobody can be declared authorative in deciding what is foul/abusive language. Short example: People from Siena (Italy) have a tendency for strong words, very strong words. And between friends it is very common. What is foul/abusive here? Strong language is fine, if you know all the recipients are OK with it. If you don't know that, you do your best to moderate your language. It may, of course, take you a while to learn how to do that, and that is OK: mistakes happen, we fix them, we learn, and we do better the next time. When people have goodwill and respect to each other, that kind of thing isn't a big deal. What you are suggesting, instead, is that anybody should be able to say anything, just because they can point at a cultural background, regardless of how it will affect others. That is ... not a good idea. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130521101011.gb5...@mavolio.codethink.co.uk
Re: Debating difficult development issues in essay form
On Fri, May 10, 2013 at 11:19:08AM +0200, Stefano Zacchiroli wrote: Question: there are various overlaps from this proposal and DEPs ( http://dep.debian.net/ ). Not only in some of the explicit goals you state (e.g. documenting the state of discussions), but also in the fact that other FOSS communities out there are using DEP-like solutions to address the debating difficulty. Given that Lars has been one of the main proponents of DEPs, I suspect you have put quite some thought on the relationships of the two approaches. Can you share with us what you think are the pro/con of this wrt DEPs? I haven't, actually, spent a lot of time thinking about the relationship between viewpoint essays and DEPs, but here's what I currently think: a DEP is good when there is a reasonably clear goal and there's a rough consensus on the goal, but you need to work out the details and plan and track the work to achieve the goal. For example, the goal might be make Jessie provide a backup service for desktop users out of the box, and the DEP can be used to scope and plan the work to achieve that. A set of viewpoint essays, on the other hand, are, I think, a way to keep track of a discussion as the rough consensus is formed. We can't have, say, a DEP on make $INITSYSTEM the default init system in jessie, since there is no consensus at all on which init system that would be. Tracking that discussion, and perhaps making it calmer and more rational, with fewer emotional reactions, by having the various sides write essays instead of writing rapid-fire e-mails, is what the essay initiative is about. So essays and DEPs should complement each other fairly well. About this, it's not clear to me if you actually encourage sign-offs from people other than the original authors or not. I have no strong opinion on it. I'm happy to see what happens and let people work out that kind of detail themselves. * Publish the document on as a subpage of the topic page in the wiki. Add a link to the subpage from the topic page. Technical hint: subpages syntax in Moin can be quite frustrating, especially for those who do not often edit Moin pages. It might be useful to have some sample (dangling) links for subpages pointing to alternative positions directly in the page template. (Of course I can implement the above changes myself in the wiki, but first I need to know if you agree with them or not :-)) Please do that. I obviously failed to do it with the current wiki setup (the release essay is not a subpage of the Debate page, for example). -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130512115056.gq2...@havelock.liw.fi
Re: Debating difficult development issues in essay form
On Fri, May 10, 2013 at 12:06:57PM +0200, Andreas Tille wrote: I really like this idea. The only problem I have is: How to know in advance whether a debate might concern a difficult development issue or not. I don't think there's any need to define criteria for when writing essays are warranted. If any participants in a discussion want to write some, they should go ahead. The topic at hand does not need to be difficult. Even completely friendly topics with only one viewpoint can benefit from getting written up in long form, so that all the aspects are captured on one place. Considering this would you agree to turn [2] into a Debate or would you apply further creterions for this? The important part is not whether something is listed on the Debate wiki page or not: that's just a technicality. The important part is that it's clear to everyone what the current rough consensus of something is. Your wiki page for Uscan improvements seems to capture that just fine. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130512115608.gr2...@havelock.liw.fi
Re: Debian in space
Debian: still in space http://www.debian.org/News/1997/19970708b -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130509122338.gj4...@mavolio.codethink.co.uk
Re: A Debian contributor StackOverflow
On Thu, Apr 04, 2013 at 10:32:05AM -0700, Russ Allbery wrote: A colleague of mine did an internal evaluation of possible locally-hosted StackOverflow-style applications and found one that looks pretty good: We have had http://ask.debian.net/ for a couple of years now, but I haven't looked at it in a long time. Would it do the kind of you are suggesting, Russ? I have no opinion on the software choice on what that site is currently using versus question2answer. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404175641.gn4...@havelock.liw.fi
Re: mjg59's blog on planet.d.o
On Tue, Oct 30, 2012 at 12:19:12AM +0100, Jakub Wilk wrote: AFAIK Matthew Garrett hasn't been active and directly involved participant in the Debian development community for years. What is the reason for keeping his blog on planet.d.o? Matthew has been blogging frequently over the several past years, and aggregated on Planet Debian. He has, for example, written a lot about UEFI and Secure Boot, and the different ways in which Linux and distributions can handle them. You said nothing then. Now, when he blogs about what Ted Ts'o has said about rape, you react. This sounds an awful lot like you want to remove Matthew from Planet Debian because of his opinions on that issue. It is true that Matthew does not necessarily fill the criteria for being on Planet Debian, in the strictest interpretation. However, if we remove him right now, it sends a very clear signal that this is a forbidden issue in Debian, and, as a result, that women's rights aren't welcome anymore. I don't find that acceptable. I would find it extremely unfortunate if we removed Matthew from Planet Debian right now. -- I wrote a book on personal productivity: http://gtdfh.branchable.com/ signature.asc Description: Digital signature
Re: trademark policy draft
On Wed, Aug 01, 2012 at 05:50:56PM +0200, Stefano Zacchiroli wrote: (Fearing an increase in nitpicking threshold.) Well, you can, people will, and I'm sure nobody will bother, on average. But I can imagine all sorts of journalistic declarations about Debian that would undermine the project reputation. If they are factual (or non-disprovable) fine, if not this gives the project a edge to defend its reputation/identity. This is what trademarks are about. Do I understand correctly? If a journalist says bad things about Debian, you want to use trademark law to shut them up? I think this is an abuse of the trademark system, regardless of whether the journalist is correct or not, or whether they lie or not. The purpose of the trademark system is to avoid consumers from being confused by competitors making products with similar names, but large differences. Or that's what it used to be, when I was young; these days it is a way to excercise control on people you don't like. The proper way to react to lies told about us is to respond with the correct information. Trademarks and software freedom mix badly. If I make a big change to Debian (replace eglibc with musl, or gcc with llvm), can I still call it Debian? We've struggled with that issue with Firefox, and we should not be inflicting the same pain onto others. I've been correct by Mako on this before. Short answer: hostname != domain name, so debian.mirror.my.org is perfectly fine. (No, I don't have a clear definition for domain name to offer, but it is intended here as the things that you register via a domain name registrar.) If you don't have a clear definition of what it means, then having it in the license is not acceptable, in my opinion. I don't think I want to participate in this discussion much, since the entire premise seems unacceptable to my value system. I'll leave the discussion with this counter suggestion: change the trademark policy to say: We call ourselves the Debian project. You can use our name as long as it doesn't make reasonable people confuse you or your stuff with us or our stuff, or imply that we're affiliated with or endorse you. You can use our logos under the CC-BY-SA 3.0 (US) or later license. I don't expect this to be acceptable to the rest of the project, but I also don't want to let this trademark stuff happen without objecting. -- I wrote a book: http://gtdfh.branchable.com/ signature.asc Description: Digital signature
Re: OSI affiliation
On Wed, Feb 15, 2012 at 06:41:04PM +, Steve McIntyre wrote: Hmmm. I *hope* they manage to achieve some of this, but I'll admit to being skeptical. There's been a lot more heat than light in discussions I've been seen in and around the OSI in the last few years. It would be nice to see them doing useful work. On the other hand, OSI, like everyone else, needs people who do the work, and it seems to me that it can't hurt us to have a closer relationship with them. On the other hand, if we don't do that, that will help make it harder for them to achieve anything. So I think it would be good to follow Zack's lead on this. signature.asc Description: Digital signature
Re: Security guidelines for Debian people
On Thu, Nov 03, 2011 at 03:44:36PM -0200, Henrique de Moraes Holschuh wrote: One thing we have not talked about, is that of subkey validity. It is not that kosher to have anything signed in stable with a subkey which will not be valid for the lifetime of stable, so we should keep that in mind. Assuming we're talking about each developer's personal key: what things would they be signing that matter? Package upload signatures are relevant only until the upload gets accepted into the archive, and after that it's the archive signing key that matters. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: Security guidelines for Debian people
On Thu, Nov 03, 2011 at 05:38:51PM +0100, Jakub Wilk wrote: This seems to suggest that having multiple copies of the PGP key somehow improves security. However, at least for some attack scenarios, it's quite the opposite. I'm sorry if I was too terse. The point of a backup copy of your master key is to increase safety, not security: if your master key gets destroyed by an accident (broken hardware, house burns down, etc), the backup copy makes it unnecessary for you to go through the process of getting a new key signed by other DDs and accepted into the keyring by keyringi-maint. That process can be quite time-consuming and even expensive, for those living in remote places. More copies means more things that could be stolen. And backups are often stored in distant locations, so it might be easier to swipe the copy without you noticing. Indeed. That's why I added a note that the backup copy should be stored in a safe place, as one would store one's passport. Which, I find, is a reasonable minimal standard. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: Security guidelines for Debian people
On Sun, Nov 06, 2011 at 11:52:02AM +0100, Milan Zamazal wrote: I also agree that having a best practice document is useful. Here are some suggestions for clarification: - The wiki page says: Meta-discussion note: the wiki page referred to is http://wiki.debian.org/subkeys -- and all the discussion so far has been about PGP encryption keys. Does anyone have any points about other kinds of security guidelines for Debian developers? Perhaps about how to properly check for rootkits on one's computer? This is confusing as when someone gets access to signing and encryption subkeys, he can also perform very harmful actions to Debian etc. until the real owner detects the problem and revokes his subkeys or until the subkeys expire. So keeping a master key very safe is important for other reasons: to make replacing a compromised key easier and to prevent signing other people's keys (until the compromised master key is revoked). But not to make package uploads safer, right? That's a fair point. Could you update the subkeys wiki page accordingly? - It's not clear to me how much it makes sense (unless the key is protected by a poor password) to keep a master key just on separate offline drives if it is created or used on a system that has ever been connected to a network, especially when the computer is used for other purposes than signing. That's an important value decision: where do you draw the line? I don't think it's realistic to require Debian developers to have two computers, one dedicated for using with the master PGP key. Booting off a separate medium (CD or USB drive, for example) might be a practical enough. On the other hand, I'm OK with people keeping their development systems generally secure and then also using them for the master key. Thoughts? -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Security guidelines for Debian people
On a mailing list far far away, someone wrote: Personally, I think some guidelines for DD's about securing their personal machines where their private keys are located would be a good idea. It would be a lot better than just having a vague and ineffable thing called trust. I agree. I offer the following as a first approximation, targeted specifically for key management. * These are meant to provide an idea of the minimal acceptable standard. * Store your master PGP keys on at least two USB thumb drives. - use full-disk encryption on the drives - don't use them for anything else - use the master keys only for keysigning and subkey generation - never use the drives in a computer you did not install yourself, and which anyone else has root in; preferably, don't use them in a computer anyone else uses ever - use one drive as the master, the other as a backup; refresh the backup when you make changes - store the drives in a reasonably safe place, as you would store your passport or other crucial documents; perhaps store the backup drive offsite in a safe deposit box * Create and use subkeys for everyday use. - see http://wiki.debian.org/subkeys for instructions - you can keep them on your laptop/desktop - you should still avoid anyone getting copies of them - rotate the subkeys at least once a year Suggestions for improvement? I didn't touch anything else, such as running intrusion detection systems, since I know little about them. (Run chkrootkit every morning seems so pointless.) If there's any consensus on these guidelines, someone should put them on the wiki. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken
I'll note, in public, that after meeting with Steve in person, and having had a friendly and constructive discussion about DEP5 with him, I'll be stepping down from an active drivership role, at least for a while, and Steve will take care of getting any linguistic or other changes that he feels should be done, and push things through to a final version. Meanwhile, I'll ignore everything to do with DEP5. On Sat, Sep 10, 2011 at 02:12:31PM +0900, Charles Plessy wrote: Package: debian-policy Version: 3.9.2.0 Severity: minor Subject: [copyright-format] correct or add links to SPDX. Dear all, I attached a patch that corrects or adds links to the SPDX Open Source License Registry. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: DEP: 5 Machine-readable debian/copyright - License specifications - Link broken
Oh dear. Linking to spdx.org is clearly a bad idea. We should link to locations that are stable. This should really be fixed in the debian-policy git, but since any changes there are currently having massive lag time, I'll just Cc debian-project to notify people of the problem, while we figure out what to actually do. (I do not want to make any changes that may have to be made in many places.) On Fri, Sep 09, 2011 at 12:22:15AM +0200, m...@cryptolab.net wrote: First of all sorry for my bad english, i'm italian. On the page http://dep.debian.net/deps/dep5/ some link of license are broken. - Apache license 1.0 http://spdx.org/licenses/ASL-1.0 was changed in http://spdx.org/licenses/Apache-1.0 - Apache license 2.0 http://spdx.org/licenses/ASL-2.0 was changed in http://spdx.org/licenses/Apache-2.0 - CDDL http://spdx.org/licenses/CDDL was changed in http://spdx.org/licenses/CDDL-1.0 - GNU Library General Public License 1.0 http://spdx.org/licenses/LGPL-1.0 was changed in ? ( On http://spdx.org/licenses/ is present GNU Library General Public License v2 only and GNU Library General Public License v2 or later. - GNU Free Documentation License http://spdx.org/licenses/FDL-1.0 was changed *probably* whit http://spdx.org/licenses/GFDL-1.1 - Python license http://spdx.org/licenses/Python-CNRI was changed in ? ( The only version is Python License 2.0 : http://spdx.org/licenses/Python-2.0 ) - Zope Public License 1.0 was changed in Zope Public License 1.1 http://spdx.org/licenses/ZPL-1.0 was changed in http://spdx.org/licenses/ZPL-1.1 Thanks! -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: [DEP 5] URI to SPDX license list and good news from the OSI.
On Sun, May 29, 2011 at 12:19:22PM +0900, Charles Plessy wrote: Currently, the full text of the licenses is only available in the ulink -url=http://spdx.org/wiki/working-version-license-list;working version -of the SPDX license list/ulink. +url=http://spdx.org/licenses;SPDX Open Source License Registry/ulink. Looks good to me, please apply the patch. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110529155452.gb18...@havelock.liw.fi
Re: DEP0 driver wanted
Welcome Charles, and also Ben Finney, as new DEP0 drivers. I've added you as admins to the Alioth project. Please add yourselves to the DEP0 document as drivers, and drop me at the same time. Thanks. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110526104223.gc5...@havelock.liw.fi
DEP0 driver wanted
In 2007 Stefano, Dato, and I cooked up the Debian Enhancement Proposal system. It is meant as an lightweight system to keep track of discussions, and record what has been decided. Each DEP has one or more drivers, and ideally, only the drivers need to care about it. Everyone else just responds on mailing lists as before. DEPs have been used several times now, with DEP3 being perhaps the best example. The DEP0 is a bit special, in that its drivers are taking care of the DEP website and other things to keep things running smoothly. They aren't required to participate in discussions about DEPs, but may decide that a particular DEP has stalled and should be resurrected, or perhaps abandoned. If a driver disappears, the DEP0 drivers might find a new driver, for example. Due to other commitments, I would like to step down as a DEP0 driver. This would leave Stefano as the only active DEP0 driver. That seems about one person too few. So we're looking for new people. There are no urgent problems to be fixed, but a possible future improvement would be to switch the DEP repository from Subversion to git, or another DVCS. The dep.debian.net website is currently reachable via http://dep.alioth.debian.org/ due to the Alioth move. The old url http://dep.debia.net/ will start working again at some point. (Something about vhost setup having changed.) Would anyone like to step up as a DEP0 volunteer? More than one are welcome. Reply to this mail if you're interested, and request to join the https://alioth.debian.org/projects/dep/ project, and Zack and I will take it from there. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524141435.ga24...@havelock.liw.fi
Re: audible compatibility with linux
On ti, 2011-04-12 at 23:13 -0700, Victor Jones wrote: Audible says At this time Audible is not compatible with the Linux operating system. Audible is actively pursuing compability with Linux in all versions by pursuing support from the open source community that develops this platform. I joined Audible in 2002 and saw that exact message shortly after and it has not changed to this date today. Audiible is one of the big reasons I have heard people say they will not switch to linux. There are already ways to take out the protections and turn the audio books to mp3 files, but I have a very large library on their site and need (as do many other people) for it to just work. Just work is what Ubuntu is all about. If you do not think it is serious just do a Google search for Audible linux and you will come out with a different frame of mind. Could someone please contact them and tell them how much money they are losing? In the process please offer to work with them to make Audible compatible with the Linux operating system. Ubuntu is the largest and should have a little bit of pull in whatever negotiations are needed. It would help if the other OS's would get on the wagon for the long haul. You sent the mail to a Debian mailing list, but you ask Ubuntu to do things. You may want to check https://lists.ubuntu.com/ for a more suitable list. That said, there is nothing anyone else can or need to do to get Audible to work with Linux distributions and other systems based on freedom. Audible can just drop the DRM on their files, and use a commonly accepted format instead, such as MP3 (or Ogg Vorbis, for even more freedom). -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1302676823.2921.5.ca...@havelock.liw.fi
Re: dep5 appendix wording
On ke, 2011-03-09 at 10:16 +0900, Charles Plessy wrote: I think that it is a good idea to clarify the Policy. Would you like to open a bug or shall I ? I actually wonder if the DEP's appendix is really needed… I think that it appeared when I tried to un-brand the proposal. But this was eventually given up. There is another Policy change in the pipeline (seconded by there persons) for dropping the ‘should’ requirement to document the original packagers: see http://bugs.debian.org/593533 After this change is applied, I propose to remove the appendix entirely. We can add a hyperlink to Policy §12.5 in the ‘File syntax’ section to compensate. I agree that the paragraph could be removed. I don't actually feel the need to explain in the DEP5 spec what the Policy requires in debian/copyright. Policy already does that, and it's required reading for anyone making packages for Debian, so even just linking to it should be unnecessary. I've removed the appendix in svn. If anyone feels a link should be added, please suggest exact location and wording (a patch would be welcome). -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299777453.3524.31.ca...@havelock.lan
Re: DEP5: extra fields compliant with the spec? [Was, Re: New version of DEP-5 parser]
On su, 2011-01-23 at 12:29 -0800, Steve Langasek wrote: I have always been lukewarm on the idea of specifying within the DEP itself that extra fields can be added without standards-compliance implications. I don't think people should be adding random fields here without first *defining* those fields; and with DEP5, defining them is as straightforward as taking a copy of the DEP, adding your field definitions to it, posting that modified document to the web and referencing the new URL in your Format: declaration. It's not like this even requires you to write a formal XML DTD or something, so I really don't think this is too high a barrier; and if someone thinks that it is, there's always the Comment: field already defined for the purpose of including arbitrary text in the document. It would be my strong preference to see the language in DEP5 clarified in this manner, and parsers modified to treat unknown fields as validation *failures* when referencing a known Format: URL. Would you like to propose a patch for discussion? My personal preference, at this time, would be to not change DEP5 about this, but re-visit it later if this turns out to be a problem. If the consensus on -project is that changing the spec now is better, however, then let's do that. (I see my current role as DEP5 driver to stand on the brake so we make only those changes that are really seemed necessary, so we can get this thing out of the door eventually. I'm not opposed to further changes, but I would like to avoid re-visiting things unless there's a strong need. I keep noticing things I'd like to do entirely differently, but stopping myself from suggesting them.) -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295975424.4771.52.ca...@havelock.lan
Re: [DEP5] License field in the first paragraph ?
On la, 2011-01-22 at 14:47 -0800, Steve Langasek wrote: So a License could appear without a Copyright (to indicate the effective license of a work), but a Copyright should not appear without a License. If that's true, I think it's important to call it out in the spec. I'll add the following words to Charles's patch: It is possible to use only License in the header paragraph, but Copyright alone makes no sense. I hope that's acceptable. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295772127.2989.25.ca...@havelock.lan
Re: [DEP5] License field in the first paragraph ?
On la, 2011-01-22 at 18:48 +1100, Ben Finney wrote: Charles Plessy ple...@debian.org writes: Le Tue, Jan 18, 2011 at 11:42:17PM +0200, Lars Wirzenius a écrit : There seems to be consensus to add an optional License field to the first paragraph. […] Here is a first attempt. Comments welcome: the discussion was a bit complex and I am not sure if I summarised it well. One aspect I don't see covered in your patch: ‘Copyright’ and ‘License’ only make sense as a pair (details in the preceding discussion). I think the standard should specify that if either is used, both must be used. I find it reasonable to use only License, to indicate that a specific license applies to the package as a whole, without having any one party have a copyright on the package as a whole. If the package contains of files A and B, with A being GPL2+ and B being GPL3+, the header paragraph's License field could say GPL3+. There would still be no need to have a Copyright field in the header paragraph. I would prefer to keep things simpler, and not have a rule about when either field requires the other. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295687091.2989.6.ca...@havelock.lan
Re: DEP5: Format example patch
On to, 2011-01-20 at 09:42 +0100, Stefano Zacchiroli wrote: Agreed to both, but don't underestimate the risks of copy-paste. I suggest the attached patch, which uses an explicit invalid placeholder in the examples, hoping it's clear enough that it's a placeholder. Applied, thanks. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295606641.10134.0.ca...@havelock.lan
Re: DEP5: Public domain works
On ke, 2011-01-19 at 20:55 +1100, Ben Finney wrote: That appeared inappropriately line-wrapped when I received it. Here it is as an attachment. Applied, thanks. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295509229.2927.4.ca...@havelock.lan
Re: DEP5: Format example patch
On ti, 2011-01-18 at 16:05 +0100, Jonas Smedegaard wrote: I therefore recommend to instead switch to the versioned format again, which also - now that we are back to Subversion - fits within 72 chars: Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?rev=162 From http://lists.debian.org/debian-devel/2011/01/msg00340.html: I would rather avoid it, though, since then the examples need to be updated every time, and I'm lazy. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295386127.3740.156.ca...@havelock.lan
Re: DEP5: ready for CANDIDATE?
On ti, 2011-01-18 at 08:00 +0900, Charles Plessy wrote: I am hoping that given SPDX is advancing towards beta release, they will fill these pages in a not too long time. But in the meantime, we could add a link to their license table, if necessary: diff --git a/dep5.mdwn b/dep5.mdwn index 09da1e1..1b217de 100644 --- a/dep5.mdwn +++ b/dep5.mdwn @@ -383,6 +383,9 @@ of that license, the short name is finished with a plus sign. For SPDX compatibility, trailing dot-zeroes are considered to be equal to plainer version (e.g., 2.0.0 is considered equal to 2.0 and 2). +Currently, the full text of the licenses is only available in the +[working version the SPDX license list](http://spdx.org/wiki/working-version-license-list). + Applied. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295386758.3740.157.ca...@havelock.lan
Re: [DEP5] License field in the first paragraph ?
On ma, 2011-01-17 at 21:11 -0800, Russ Allbery wrote: Ben Finney ben+deb...@benfinney.id.au writes: Charles Plessy ple...@debian.org writes: I am worried that there was a misundertanding about the purpose of the first paragraph's Copyright field: from my reading of the current version of the DEP (and independantly of how my opinion on how it should be) The explanation in the DEP doesn't really make it clear why this is needed, as opposed to an initial “Files: *” paragraph with the “package as a whole” copyright and license values. Where is the rationale for having Copyright apply in the header? We talked about this several times, I think. We should probably capture the rationale in the standard since it keeps coming up again. Files: * implies that each individual file is covered by that copyright and license. The intent of putting Copyright and License in the top header was to specify the copyright and license for the collective distribution, separate from the copyright and license for any individual file. I'm not sure how License fell out of that. It was always supposed to include both, I think. Having Copyright without License isn't horribly useful. I was one of the people who specifically requested this, since one of the purposes to which I want to put DEP-5 requires some way of specifying the collective copyright and license for a package as a whole, regardless of the individual licenses of some files. This is not the same thing as a Files: * block that's overridden by more specific Files: blocks. There seems to be consensus to add an optional License field to the first paragraph. Anyone want to make a patch, and perhaps include some version of Russ's explanation above as rationale, so that we don't get endless questions about this in the future? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295386937.3740.158.ca...@havelock.lan
Re: DEP5: Please drop requirement of stripped source being mentioned in Source:
On ti, 2011-01-18 at 02:35 +0100, Jonas Smedegaard wrote: ...except I am now forced to *duplicate* those excluded files in a non-machine-extractable format inside the Source: field due to that recent simplification. Or continue to duplicate that info across debian/copyright and debian/rules as done in the lack of DEP5. As far as I understand, you only need to mention the fact that the source has been re-packaged in the Source field, you don't need to explain in detail what you did. Even if it did, you could just point at your custom headers instead of duplicating the information. So I see no need to change the current wording. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295387475.3740.161.ca...@havelock.lan
Re: DEP5: CANDIDATE and ready for use in squeeze+1
Charles and Ben have offered competing patches for Source, one making it optional (but relying on the policy to make it implicitly mandatory in most cases), the other making it required (but allowing just a mention of upstream sources not existing, when that is the case). Is anyone in favor of one or the other? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295387871.3740.163.ca...@havelock.lan
Re: DEP5: Public domain works
On ti, 2011-01-18 at 17:03 -0800, Russ Allbery wrote: I'm happy to see public domain added as a license keyword. This is the consensus, it seems. Would anyone like to suggest a patch to implement it? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295417801.3740.167.ca...@havelock.lan
Re: DEP5: CANDIDATE and ready for use in squeeze+1
On ke, 2011-01-19 at 10:27 +1100, Ben Finney wrote: Steve Langasek vor...@debian.org writes: I am vehemently opposed to Ben's patch, which is effectively an end run around Debian Policy. That's a fair criticism. I should make a bug report against Policy. Good, then I'll apply Charles's patch. Thanks. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295417880.3740.168.ca...@havelock.lan
Re: DEP5: ready for CANDIDATE?
Applied all three patches, thanks. On to, 2011-01-13 at 09:53 +0900, Charles Plessy wrote: Le Wed, Jan 12, 2011 at 09:09:09PM +0200, Lars Wirzenius a écrit : I think I agree with your proposal to link to SPDX. Alternatively, we could collect the licenses as attachments to the spec, or point at the ones on the OSI site. I'd rather avoid attaching things, but otherwise I'm fine with anything. Charles, would you be willing to provide a patch to link to SPDX and fix the FreeBSD shortname issue? I seem to have shown myself to be a bit careless with this license thing, and I make sloppy edits (this is probably because I find this part to be the least interesting one, and one that I've dreaded for months). I just realised that the SPDX site is not yet ready as their license links point to empty pages: http://spdx.org/licenses/ I attached three patches. The first removes the FreeBSD license, the second adds missing links to upstream pages, and the last points all the links to SPDX instead. I think that we should wait before applying the third and use the second in the meantime. In addition I noticed a minor mismatch between the SPDX license list page and the SPDX license spreadsheet: in the first the Apache license is ‘ASL’, and in the second it is ‘Apache’. The third patch may therefore need some adjustment, depending on how SPDX resolves this. Have a nice day, -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295095823.3740.27.ca...@havelock.lan
Re: DEP5: CANDIDATE and ready for use in squeeze+1
On pe, 2011-01-14 at 17:05 +0900, Charles Plessy wrote: Le Fri, Jan 14, 2011 at 08:56:16AM +0100, Stefano Zacchiroli a écrit : On Fri, Jan 14, 2011 at 03:20:37AM +0200, Lars Wirzenius wrote: and it's ok by Policy, then I'd be happy to apply a patch someone provides. :) Index: dep5.mdwn === --- dep5.mdwn (revision 157) +++ dep5.mdwn (working copy) @@ -149,12 +149,14 @@ will usually be written as a list of RFC5822 addresses or URIs. * **`Source`** - * Required + * Optional * Syntax: formatted text, no synopsis * An explanation from where the upstream source came from. Typically this would be a URL, but it might be a free-form explanation. If the upstream source has been modified to remove - non-free parts, that should be explained in this field. + non-free parts, that should be explained in this field. This field + is mandatory for non-native Debian packages; it can be omitted for + native Debian packages. * **`Disclaimer`** * Optional I would recommend to stick to Policy's words: if there is no upstream sources, the field is not required. I went with the patch below. Thanks Zack, Charles, Andrei. Index: dep5.mdwn === --- dep5.mdwn (revision 161) +++ dep5.mdwn (working copy) @@ -149,12 +149,17 @@ will usually be written as a list of RFC5322 addresses or URIs. * **`Source`** - * Required + * Required, unless there is no upstream * Syntax: formatted text, no synopsis * An explanation from where the upstream source came from. Typically this would be a URL, but it might be a free-form explanation. If the upstream source has been modified to remove non-free parts, that should be explained in this field. + This field is mandatory, unless there are no upstream sources, + which is mainly the case for native Debian packages. + See [Debian Policy, + 12.5](http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile) + for details. * **`Disclaimer`** * Optional -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1295096619.3740.30.ca...@havelock.lan
Re: DEP5: CANDIDATE and ready for use in squeeze+1
On to, 2011-01-13 at 17:15 -0800, Russ Allbery wrote: Yeah, I think Source should be optional for native packages. Would anyone oppose making such a change? Does Policy allow it? If there's consensus for, and it's ok by Policy, then I'd be happy to apply a patch someone provides. :) -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294968037.6791.143.ca...@havelock.lan
Re: DEP5: CANDIDATE and ready for use in squeeze+1
On su, 2011-01-09 at 20:42 +0100, Dominique Dumont wrote: Le vendredi 7 janvier 2011 11:09:59, Dominique Dumont a écrit : I'll update DEP5 description (aka Debian::Dpkg::Copyright model [1]) as soon as I've stabilised the latch batch of modifications in config-model. I've taken a stab at implementing the new specification. I've a new description matching the CANDIDATE DEP-5. (the new model is able to parse the new example, but I still need to polish the non-reg tests) As a bonus, Config::Model will be able to migrate copyright files from older specification to the new spec. Cool! One question: if the File: * line in the first File paragraph is missing (*), should it be added automatically ? Nope, the Files field must always be there explicitly. (Note that it's Files, not File, but I expect that was just a typo in your mail.) (*) the examples shown in http://dep.debian.net/deps/dep5/ page are lacking a File: * line in the first File paragraph. You're right, and the spec's examples are wrong. Fixed in r157. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294853871.6791.42.ca...@havelock.lan
Re: DEP5: CANDIDATE and ready for use in squeeze+1
On ke, 2011-01-12 at 19:16 +0100, Jonas Smedegaard wrote: Is that so?!? Then please clarify what the paranthesis below means: Files: Required (not in header paragraph). It means that in the first paragraph (called header paragraph for reasons I am not entirely sure of), the Files field is not required. The first paragraph applies to the package as a whole, rather than each file separately. In the other paragraphs, the Files field is required, and those paragraphs apply to each file separately. This is a subtle distinction, and may be too subtle for me, but seems to be important. My understanding is that our previous special handling of an initial Files: * section was changed into the header paragraph having an implicit Files: * section with optional Copyright and License added. Yes, something like that happened. I thought things were clear at the time. If not, then it may be necessary to re-open this point. The history, however, matters less than the actual specification text. The people of the future will read the spec only. If you, or anyone, has a clarification or other change to propose, please do so with a diff to be applied to the svn version. At this stage, I don't want to make any changes that are not obvious minor bugs, and I do not want the burden of formulating further changes myself. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294858617.6791.56.ca...@havelock.lan
Re: DEP5: ready for CANDIDATE?
On ma, 2011-01-10 at 19:24 +0900, Charles Plessy wrote: The current version of the DEP specifies that the differences with the SPDX format will be tracked. My understanding of this, and the discussions we had before, is that we will use the same short names than SPDX unless specified otherwise. The SPDX list includes a full copy of the license, and a beta program is starting, with the aim of releasing a spec within three months. http://spdx.org/wiki/beta-program-doc-and-email-blurb I think that if they acheive their schedule, SPDX 1.0 will be out before DEP5 is declared ACCEPTED. Then we could simply refer to SPDX 1.0 and its license list, which is comprehensive. Also, if we have additions or changes to suggest, it is perhaps not too late. Also, it is not too late to ask the Linux Foundation that the SPDX specification will be redistributable by Debian. Its license is Creative Commons Attribution 3.0, and according to the Debian wiki it may be acceptable in our archive. But we will need the source PDF. Also, some license texts themselves are not modifiable, but since we already make an exception for the GPL, we may make one for them as well ? For the current list in the DEP's revision 154, I think that Lars forgot to remove the FreeBSD license when he added the BSD-2-clause, which is how SPDX calls it. I can also add links to the licenses in the DEP, following the patch that I sent earlier (http://lists.debian.org/20100814075847.ge5...@merveille.plessy.net). I think I agree with your proposal to link to SPDX. Alternatively, we could collect the licenses as attachments to the spec, or point at the ones on the OSI site. I'd rather avoid attaching things, but otherwise I'm fine with anything. Charles, would you be willing to provide a patch to link to SPDX and fix the FreeBSD shortname issue? I seem to have shown myself to be a bit careless with this license thing, and I make sloppy edits (this is probably because I find this part to be the least interesting one, and one that I've dreaded for months). -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294859349.6791.63.ca...@havelock.lan
Re: DEP5: CANDIDATE and ready for use in squeeze+1
On to, 2011-01-06 at 20:55 +, Lars Wirzenius wrote: I have just pushed out the CANDIDATE version of DEP5 to the DEP subversion repository. DEP5 is the specification for a machine-readable format for debian/copyright files, the use of which will be optional. I consider this version (r153) to be ready for production use. To clarify: this: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?rev=153sc=0 I've also filed a bug for inclusin into the debian-policy package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609160 For the bug, I modified the markup in the spec to be pure markdown and avoid ikiwiki-specific extensions. I also changed the Format: urls to point at what will become the publically available one if debian-policy accepts the patch. I don't _think_ I did any semantic changes, but please prove me wrong. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294394191.20273.23.ca...@havelock.lan
DEP5: CANDIDATE and ready for use in squeeze+1
I have just pushed out the CANDIDATE version of DEP5 to the DEP subversion repository. DEP5 is the specification for a machine-readable format for debian/copyright files, the use of which will be optional. I consider this version (r153) to be ready for production use. Those using an earlier version of the format will hopefully start upgrading to it, as soon as squeeze is released. However, there is a final little detail to get fixed, which is that the Format: field is supposed to get a stable URL, and the spec should get integrated into the debian-policy package. Once that has been done, DEP5 will go into ACCEPTED state. An e-mail to debian-devel-announce will happen then. The bzr repository for DEP5 will now be frozen. All further changes will happen in the DEP svn repository, until the spec moves to debian-policy. Yours truly, Lars master bikeshed painter and professional provocateur Wirzenius -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294347338.20273.5.ca...@havelock.lan
Re: DEP5: ready for CANDIDATE?
All of the below is now done, I've today done the final bits by splitting BSD into BSD-[234]-clause and renaming some licenses to match the names in SPDX. As far as I know, these were the final changes that were needed. Does anyone object if I change the status of DEP5 to CANDIDATE, and push the version in bzr to svn at the same time? If nobody objects, I will do that in the early days of January, and announce this on debian-devel-announce. After that, the final steps for the spec should be the following: * integrate the spec with the debian-policy package * as part of that, set up a stable URL Of course, if any bugs in the spec are found, they can and should still be fixed. I hope that no large changes will turn out to be necessary. On ma, 2010-12-20 at 21:43 +, Lars Wirzenius wrote: A summary of differences found by Charles and others, if I have understood correctly, with comments. * SPDX sometimes adds a license version, when we don't, or adds a .0 to license version = ignore? the difference should not matter much = maybe suggest to SPDX they drop the .0 * SPDX does not have some licenses we do (Artistic v1, CC0, Expat, Perl, GFDL without invariants) = ignore: it's OK for us to have names for more licenses = but remove Perl as a shortname in DEP5 * SPDX has BSD 3 and 4 clause licenses with placeholders = ignore: we'll just have many variants of BSD (called other-FOO or whatever) * BSD license versions = adopt SPDX naming: BSD-2-clause (from FreeBSD), BSD-3-clause, BSD-4-clause (do dashes clash with license version syntax?) * SPDX represents or later as a different license, where we have a generic syntax, but end result is same = ignore * SPDX treats each GPL exception as a separate license = ignore, and suggest to SPDX they adopt DEP5 approach * LGPL+ means in SPDX that no version was specified, but no such convention for the GPL = ignore, it's their problem, our syntax supports it anyway * SPDX calls it FDL, DEP5 calls it GFDL = ask SPDX to rename, since GFDL is the logical name, otherwise maintain a mapping table * SPDX calls it Python and Python-CNRI, DEP5 calls it PSF = rename in DEP5 * SPDX calls them EFL, W3C, Zlib = rename in DEP5 * SPDX links to http://www.opensource.org/licenses/mit-license.html = add link to DEP5 * I've fixed DEP5 to use the right versions for the Perl example (thanks, gregoa) Any comments on this? Did I miss anything, or misunderstand something? Are all above suggestions acceptable? If so, I'll make the changes and push things to svn. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293749342.13186.19.ca...@havelock.lan
Re: DEP5: common abbreviation for GNU FDL (was: DEP5: License section)
On pe, 2010-12-31 at 10:38 +1100, Ben Finney wrote: Lars, can you point us to a rationale for that to-do item? Er, sorry, I can't. I misread my notes (mixed up FDL with the .0 stuff). I'll remove that from the wiki. Thanks for pointing it out, Ben. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293752578.13186.20.ca...@havelock.lan
Re: DEP5: reasons for not pushing Bazaar changes to Subversion
On to, 2010-12-23 at 09:55 +0100, Stefano Zacchiroli wrote: So, let's get back to the basic principles at stake. The point hardly is Bzr vs SVN; rather it seems to be whether the working draft of a DEP should be constantly updated and trivially accessible, for instance on the web at the canonical URL listed at the beginning of the DEP text. 1) The argument in favor of that approach is: it diminish to the very minimum the barrier for all people interesting in contributing. 2) The argument against that, which has been mentioned earlier on in DEP-5 discussions, is: it encouraged proliferation of adoptions of working drafts, creating an incompatibility mess. In general, I find that the benefits of (1) largely outweigh those of (2). The status of a DEP is clearly marked and if people would like to adopt a DRAFT, well, they are on their own in keeping up with the evolutions of the format later on. I entirely agree with this. In the general case DEP drafts should be public, even aggressively so. In the specific case of DEP-5 however, I understand the sensibility of the drivers about (2). Half-baked versions of the format, not really controlled by anyone, have been floating around for a long while. Even more so, at some point there has been a sort of encouragement in adopting ever-evolving version of the format by pointing to a specific revision of it. So, while I believe that advantages of (1) outweighs those of (2), even in the case of DEP-5, I can't really blame the drivers for having chosen a more conservative approach. I agree with this as well. Further, quite a number of people were against the entire idea of a machine-readable debian/copyright files, and it seems to me that was due to the way the spec was being developed over the years. The fact that it took years was, itself, also a problem. This should only take a few weeks, at most. (It's taken five months already since I became a driver, for which I apologize. I should have made things go faster.) At least the most vocal complaints about the DEP5 concept and format seem to have died away recently. It's even been a while since anyone offered DEP5 as an example of why the entire concept of DEPs was unworkable. This sensitivity within the Debian development community to the issue is the other reason I don't want to have lots of versions of *this* spec in actual use. It's not just the practical effort that's going to be required to update from umpteen different formats to the final one, it's also that I want to minimize any further the aggravation from this. Now I have failed to do that, in another way. I also agree with Charles that we're about ready to finish the DRAFT stage, and can stay with status quo until then. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293104902.23963.130.ca...@havelock.lan
Re: dep5, whats the status? Re: DEP5: reasons for not pushing Bazaar changes to Subversion
On to, 2010-12-23 at 12:34 +0100, Holger Levsen wrote: Hi, for those who are just marking mails in this thread as read... ;-) On Donnerstag, 23. Dezember 2010, Charles Plessy wrote: Using revision 135 of the DEP from svn.debian.org is a waste of time, for the people who would like to write a copyright file, or for the peopole who would like to write a parser. I strongly recommend against using it. is there a revision not being a waste of time^w^w^w^w^wworth adapting by now? I, personally, think it would be better to wait for the first version of DEP5 that is marked CANDIDATE, which I intend to announce on debian-devel-announce. Hopefully that will happen quite soon. Those who already use some revision, such as pkg-perl, should stick to what they are using now. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293105119.23963.133.ca...@havelock.lan
Re: DEP5: License section
On ke, 2010-12-22 at 15:29 +0100, Jonas Smedegaard wrote: The canonical URL http://dep.debian.net/deps/dep5/ has been updated too - but by hand, with a warning at the top that it might go stale. Actually, I was quite happy with the way things were. The draft of DEP5 in svn was and is the version people should use, if they want to use DEP5 now. The version in bzr is the one I edit based on discussions, until it's stable enough to start suggesting people use. This way, there is little fear from changing the working draft, since nothing bad will happen. I would like this to continue. I appreciate the desire to help, but please revert your change. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293030144.23963.84.ca...@havelock.lan
Re: DEP5: License section
On ke, 2010-12-22 at 02:23 +0900, Charles Plessy wrote: Le Tue, Dec 21, 2010 at 04:54:56PM +, Lars Wirzenius a écrit : On ti, 2010-12-21 at 14:04 +0100, Jonas Smedegaard wrote: I don't have an opinion on whether MIT license is ambiguous or not, but notice that it is still (in Bazaar repo as of today) not listed in the Short name section, but _is_ listed in the Problematic Licenses section. So your proposal to add link to DEP5 is, I believe, tied to removing it from Problematic Licenses, and this we should discuss. No, I don't suggest that at all. I suggest keeping it where it is and adding a link to it. I don't care what happens to it, so nothing else will happen unless and until someone proposes concrete changes. I suggest to remove the whole section about problematic licenses: - If we indicate a reference form for the MIT license, then it has its place in the short name table. - Description of the Copyright field already specifies that it is where public domain should be mentionned. - The part about PHP explains that the reason why it is not in the list of short names; but I do not thing why we should make a justification for PHP in particular. I think I agree with Charles, and we should remove the section. Nobody seems to have objected to it. I agree with Ben that MIT is an ambiguous name, and Expat is better, when it is the one people mean. I'll add a note about this. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293030752.23963.98.ca...@havelock.lan
Re: DEP5: License section
On ke, 2010-12-22 at 16:50 +0100, Jonas Smedegaard wrote: I respect your great work here, Lars, but disagree with your style. If you disagree with my reasons for doing edits in bzr and not pushing changes to svn all the time, you can argue those. You even have an excellent chance of convincing me that way. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1293034630.23963.116.ca...@havelock.lan
Re: DEP5: License section
On ti, 2010-12-21 at 00:15 +0100, gregor herrmann wrote: Or for one page that links to both: http://www.perlfoundation.org/legal Thanks, picked that one. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292926578.23963.0.ca...@havelock.lan
Re: DEP5: License section
On ti, 2010-12-21 at 00:37 +0100, Jonas Smedegaard wrote: On Mon, Dec 20, 2010 at 09:43:53PM +, Lars Wirzenius wrote: * SPDX has BSD 3 and 4 clause licenses with placeholders = ignore: we'll just have many variants of BSD (called other-FOO or whatever) Related to this, there are few oddities regarding other licenses: In Files section the License field is required but allowed to be completely empty (as long as a later License section named other is included). I suggest simplifying to always require an explicit license shortname (i.e. drop the implicit other name). Agreed. Done. The License shortname list includes an other name describes as being any other custom license. Nowhere is it explicitly described that other-FOO or FOO is allowed in addition to the officially listed shortnames. I suggest to replace that final other shortname in the list with a short text decribing explicitly that a) any custom names is permitted, b) it is encouraged to use a custom name that might be suitable for later adoption in the official list, and c) it is encouraged to use a leading other- for exotic licenses unsuitable for adoption in the list. The License field description includes this (after the above modification; the wording at the beginning was slightly different earlier): If there are licenses present in the package without a standard short name, an arbitrary short name may be assigned for these licenses. These arbitrary names are only guaranteed to be unique within a single copyright file. Should be clear enough. NB! These comments are based on the latest published rev. 135 draft. If fixed in later drafts, I apologize for the noise. That would be revision 135 in svn, not bzr, I assume. Go to http://bzr.debian.org/scm/loggerhead/dep/dep5/trunk/annotate/head:/dep5.mdwn to see the current revision in bzr. (Not sure why this is so hard to find.) * SPDX links to http://www.opensource.org/licenses/mit-license.html = add link to DEP5 Draft rev. 135 lists only Expat, but mentions MIT license as being ambiguous. Is the ambifuity solved in newer revisions? Is Expat preserved or replaced by MIT license? I don't actually see the ambiguity. Do you have a specific change to suggest? How would you word it? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292927182.23963.8.ca...@havelock.lan
Re: DEP5: License section
On ti, 2010-12-21 at 09:25 +1100, Craig Small wrote: On Mon, Dec 20, 2010 at 09:43:53PM +, Lars Wirzenius wrote: * SPDX sometimes adds a license version, when we don't, or adds a .0 to license version = ignore? the difference should not matter much = maybe suggest to SPDX they drop the .0 I'd suggest that to SPDX but if they don't change just put in something that Foo-1.2 implies Foo-1.2.0 or even Foo-1.2.0.0 Sure, that sounds reasonable. The rest of it I agree, the only thing is that any differences should be documented somewhere so when someone comes along to this standard they don't have to trawl debian-project email archives to work out why we have GFDL and SPDX has FDL (for example). A reference somewhere stating the differences would be enough, perhaps not in DEP5 itself, but somewhere, such as the wiki. Good point. I added the list I currently have to the wiki[0] and modified the DEP5 draft to include that link. [0] http://wiki.debian.org/Proposals/CopyrightFormat -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292927535.23963.9.ca...@havelock.lan
Re: DEP5: License section
On ti, 2010-12-21 at 14:04 +0100, Jonas Smedegaard wrote: On Tue, Dec 21, 2010 at 10:26:22AM +, Lars Wirzenius wrote: On ti, 2010-12-21 at 00:37 +0100, Jonas Smedegaard wrote: The License shortname list includes an other name describes as being any other custom license. Nowhere is it explicitly described that other-FOO or FOO is allowed in addition to the officially listed shortnames. I suggest to replace that final other shortname in the list with a short text decribing explicitly that a) any custom names is permitted, b) it is encouraged to use a custom name that might be suitable for later adoption in the official list, and c) it is encouraged to use a leading other- for exotic licenses unsuitable for adoption in the list. The License field description includes this (after the above modification; the wording at the beginning was slightly different earlier): If there are licenses present in the package without a standard short name, an arbitrary short name may be assigned for these licenses. These arbitrary names are only guaranteed to be unique within a single copyright file. Should be clear enough. It solves a) but not b) or c). I don't think it is appropriate for us to make DEP5 users make value judgements on what licenses are or are not suitable for inclusion into the official list of shortnames. I don't have an opinion on whether MIT license is ambiguous or not, but notice that it is still (in Bazaar repo as of today) not listed in the Short name section, but _is_ listed in the Problematic Licenses section. So your proposal to add link to DEP5 is, I believe, tied to removing it from Problematic Licenses, and this we should discuss. No, I don't suggest that at all. I suggest keeping it where it is and adding a link to it. I don't care what happens to it, so nothing else will happen unless and until someone proposes concrete changes. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292950496.23963.18.ca...@havelock.lan
Re: DEP5: License section
I'll respond to several mails in this one. * patch from Zack to fix broken example applied, thanks * added SPDX section, since nobody objected to it; with gregoa's fix * yes, we (the DEP5 drivers) have communicated with Kate Stewart and the SPDX people, though not very much yet; I don't have time to follow SPDX, perhaps someone else would be interested in that task? * I'll push the current version from bzr to the dep.debian.net svn soon * the current version in bzr is at http://bzr.debian.org/scm/loggerhead/dep/dep5/trunk/annotate/head:/dep5.mdwn (which link is on http://wiki.debian.org/Proposals/CopyrightFormat, too), except when loggerhead on alioth is broken (in which case you should report it to alioth admins if you notice it) I'll reply directly to Charles's e-mail about differences between DEP5 and SPDX. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292877734.4384.23.ca...@havelock.lan
Re: DEP5: License section
On to, 2010-12-16 at 17:04 +0100, Stefano Zacchiroli wrote: On Thu, Dec 16, 2010 at 04:30:08PM +0100, Jonas Smedegaard wrote: Uhm, this unfortunately is not the latest draft; Lars: can you confirm that the diff produced by Charles still applies? Do we even have any newer draft publicly available? ...i.e. accessible not only by VCS but also web browsable. AFAIK, no, but I understand that Lars is going to publish that ASAP (after consensus would probably better match his stance :)). In fact, DEP5 choice can be seen as introducing new license names as well, except that they include spaces and provide a clear convention, e.g. GPL-2+ with OpenSSL exception. Which reveals a related issue: DEP5 currently (or at least r135 of it) lists only non-space shortnames for licenses but do not require a shortname to not include spaces. Do we want that clarified? Nice catch. Given that we are relaying on some sort of word tokenization for things like exceptions, I'd say that we certainly want to. I've changed: ## Syntax -License names are case-insensitive. +License names are case-insensitive, and may not contain spaces. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292879559.4384.27.ca...@havelock.lan
Re: DEP5: License section
On to, 2010-12-16 at 14:08 +0100, gregor herrmann wrote: * The link in For versions, consult the Perl Foundation doesn't lead to the expected page. Can you give a good link? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292881127.4384.55.ca...@havelock.lan
Re: DEP5: License section
A summary of differences found by Charles and others, if I have understood correctly, with comments. * SPDX sometimes adds a license version, when we don't, or adds a .0 to license version = ignore? the difference should not matter much = maybe suggest to SPDX they drop the .0 * SPDX does not have some licenses we do (Artistic v1, CC0, Expat, Perl, GFDL without invariants) = ignore: it's OK for us to have names for more licenses = but remove Perl as a shortname in DEP5 * SPDX has BSD 3 and 4 clause licenses with placeholders = ignore: we'll just have many variants of BSD (called other-FOO or whatever) * BSD license versions = adopt SPDX naming: BSD-2-clause (from FreeBSD), BSD-3-clause, BSD-4-clause (do dashes clash with license version syntax?) * SPDX represents or later as a different license, where we have a generic syntax, but end result is same = ignore * SPDX treats each GPL exception as a separate license = ignore, and suggest to SPDX they adopt DEP5 approach * LGPL+ means in SPDX that no version was specified, but no such convention for the GPL = ignore, it's their problem, our syntax supports it anyway * SPDX calls it FDL, DEP5 calls it GFDL = ask SPDX to rename, since GFDL is the logical name, otherwise maintain a mapping table * SPDX calls it Python and Python-CNRI, DEP5 calls it PSF = rename in DEP5 * SPDX calls them EFL, W3C, Zlib = rename in DEP5 * SPDX links to http://www.opensource.org/licenses/mit-license.html = add link to DEP5 * I've fixed DEP5 to use the right versions for the Perl example (thanks, gregoa) Any comments on this? Did I miss anything, or misunderstand something? Are all above suggestions acceptable? If so, I'll make the changes and push things to svn. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292881433.4384.61.ca...@havelock.lan
DEP5: License section
The remaining parts of DEP5 are all related to licenses. I propose the following: * Add a mention of and link to SPDX to the License specifications chapter. ## SPDX [SPDX](http://spdx.org/) is an attempt to standardize a format for communicating the components, licenses and copyrights associated with a software package. It and the machine-readable debian/control format attempt to be somewhat compatible. However, the two formats have different aims, and so the formats are different. * I don't think we need to do much extra work for SPDX compatibility at this time. I'd like to get DEP5 pushed out, and not wait for conversion tools or verification that such tools can be written. We can fix things later, if need be. * The list of license short names looks fine to me. I have not compared the DEP5 list with SPDX or Fedora, or other projects, though. If someone notices incompatibilities, we should fix that. * I'm not sure we need to worry about adding licenses to the list right now. We will need to add them later, as they are needed by people actually using DEP5 for their packages. Opinions? * The wiki suggests that the meaning of public domain as a license may need clarification. I am not sure what that means. Does anyone else have anything to say about this part of DEP5? Once there's rough consensus of this part of DEP5, I'll push out the changes we've made over the past months to the DEP svn repository, and after that we should start moving it info the debian-policy package, assuming [1] still applies. (After that, any further changes to the debian/control format should happen via debian-policy package maintainers.) [1] http://lists.debian.org/debian-project/2010/08/msg00269.html -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1292442846.2611.52.ca...@havelock.lan
Re: [DEP5] Asking for common wisdom on new field(s): References*
On ke, 2010-11-24 at 13:39 -0500, Yaroslav Halchenko wrote: Dear DEP5 Committee ;) In the light of previous discussions [1] and the presentation of our little effort at debconf10 [2, 3 for PDF], and now following your recommendation I am RFCing for References* fields to be used in DEP5-formatted copyright files. I foresee use of following fields: I am afraid I am not convinced by this proposal. In addition to the upstream-metadata.yaml suggested later in the thread, I'd like to raise the following points: * I don't think bibliographic references to upstream (or papers describing them) belong in debian/copyright, unless the upstream copyright requires them to be there. * Inventing new fields for entirely new things this late in the DEP5 process is a bit unfortunate. I would like to see DEP5 pushed out of the door and finalized soon. It would seem to me be better to do that, and then discuss the references stuff separately, later. Sorry to be so negative on your proposal. A generic upstream-meatdata.yaml sounds to me like the best solution for sorts of things. Some day in the future I would like too see as much non-copyright information as possible moved out from debian/copyright to upstream-metadata.yaml, but that, too, will be a separate discussion. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290682079.3234.126.ca...@havelock.lan
Re: DEP5: Extra fields without ‘X-’ prefix?
On ma, 2010-11-22 at 10:53 +, Philip Hands wrote: Not that I think there's anything wrong with what you already have, so go with whatever you prefer. I'm lazy so I'll with the current wording, in the hope that my assumption of the high level of common sense turns out to be correct. :) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290531403.3234.105.ca...@havelock.lan
Re: DEP5: copyright statement form, etc
On la, 2010-11-13 at 20:12 +, Lars Wirzenius wrote: * Should we suggest people keep the upstream copyright statements verbatim, including the word Copyright or c-in-a-circle or whatever? Or should we suggest that they can also shorten them to, say, 2010, J. Random Hacker? I'm fine with either. Currently the examples use the shortened form, so there's an implicit suggestion, but should be explicit about it? Or change the examples? Opinions? After the discussion, I am applying the attached patch for this. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-11-14 11:19:15 + +++ dep5.mdwn 2010-11-20 09:13:46 + @@ -222,6 +222,11 @@ Copyright 2008 John Smith Copyright 2009, 2010 Angela Watts + +The Copyright field may contain the original copyright statement +copied exactly (including the word Copyright), or it can +shorten the text, as long as it does not sacrifice information. +Examples in this specification use both forms. * **`License`** * Licensing terms for the files listed in **`Files`** field for this paragraph @@ -543,7 +548,7 @@ Upstream-Name: X Solitaire Source: ftp://ftp.example.com/pub/games -Copyright: 1998, John Doe j...@example.com +Copyright: Copyright 1998 John Doe j...@example.com License: GPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public @@ -567,7 +572,7 @@ `/usr/share/common-licenses/GPL-2'. Files: debian/* -Copyright: 1998, Jane Smith jsm...@example.net +Copyright: Copyright 1998 Jane Smith jsm...@example.net License: [LICENSE TEXT]
Re: DEP5: Extra fields without ‘X-’ prefix?
On su, 2010-11-14 at 11:13 +, Lars Wirzenius wrote: Extra fields can be added to any paragraph. No prefixing is necessary. Future versions of the `debian/copyright` specification will attempt to avoid conflicting specifications for widely used extra fields. Is that enough? This is a minor detail, I'd like to not start specifying too much about how parsers are supposed to handle the fields, etc. I ended up with this formulation, I hope that's acceptable to everyone: -Extra fields can be added to any paragraph. Their name starts by **`X-`**. +Extra fields can be added to any paragraph. +No prefixing is necessary or desired, but please avoid names similar +to standard ones so that mistakes are easier to catch. +Future versions of the `debian/copyright` +specification will attempt to avoid conflicting specifications +for widely used extra fields. After this, we should have the license shortname, description, SPDX compatibility, etc, discussion remaining before the DEP5 spec should hopefully be finished. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290244968.3234.44.ca...@havelock.lan
Re: DEP5: Extra fields without ‘X-’ prefix?
On su, 2010-11-14 at 11:37 +0900, Charles Plessy wrote: Le Sat, Nov 13, 2010 at 08:12:15PM +, Lars Wirzenius a écrit : The editorial changes, plus these two items, are the final things left for DEP5, except for the review for licenses, shortnames and SPDX compatibility. Hi Lars, I would like to discuss about the addition of ‘X-’ in front of extra fields. I proposed earlier to recommend against, Steve answered that he prefered to simply remove the requirement. I'm fine with pretty much anything with regards to the extra fields. How about we change the wording from this: Extra fields can be added to any paragraph. Their name starts by **`X-`**. To this: Extra fields can be added to any paragraph. No prefixing is necessary. Future versions of the `debian/copyright` specification will attempt to avoid conflicting specifications for widely used extra fields. Is that enough? This is a minor detail, I'd like to not start specifying too much about how parsers are supposed to handle the fields, etc. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289733212.6260.38.ca...@havelock.lan
Re: DEP5: copyright statement form, etc
On su, 2010-11-14 at 12:59 +0900, Charles Plessy wrote: Dear Lars and everybody, here are two answers and a proposition for editorial changes. * Should we suggest people keep the upstream copyright statements verbatim, including the word Copyright or c-in-a-circle or whatever? Given that the upstream authors are somtimes themselves inconsistent, this would probably give extra work and possilibities of failure to the Debian package maintainer. I think that the current draft is good as it is. We should, of course, allow people to copy copyright statement verbatim into debian/control. However, since that can result in a fair bit of redundancy, with all the repeated Copyright words, some might prefer to simplify things and use something like the format the current examples in DEP5 do. Personally, I don't think we should suggest either verbatim or mangling. However, it would be good if all the examples didn't use the mangled format. Thus, we could change some examples to be unmangled. Any other opinions? Field types === @@ -85,12 +85,13 @@ for details. There are four kinds values for fields. Each field specifies which -kind is allowed. +kind is allowed. The field type is indicated in parenthesis, according +to Policy's §5.1. -* Single-line values. -* White space separated lists. -* Line based lists. -* Text formatted like package long descriptions. +* Single-line values (simple). +* White space separated lists (folded). +* Line based lists (multiline). +* Formatted text like package long descriptions (multiline). A single-line value means that the whole value of a field must fit on a single line. For example, the `Format` field has a single line value In the above patch, I also changed ‘Text formatted’ by ‘Formatted text’, which is more consistent with the text that follows in the DEP. Once policy has actually been amended, I'd be happy to apply this patch. Until then, I think it's best not to do it, since the policy amendment might still change. Redundancy with Policy == The Policy already disallows to use a field more than once in a paragraph. Perhaps that can then be removed from the DEP? @@ -114,8 +115,6 @@ For example, `Disclaimer` has no special first line, whereas `License` does. -Each field may occur at most once in a paragraph. - # Implementation ## Paragraps ### Header paragraph (Once) This'll require people to be intimate with the policy spec for this, but it's not that big a deal. Applied. RFC (2)822 == The most up to date version is 5322: @@ -139,7 +138,7 @@ * Syntax: line based list * The preferred address(es) to reach the upstream project. May be free-form text, but by convention - will usually be written as a list of RFC2822 addresses or URIs. + will usually be written as a list of RFC5322 addresses or URIs. * **`Source`** * Required Applied, thanks. -### Examples in pseudo-RFC-822 format +### Examples Simple A possible `copyright` file for the program 'X Solitaire' distributed in the Debian source package `xsol`: Applied, thanks. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289733827.6260.47.ca...@havelock.lan
Re: DEP-5: clarify batching of copyrights, licenses in a single stanza
On to, 2010-10-28 at 17:52 -0700, Russ Allbery wrote: Craig Small csm...@debian.org writes: This is the collecting part I hope is cleared up. Do something like grep -i copyright `find . -name '*.[ch]'` over a non trivial project, especially one that has been around for years and you get all sorts of wonderful combinations. The globbing Charles suggested adds Angela to 2008 and John to 2009, maybe. I'm not sure if that's a problem. I doubt there's any way that we could know without asking a lawyer, but my feeling is that long before we got into trouble for aggregating copyright statements, we would have many, many other problems with our current practices. I gather there's a rough consensus on accepting my diff, with the fixes suggested by Charles, so I merged that. If it turns out that the combination of various copyright statements into summaries (see [1]) is a bad idea, legally speaking, then we can just not do that. It should not affect the DEP-5 format, I think, so I don't want to postpone this change until legal minds have figured it out. [1] http://lists.debian.org/debian-project/2010/10/msg00101.html On to the next topics... -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289676794.6260.14.ca...@havelock.lan
DEP5: editorial changes
I would like to propose the attached patch, which makes some editorial changes to the DEP5 draft. It was bugging me that the document structure was so deep (four levels of sections in some places), and details of Files were in two places, and so on. So I re-arranged things a bit more to my liking, and the attached patch is the result. There should be no change to meaning, unless I screwed up, in which case please point it out. Otherwise I'll push this in a few days. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-10-28 11:35:36 + +++ dep5.mdwn 2010-11-13 19:54:04 + @@ -83,6 +83,7 @@ See http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax for details. +Extra fields can be added to any paragraph. Their name starts by **`X-`**. There are four kinds values for fields. Each field specifies which kind is allowed. @@ -116,18 +117,21 @@ Each field may occur at most once in a paragraph. -# Implementation -## Paragraps -### Header paragraph (Once) +# Paragraps + +There are three kinds of paragraphs: the first one is called +the header paragraph. Every other paragraph is either a Files +paragraph or a stand-alone license paragraph. +This is similar to source and binary package paragraphs +in `debian/control` files. + +## Header paragraph (Once) * **`Format`** * Required * Syntax: single line * URI of the format specification, such as: * http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=REVISION - * Note that the unwieldy length of the URL should be solved in - future by hosting the specification at a shorter URL (including the - specification version). * **`Upstream-Name`** * Optional @@ -167,14 +171,14 @@ from a version known to be DFSG-free, even though the current upstream version is not. - * **`Copyright`** -* Optional. -* Syntax: line based list -* In the header paragraph (no `Files` specification), this field - gives the copyright information for the package as a whole, which - may be different or simplified from a combination of all the - per-file copyright information. See also `Copyright` below in - the `Files paragraph` section. + * **`Copyright`** + * Optional. + * Syntax: line based list + * In the header paragraph (no `Files` specification), this field + gives the copyright information for the package as a whole, which + may be different or simplified from a combination of all the + per-file copyright information. See also `Copyright` below in + the `Files paragraph` section. Example: @@ -183,7 +187,7 @@ Upstream-Contact: John Doe john@example.com Source: http://www.example.com/software/project -### Files paragraph (Repeatable) +## Files paragraph (Repeatable) The declaration of copyright and license for files is done in one or more paragraphs. In the simplest case, a single paragraph can be used which @@ -193,7 +197,7 @@ * Required (not in header paragraph). * Syntax: white space separated list * List of patterns indicating files covered by the license - and copyright specified in this paragraph. See File patterns below. + and copyright specified in this paragraph. See below for details. * **`Copyright`** * Required @@ -247,59 +251,6 @@ * **`Comment`** * Same as in the header paragraph. - -Example: - -Files: * -Copyright: 2008, John Doe john@example.com - 2007, Jane Smith jane.sm...@example.com -License: PSF-2 - [LICENSE TEXT] - -### Standalone License Paragraph -Where a set of files are dual (tri, etc) licensed, or when the same license -occurs multiple times, you can use a single line **`License`** field and -standalone **`License`** paragraphs to expand the license short names. - -Example 1 (tri-licensed files). - -Files: src/js/editline/* -Copyright: 1993, John Doe - 1993, Joe Average -License: MPL-1.1 or GPL-2 or LGPL-2.1 - -License: MPL-1.1 - [LICENSE TEXT] - -License: GPL-2 - [LICENSE TEXT] - -License: LGPL-2.1 - [LICENSE TEXT] - - -Example 2 (recurrent license). - -Files: src/js/editline/* -Copyright: 1993, John Doe - 1993, Joe Average -License: MPL-1.1 - -Files: src/js/fdlibm/* -Copyright: 1993, J-Random Corporation -License: MPL-1.1 - -License: MPL-1.1 - [LICENSE TEXT] - -### Extra fields. - -Extra fields can be added to any paragraph. Their name starts by **`X-`**. - -## Fields Detail - -### Files - Filename patterns in the `Files` field are specified using a simplified shell glob syntax. Patterns are separated by white space. @@ -351,8 +302,46 @@ differently. Finally, there are some manual pages added to the package, written by a third person. -### License - Short name +## Standalone License Paragraph (Optional, Repeatable) + +Where a set of files are dual (tri, etc) licensed, or when the same license
DEP5: copyright statement form, etc
A couple more points about DEP5: * Should we suggest people keep the upstream copyright statements verbatim, including the word Copyright or c-in-a-circle or whatever? Or should we suggest that they can also shorten them to, say, 2010, J. Random Hacker? I'm fine with either. Currently the examples use the shortened form, so there's an implicit suggestion, but should be explicit about it? Or change the examples? Opinions? * At the moment the License field's description says the first line can only be a single short name, but the intention is clearly that it can be an arbitrary license shortname expression, with examples given later in the document. Would everyone be OK if I change it to say First line: an abbreviated name for the license, or expression giving alternatives (see *Short names* section for a list of standard abbreviations). instead? The editorial changes, plus these two items, are the final things left for DEP5, except for the review for licenses, shortnames and SPDX compatibility. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289679135.6260.29.ca...@havelock.lan
Re: Please draft a policy for planet.debian.org
(Dropped planet@ and leader@, who are probably not intrested in this anymore.) On to, 2010-11-11 at 20:06 -0500, Kevin Mark wrote: On Thu, Nov 11, 2010 at 05:03:38PM +0100, Gerfried Fuchs wrote: * Tshepang Lekhonkhobe tshep...@gmail.com [2010-11-11 16:14:37 CET]: snippage What one does on their own blog is their own thing, what one pushes explicitly to planet.debian is a different area. Just my thoughts, Rhonda snippage So, at the moment, there are blogs with some content relating to donations that are on planet. Lars says that these posts might lead to a change in the focus wrt which packages are developed or motivation in the project. I may not have been as clear as I intended, so allow me a small clarification: I was specifically objecting to involving the Debian project in anything that has to do with money being collected and given to individuals. This was triggered by the suggestion that we put Flattr buttons on packages.debian.org pages. I'm fine with people going out and finding people who pay them to do Debian stuff. I've done paid Debian work myself. But don't get Debian itself involved in that, or much vigorous discussion will happen. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289560393.3572.11.ca...@havelock.lan
Re: Please draft a policy for planet.debian.org
On to, 2010-11-11 at 14:01 +0200, Tshepang Lekhonkhobe wrote: -1 for flattr; it's a great way to contribute a few cents; and these people are great contributors to Debian anyways, so why don't they get rewarded? while on that topic, maybe each package on package.qa.d.o should have a flattr button ;-) I see the smiley, but I object anyway: please let's not start promoting non-free services on debian.org. There's a bigger problem lurking in the background, though. We could replace Flattr with a (hypothetical) free service, but we would still have money involved. Money is a powerful motivator. It is not the only thing that motivates people, but it is powerful enough that it can easily warp decision making. If micropayments take off, and the amounts of money grow to become significant, then it's likely that people will work to increase the amount of money they get. If they have to choose between the technically correct option and the money-making one, there is a conflict. Right now that conflict is missing, and the quality of Debian is high because of it. Also, micropayments like Flattr are most likely to go to popular, high-visibility things. Debian mostly consists of the long tail: most packages have fairly few users, but Debian as a whole is stronger for having such a wide variety of packages. If people have to choose between money and working on an unpopular package, there is again a conflict. There's more source conflict: if there's a micropayment button on packages.debian.org, how will the money be divided between members of a packaging team? People who do NMUs? Should people who report particularly useful bugs be rewarded, too? What about people who maintain the Debian infrastructure? There may be a way to collect money via Debian and not have conflicts. But on the whole I would prefer for us to not experiment and avoid this entirely. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289478460.2957.119.ca...@havelock.lan
Re: d-d-a (and/or d-announce) on planet.debian.org
On la, 2010-11-06 at 11:44 +0100, Mehdi Dogguy wrote: I find this comment quite inappropriate. Do you think that news about Debian are burden on one of the most important news media Debian has? I, for one, find it unproductive to duplicate debian-devel-announce on Planet Debian, if it is done automatically. Having Debian Project News or someone else summarize it is fine. D-d-a is low in volume, but so are a lot of other things. That doesn't mean the total volume isn't a problem. Or the fact that filtering is unnecessarily hard. If people want an RSS feed that also includes d-d-a then I suggest setting it up as a separate thing is preferable to having it on Planet Debian. Indeed, that might be a good idea in general. Planet Debian should be for people, IMHO, and having a separate aggregator for announcements, news, etc, would be good. The GNOME project is doing that now. Or it could be the same aggregator, providing two feeds. Joey Hess already pointed this out, but I'll repeat: ikiwiki can do that, pretty easily. Does anyone else think splitting Planet Debian into a people who work on Debian feed and a bits from the project feed is a good idea? [1] http://www.feedrinse.com/ [2] http://liferea.sourceforge.net/scripting.htm One seems to be a non-free service, the other says the scripting support is going away. Other tools could, of course, be found or written for this. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289042238.2957.18.ca...@havelock.lan
Re: d-d-a (and/or d-announce) on planet.debian.org
On la, 2010-11-06 at 13:48 +0100, Holger Levsen wrote: _I_ read d-d-a anyway, and I can filter (so dont mind double posts). Having a combined planet would be good for those who are less into Debian, but still enough to be curious. And in todays time, many of them would probably not subscribe to a mailinglist _as a starting point_. I have friends who's only direct source of Debian information is through reading planet.d.o. Thats the only interesting web20-like source we have. None of that requires mixing people's personal stuff with project news and announcements. Also, with ikiwiki we could easily have a third feed, which combines the two. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289048016.2957.21.ca...@havelock.lan
Re: DEP-5: clarify batching of copyrights, licenses in a single stanza
This is continuing the discussion from 2.5 months ago. On la, 2010-08-14 at 10:04 -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: On Fri, Aug 13, 2010 at 04:13:57PM +1000, Craig Small wrote: We should say explicitly that the copyright field is a rollup of all relevant copyright declarations for that group of files, yes. Russ, can you suggest some language around this? rollup just conjures images of children's fruit snacks for me. :) How about this (written without looking at the detailed wording of the document, so may need some massaging to fit into the flow): I think it fits fine with the flow, and would like to propose the attached patch. The patch also adds a Copyright field in the header paragraph, which would give the copyright status for the work as a whole. Assuming I understand what I'm writing, please fact-check. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-09-23 12:40:46 + +++ dep5.mdwn 2010-10-28 10:14:33 + @@ -167,6 +167,15 @@ from a version known to be DFSG-free, even though the current upstream version is not. + * **`Copyright`** +* Optional. +* Syntax: formatted text, no synopsis +* In the header paragraph (no `Files` specification), this field + gives the copyright information for the package as a whole, which + may be different or simplified from a combination of all the + per-file copyright information. See also `Copyright` below in + the `Files paragraph` section. + Example: Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=135 @@ -194,6 +203,24 @@ If a work has no copyright holder (i.e., it is in the public domain), that information should be recorded here. + The Copyright field collects all relevant copyright notices for the + files of this stanza. Not all copyright notices may apply to every + individual file, and years of publication for one copyright holder may + be gathered together. For example, if file A has: + + Copyright 2008 John Smith + Copyright 2009 Angela Watts + + and file B has: + + Copyright 2010 Angela Watts + + the Copyright field for a stanza covering both file A and file B need + contain only: + + Copyright 2008 John Smith + Copyright 2009, 2010 Angela Watts + * **`License`** * Licensing terms for the files listed in **`Files`** field for this paragraph * Required
Re: DEP-5: clarify batching of copyrights, licenses in a single stanza
On to, 2010-10-28 at 19:58 +0900, Charles Plessy wrote: It may be confusing that the header paragraph Copyright field has not the same format as the files paragraph Copyright fields (‘line based list’). Perpaps people writing parsers may comment on this as well… That was a bug. Fixed. Since we already replaced all previous occurences of “stanza” by “paragraph”, I suggest to replace this one as well. Fixed. Would ‘Copyright 2008, 2009, 2010 John Smith, Angela Watts’ be also acceptable ? Especially if the situation is: Copyright 2008 John Smith Copyright 2009, 2010 Angela Watts Copyright 2010 John Smith, Angela Watts I don't know what the proper answer to this is, but it is probably not something that the DEP5 file format needs to address anyway. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1288265723..17.ca...@havelock
Re: where can I get etch debian package?
On ti, 2010-10-26 at 15:53 +0800, Naufal Alee wrote: I'm using SBC with ARM and using Debian Etch. Usually, I download any package at Debian website but now I can't see the etch package anymore. Can I get it? or Where can I get it? The etch release of Debian is no longer supported. Because of this, it has been moved to the archive server (archive.debian.org). Etch gets no updates, and no security support, so it would be best to not use it anymore if you can avoid it. However, if you need to continue using it, then archive.debian.org is your place to go. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1288081011.7859.11.ca...@havelock
Re: QTS ( was Re: user support - Shapado instance for Debian)
I am going to be quite blunt. Please be forewarned. On pe, 2010-10-08 at 13:39 +0200, Jesús M. Navarro wrote: Does it? With regards to any assymetric relationship, benefit is in finding common grounds. What I mean is, think of an extreme scenario, one where only newbies asking for help visit, say, a web forum with no expert over there. This extreme case would be worse than no help at all, since it would be bound to rise both cargo cult (I saw once a so called expert and he did something like this, though I don't know why, I know it worked) and bad practices (think of ten year old children explaining one another how babies are made). It is, indeed, entirely possible that an experiment in making the Debian community function better is not going to be successful. I don't know if the ask.debian.net site will be successful or not. It might fail, it might not. If it doesn't fail outright, it might still not be a good addition to the Debian ecosystem. Nobody knows that either. Yet. It is, however, a really bad idea to suggest experimentation should not be attempted because it might fail. The failure mode here is not catastrophic; there is no need to be excessively cautious. Painting doomsday images is uncalled for. This is stop energy, pure and simple. http://www.userland.com/whatIsStopEnergy This behavior pattern is one of the reasons why Debian moves less slowly than it could. We need to have room to experiment, and it needs to be OK to fail. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1286542005.2755.147.ca...@havelock
Re: QTS ( was Re: user support - Shapado instance for Debian)
On pe, 2010-10-08 at 00:19 +0530, Ritesh Raj Sarraf wrote: Exctly my point. What all places can we expect people to track ? debian-announce for users, and debian-devel-announce for developers. Everything else is up to you. ask.debian.net is not taking anything away from you. You can ignore it the way you ignore Debian web forums, for example. ask.debian.net is not there to replace mailing lists, it is there to add to them, for those who want to use it. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1286482982.2755.107.ca...@havelock
Re: DEP5: Making Files: * non-optional
On ma, 2010-09-13 at 14:53 +0100, Lars Wirzenius wrote: The current DEP5 draft says: * **`Files`** * Required for all but the first paragraph. If omitted from the first paragraph, this is equivalent to a value of '*'. * Syntax: white space separated list * List of patterns indicating files covered by the license and copyright specified in this paragraph. See File patterns below. Unless there are objections, I am going to apply the attached patch to the DEP5 spec. It's a tiny bit different from what I originally proposed, but should achieve the mission of getting rid of the optionality of Files: *. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-09-13 13:45:36 + +++ dep5.mdwn 2010-09-22 15:48:43 + @@ -179,9 +179,7 @@ applies to all files and lists all applicable copyrights and licenses. * **`Files`** - * Required for all but the first paragraph. - If omitted from the first paragraph, - this is equivalent to a value of '*'. + * Required (not in header paragraph). * Syntax: white space separated list * List of patterns indicating files covered by the license and copyright specified in this paragraph. See File patterns below.
