Re: Questionable Package Present in Debian - fortune-mod
On Mon, Aug 21, 2023 at 04:51:39PM -0500, G. Branden Robinson wrote: > I keep trying to make the point that if people would just quote the > specific darned fortunes that they have a problem with, we could focus > this discussion immensely. > But no one has, as yet, in either of these threads as far as I can > recall, identified more than one objectionable fortune. I pointed out in November that there were entire groups of fortunes within the source package categorized (by filename) as racist, homophobic, and misogynistic. You appeared to agree[1] that fortunes deserving of such a label were not appropriate to present to users. You expressed an interest in adopting the package to restore the fortunes-off binary package, in cleaned up form. Exactly nine months have passed, and nothing has changed. The package is unmaintained. No one has stepped forward to provide editorial oversight of the fortunes files. Instead, we're back here again arguing about whether it's *acceptable* for Debian to drop contents from the archive that no one wants to maintain, and you're trying to push the burden of proof on those who stand for the principle that we shouldn't ship content that promotes bigotry and discrimination against people of marginalized identities. Some of us have moved on from Debian as a debate club. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] https://lists.debian.org/debian-project/2022/11/msg00056.html signature.asc Description: PGP signature
Re: Questionable Package Present in Debian: fortune-mod
On Mon, Aug 21, 2023 at 05:32:22PM +, Jeremy Stanley wrote: > On 2023-08-21 20:16:22 +0300 (+0300), Dmitry Baryshkov wrote: > [...] > > According to Debian's CoC we use non-offensive ways to communicate > > within the project, so that everybody is welcome to speak and > > contribute. But we should not censor software. If there is a > > misogynistic comment in GNU HURD sources, should we censor it out? > For that matter, if Debian was going to get into book burning over > racist, homophobic and misogynistic writing, all those packaged > versions of religious texts would presumably be the first things > tossed onto the pyre. Don't you think it's a bit hyperbolic to equate "not distributing a text in our archive" to "book burning"? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Questionable Package Present in Debian: fortune-mod
On Fri, Aug 18, 2023 at 05:27:55PM -0400, Roberto C. Sánchez wrote: > Also, if quoting Mein Kampf or anything else from Hitler is problematic, > then perhaps fortune-anarchism (source package blag-fortune) should also > be considered for removal. It includes quotes from numerous individuals > who have themselves engaged in terrorism or other violence toward > individuals and groups, supported those who have engaged in such > activities, or been otherwise complicit in such. Lol bothsidesing anarchism and fascism -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Libc6 Usage Question
Hi Alexis, Note that the debian-project mailing list is for internal discussions of the debian-project; debian-user is probably a better mailing list for questions such as this. On Tue, Apr 25, 2023 at 06:29:11PM -0400, Alexis E wrote: > Dear Debian Mailing List, > I am working on a project which requires libc6. When I build this > project on my laptop, the project works fine as it builds for the libc6 on > my laptop, however, when I build it in Github actions, the project fails to > run, due to Debian not having a libc6 version as low as GLibC 2.32. I've > tried to compile my project to musl, statically, and even just embedding > the correct version of libc6 in the lib folder that I set my rpath to. I've > either had segfaults or failed builds. I would like to ask how I can either > support an older version of libc6 or upgrade any customers' systems to the > correct version. I'd also happily accept not requiring libc6 at all. The basic fact is that Linux binaries built in one environment are not guaranteed to be portable to run on other Linux distributions (or other versions of the same distribution). If github actions give you the option of building in a Debian stable environment, that would address your needs. But I wouldn't generally regard github as a production build environment. The other option is that you can wait for the next Debian stable release, which will bring glibc 2.36... > How may I achieve this? > > Thank You, > Alexis > > ```bash > ./project: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > (required by ./project) > ./project: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found > (required by ./project) > ./project: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > (required by ./project) > ./project: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > (required by lib/libSDL2-2.0.so.0) > ./project: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found > (required by lib/libSDL2-2.0.so.0) > ./project: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > (required by lib/libSDL2-2.0.so.0) > ./project: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > (required by lib/libfreetype.so.6) > ``` -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Fortunes-off - do we need this as a package for Bookworm?
On Sun, Nov 20, 2022 at 12:28:59PM -0600, G. Branden Robinson wrote: > At 2022-11-20T11:41:56+0100, Pierre-Elliott Bécue wrote: > > I'm personally fine to defend the "less neutral" position we take by > > dropping fortunes-off which is total garbage. > I'll stop here. That's 5 out of 5, none of which advocates the > oppression of any group based on ethnic or ideologic categories. So are you volunteering to adopt the package and do the work of fixing it up to remove the garbage that our users SHOULDN'T be subjected to through our archive? This isn't Sodom and Gomorrah; the package shouldn't be spared from death because you found 5 good fortunes in it. This package is a fossilized collection of fortunes that some random people on Usenet found funny or otherwise worthy of inclusion over 25 years ago. There are subcollections of fortunes in this package that are explicitly *categorized* as racist, homophobic, and misogynistic. The package IS garbage. I've looked at those files, the categorizations are not incorrect, and there is no redeeming value in shipping such things in Debian. If someone wants to sift through the contents of fortunes-off to separate the wheat from the chaff, fine, let them do it. But the presence of some good fortunes in the package doesn't compel anyone to keep it, nor does rightly pointing out the garbage that's in it incur an obligation to do the work to filter out only the stuff that conflicts with the project's Diversity Statement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: We need to define a path for Debian to climate neutrality
On Wed, Apr 13, 2022 at 11:01:04AM -0400, Sandro Tosi wrote: > > While I see no problem with the services of Debian to turn carbon > > neutral, Debian should think of ways not to end here. What else could we do? > please do not transform Debian in an activist project (i wont comment > on the carbon neutrality proposal). Debian has one goal: provide a > universal operating system. this is where it starts and this is where > it ends, and that's all the "else" that we can do. > You're free to support all your passions, missions and projects > OUTSIDE of Debian. The Debian project is not your echo chamber for > your activism. I guess our users stop being a priority when they die by the millions due to the disruption of our climate. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Tone policing by a member of the community team [Was, Re: Statement regarding Richard Stallman's readmission to the FSF board]
I broadly agree with your framing of this, Sam, with one particular point of disagreement. On Mon, Apr 12, 2021 at 01:17:30PM -0400, Sam Hartman wrote: > 2) If your statements (even outside of Debian) commit you to a path that > denies dignity, it's entirely reasonable for us to talk to you about > whether you'll be able to act in accordance with the CoC and diversity > statement. > Please convince us that you will be able to treat everyone in Debian > with dignity consistent with how we view dignity; convince us that your > actions in Debian will create a welcoming community and treat all our > members with respect. > If you can answer that question, then we should hold you to that > answer. If your answer is good, I don't think statements outside of > Debian should get in the way of your participation beyond raising the > discussion of how you will meet our community standards within Debian. > I do think if you affiliate yourself with an extreme ideology in your > statements outside Debian, it's reasonable for us to be highly skeptical > and to ask you to show us how it's going to work. > I understand some people in the project disagree with me and would like > to kick people out for their statements outside of Debian. > That's just further than I can go right now. If one has made statements outside of Debian demonstrating that they hold to an ideology that denies the dignity of other members of the project, unless those statements have been *recanted*, the existence of those statements has a chilling effect on working with others within the project *per se*. It is not enough to ask that someone *pretend* to respect other members of the project while working within the project, if their outside behavior shows that they don't actually respect those other members of the project. If a member of the Debian Project were known to have sexually assaulted someone, this would be a concern for Debian being a safe environment. It wouldn't matter that the assault happened outside the context of Debian work, or that this individual had no opportunity to assault people inside of Debian. The same applies to other, "lesser" behaviors that invalidate the innate dignity of other members of the project. A committment to keep one's mouth shut in a Debian context doesn't remove awareness of the broader context. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Debian should not engage in politics and stay neutral [was: This is not the direction that will lead to hearing each other]
On Sat, Apr 10, 2021 at 12:48:30AM +0300, Adrian Bunk wrote: > On Fri, Apr 09, 2021 at 02:11:11PM -0400, Tiago Bortoletto Vaz wrote: > > Please, let's first agree that it's not (only) about his 'personal view on > > some > > topics'. Most people defending RMS on this list seem to have suddenly > > s/actions/views/g in their spell checker. So, just to put words back to > > their > > place: it's about his incessant *actions* over the years, which may or may > > not > > been directly connected with his (publicly stated) views. And his *actions*, > > and not his views alone, have hurt the community in many many ways. And this > > community is about software freedom, the thing you said you believe on, and > > the > > thing that keeps you motivated to contribute to Debian. > >... > This community would not exist without the actions of RMS. > RMS founded the free software movement. > RMS created the GNU project. > RMS wrote emacs for the GNU project. > RMS wrote gcc for the GNU project. > RMS wrote gdb for the GNU project. > RMS wrote the GPL. > RMS founded the FSF. > Linus Torvalds originally used a non-free licence for Linux, > before switching to the GPL. > The core of Debian are the tools from the GNU project. > In the early days of Debian, RMS through the FSF employed > the DPL full-time for his work on Debian. > An open letter stating there would be "no place in the free software > community" for RMS is hugely offensive for many people who are aware > that the free software community would not exist without RMS. > RMS has always been a polarizing figure in the 38 years since he founded > the free software movement, but the same traits that make him difficult > are the reason why he stubbornly created this community against all > obstacles. Microsoft catalyzed the democratization of the Internet by contributing to the boom of low-cost commodity PCs; and without the rise of the Internet, the Free Software movement would not have taken off. Should we therefore put Bill Gates on a pedestal due to his historic contributions to the rise of Free Software, ignoring all negatives? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Tone policing by a member of the community team [Was, Re: Statement regarding Richard Stallman's readmission to the FSF board]
ws leaves one potentially subject to censure from the > > Community Team. > > > > I think the Community Team should do better. > > > > On Fri, Mar 26, 2021 at 09:21:32PM +0100, Jean-Philippe MENGUAL wrote: > > > Hi, > > > > > > Please descalate, it is an emergency. The RMS debate is very difficult for > > > many people I guess, painful or, at least, energy consumer. It often > > > results > > > to ghoughts about the compliance of some mails with the code of conduct. > > > But > > > those 2 mails are clearly not acceptable from the formal point of view. > > > You > > > cannot let yourself dominate by your badest feelings, injuring each other > > > etc. I am sure that is completely out of the code of conduct. Be > > > respectful, > > > avoiding to say words such as "shit" "fuck" "fascist", and please try > > > staying moderated. Debian will be a welcoming community if anyone can > > > express his opinons politely and others reply politely, with respect, even > > > if he disagrees. So really, descalte! If the thread is so abrasive, just > > > don't reply, ignore, I am sure it will not change your daily life in your > > > team or in the project. Or wait some hours before doing it. But again, > > > such > > > wordings are unacceptable, regardless the topic itself and the ideas. Keep > > > in mind you speak publicly and your mails stay in archives forever. > > > > > > Thanks in advance > > > > > > Regards > > > > > > > > > > > > Jean-Philippe MENGUAL > > > Debian Developer non uploading > > > Community team member > > > Accessibility team member > > > debian-l10n-french team member > > > President of Debian France non-profit organization > > > Le 26/03/2021 à 20:22, Michael Shigorin a écrit : > > > > On Fri, Mar 26, 2021 at 11:23:21AM -0700, Steve Langasek wrote: > > > > > On Fri, Mar 26, 2021 at 09:14:16PM +0300, Michael Shigorin wrote: > > > > > > On Fri, Mar 26, 2021 at 09:18:19AM -0700, Steve Langasek wrote: > > > > > > > > You absolutely have NO right to speak for all of the community > > > > > > ..so do go and apologize for the attempt in public. > > > > > > > > > > > > > And I tell you that you're humanophobic by claiming someone > > > > > > > > is "transphobic". > > > > > > > Fuck off, nobody asked you for your shitty fascist opinion. > > > > > > > > > > > It's *you* who's a fascist here. > > > > > > Go read the definition and look at what *you* do. > > > > > > > > ...e.g., http://dictionary.com/browse/fascism > > > > > > > > > > Both of my grandfathers actually fought Nazi and Japanese > > > > > > invaders. Looks like none of yours ever confronted them -- > > > > > > they would have raised you a human, not a fascist. > > > > > > > > > > > But you will learn the hard way. > > > > > > > > > > > Good luck. > > > > > > > > > > Not very good at fucking off, are you? > > > > > > > > Yep. > > > > > > > > Jonathan, I hereby demand that the Debian Project gets rid > > > > of this manipulative, insultive, divisive and libelous member. > > > > He (them? it?) can't even stand by the rules (pro|im)posed. > > > > > > > > I'm considering providing financial support to Chris Punches > > > > and asking him to not omit suing Steve Langasek by chance: > > > > http://web.archive.org/web/20210326090023/https://github.com/rms-open-letter/rms-open-letter.github.io/issues/2250 > > > > (of course the issue was deleted, mindless as it could be). > > > > > > > > > > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Cancel "culture" is a threat to Debian
On Tue, Mar 30, 2021 at 06:56:49PM +1100, Dmitry Smirnov wrote: > Cancel "culture" arrived in Debian and it threatens the project: https://davidblixtauthor.medium.com/cancel-culture-and-responsibility-b5b8065c3cbd -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: are Debian mentors nuts? the DebConf scandal
On Sun, Dec 29, 2019 at 12:24:12AM +0100, Mary-Anne Wolf wrote: > Debian deems an LGBT gender-pronoun-fail more serious than a romantic > liaison with an intern??? What evidence do you have of this? > Debian's Social Contract. Transparency my arse. Women can't see any > justice here. I don't! > Debian, please release the reports Huh? > and shift the community focus off the women and back onto the men. Huh? I would expect any claims of sexual assault or harassment in the Debian community to be fully investigated and perpetrators to be held accountable. However, without an actual complainant, claims of sexual misconduct are themselves a form of harassment. You appear to be making accusations of sexual misconduct that are nothing but hearsay and inference based on the writings of an individual who has been removed from the Debian Project and clearly has an axe to grind. Please consider whether making posts on a public mailing list about such matters, rather than reaching out to any supposed victims privately and supporting them in seeking justice, is actually effective in advancing the goal of protecting women. > The comments by RMS pale in comparison to what people are saying about > Debian, GSoC, Outreachy, groupies and casting couches at DebConf. No one appears to be saying anything of the sort /within the Debian Community/. This is not some great conspiracy of silence, there are a number of Debian Developers who take these questions seriously and would not remain silent if we were aware something like what you describe was going on. The parsimonious explanation is that the ex-DD who has now been engaged in a campaign of harassment against members of the project for over a year is materially misrepresenting the facts. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Merry Christmas more debian private leaks
On Tue, Dec 24, 2019 at 12:44:44PM +0100, Santa Claus wrote: > Download debian-private today thanks to IPFS > https://ipfs.io/ipfs/QmNgEAYhpb3djgmZWcdNM2jN3epDmfGym89U41Jt2zr9tL Nothing says "I'm taking a stand against bullying" quite like repeatedly republishing people's private correspondence from 20 years ago. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Some thoughts about Diversity and the CoC
On Fri, Dec 20, 2019 at 05:23:04PM -0800, Russ Allbery wrote: > Adam Borowski writes: > > You try to somehow equate denying a "right" to be smug over forcing > > others to lie, with a direct expulsion. One of these is just a feeling, > > the other is an actual severe action. > I'm not sure that I parsed that correctly, Adam. I hope that you didn't > just imply that asking someone to use someone else's correct pronouns is > asking them to lie, and I just misunderstood what you were trying to say. > > Accept my apologies that I'm not inclusive enough to demand expelling > > people, and that I'm not diverse enough to demand a homogenity of > > opinions. > No. > To avoid any appearance of doubt, I stand with my transgender colleagues, > I believe that it is completely unacceptable to attempt to erase their > experience, and I am completely in favor of expelling from the project > anyone who insists repeatedly on intentionally referring to them by an > incorrect gender or otherwise verbally harassing them or denying their > existence. > This principle is more important to me than the unity of the project and > is more important to me than Debian. > I do not believe diversity is about accepting anything including > intolerance. I believe in making explicit choices, and standing by those > choices. I support LGBT people and do not support anti-LGBT people. If > that's in conflict with Debian's code of conduct, so be it. Seconded. There is not room in the Debian Project for both me and transphobes, and I would rather see the Debian Project end than be a safe haven for transphobia. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: enforcement first, ask questions later?
On Sun, Feb 03, 2019 at 08:38:54AM +0100, Daniel Pocock wrote: > It is a fact that both Lamb and de Blanc have stated at various times > during 2018 that they didn't have time to talk to people. It is also a > fact that multiple people have complained that Debian leadership figures > are too busy to talk to them. Is it acceptable for them to skip over > talking to people and rush to enforcement simply because they are busy? Yes, it is. The first duty of the DPL and any delegates is to the Debian Project as a whole, not to any individual developer. If the appropriate delegates have determined that an individual developer's behavior is damaging to the project, they are absolutely justified in enforcing first. Restorative justice is a worthwhile goal, but it is a luxury. It is not the responsibility of the Debian Project to rehabilitate every contributor who it's determined has overstepped boundaries. Even ignoring the effect of bad actors, that constitutes an open-ended committment. And even if the project's representatives HAVE made a committment to rehabilitation, it is STILL acceptable to enforce FIRST if in their sole judgement this is necessary in order to limit any ongoing damage. If you don't understand this, then it is unsurprising to me if enforcement escalates. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Censorship in Debian
On Wed, Jan 09, 2019 at 07:20:41PM -0500, Miles Fidelman wrote: > On 1/9/19 5:39 PM, Josh Triplett wrote: > > Anthony Towns wrote: > > > On Fri, Jan 04, 2019 at 10:47:05AM -0800, Russ Allbery wrote: > > > > People seem to feel they're unreasonably put-upon by having to think > > > > about > > > > what they're saying *at all*, but this is absurd. Everyone else in the > > > > world is doing this all the time. > > > There are times when you don't have to think about what you're saying > > > before you say it; that situation is often called being "among friends", > > > or "in a safe space", or "able to let your guard down". > > If you have to have your "guard up" to avoid hurting people, you have a > > more fundamental problem. > > It really *isn't* that hard to just think about the effect of your words > > on others *all the time*. As Russ said, that's a fundamental skill. > > Debian is not a locker room. > On the other hand, when did people get so thin skinned, and offended by > everything? > I came across this in a FreeBSD community discussion of similar issues: > https://notablelife.com/our-generation-needs-to-stop-being-offended-by-everything-and-learn-how-to-take-a-joke/ > - a good read. > One paragraph, that nails it: "The thing is, people are often offended by > things that are so minimal compared to the actual problems in the world to > which they turn a blind eye. You don’t tend to see many people being > ‘offended’ by the fact that there are starving children in third world > countries, or making rambling Facebook posts about how access to clean water > offends their sensibilities. Yet the second a joke or an ad is slightly > offside in their eyes, they lash out like they’ve been a victim of the > greatest injustice known to humankind." That's because the vast, vast majority of people have the residual decency to not open their fat mouths and argue in public that people don't *deserve* to have access to food and clean water, whereas there is a quite high number of assholes who feel no shame at treating someone as less-than on the basis of irrelevant intrinsic characteristics. So, you know, take some personal responsibility for things you say that are offensive, and everything'll be ok. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Censorship in Debian
On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:
> On 1/7/19 10:57 AM, Ian Jackson wrote:
> > Miles Fidelman writes ("Re: Censorship in Debian"):
> > > On 1/6/19 1:38 AM, Steve Langasek wrote:
> > > > [systemd stuff]
> > > [systemd stuff]
> > I appreciate that the fights over systemd have been a defining
> > experience for many of us. Many of us are still bitter, me included.
> > I also appreciate that in some respects these fights are still,
> > unfortunately, being fought and harm is still being done (although
> > things are much less bad than they were).
> > But I really don't think it is helpful to link the recent arguments
> > over behaviour in the project, with init system diversity problems.
> > The issues are very different. And the toxic emotional and political
> > baggage from the init system stuff is really bad. So bringing init
> > system stuff into this conversation about acceptable conduct just
> > increases the hurt and argument, but does not lead to any better
> > conclusions.
> With all due respect - and recognizing your central involvement in the
> init-system-neutrality issue – I have to disagree with you here.
> IMHO, the issues are VERY similar - having to do with groupthink, diversion
> from groupthink, and really, really poor processes (and perhaps attitudes).
The process that was followed was:
- the Technical Committee was called on to make a decision about the
default init system in Debian (a technical matter).
- the TC decided.
- the Debian developers as a whole declined to overrule this decision via
GR.
I have no sympathy for people who have so little actual investment in the
Debian Project that they haven't even read the constitution to understand
that they don't have a franchise in such decisions, but then come onto the
project's mailing lists after the fact to express outrage at a technical
decision that they disagree with.
(I have a great deal of sympathy for users who were frustrated with the
actual decision, and worried about the impact of such a major change on
their future use of Debian. I just don't have any sympathy for those who
channeled that frustration into toxic posts on the mailing lists that sought
to browbeat Debian into changing course.)
I categorically reject the notion that a different process should have been
followed. Giving a formal voice to a wider range of stakeholders in Debian
(i.e.: Debian users as opposed to Debian Developers) would not have made the
discussion less acrimonious; it would not have eliminated the feelings of
upset at the conclusion. This was a decision about a default, which there
could only be one of. There were always going to be winners and losers.
The Debian Technical Committee voted unanimously to move away from sysvinit
as the default.
To suggest that a different process would have resulted in a different
outcome is to demand the Debian constitution be rewritten to let someone
else get their way.
To suggest that a different process would have made the same outcome more
palatable to those on the losing side of the decision is naive.
Maybe you personally would have felt better about the outcome, if you
personally had been consulted. But that doesn't scale, and provides no
basis for an amendment to the Debian decision-making processes.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Re: Censorship in Debian
On Fri, Jan 04, 2019 at 03:43:33PM -0500, Miles Fidelman wrote: > It sure seems that, in some sectors, disagreement is offensive, and offense > trumps substance. (One might point to our current President in that regard, > as well.) > I kind of wonder if Debian is headed that way - given the way the discussion > on systemd went, not that long ago. I don't know where you've gotten the impression that the systemd discussion implies Debian does not tolerate disagreement. *Respectful* disagreement has always been tolerated regarding Debian's choice of default init system. What should not be tolerated (and all of these have actually occurred on Debian mailing lists, which is why this is a sore subject) is: - accusations that members of the TC have sold out to a particular commercial entity - refusal to accept the decision that was made in accordance with the Debian constitution - attempts to readjudicate the decision on Debian mailing lists (as opposed to via a GR, which Debian developers do have a right to use to override a TC decision if they believe it was wrong). - using a disagreement about init systems to justify attacks on developers' character, integrity, or technical competence There is no expectation that everyone agree with every technical decision in Debian. The only expectation is that they engage constructively in spite of any disagreements. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Expulsions Policy
On Sat, Jan 05, 2019 at 06:48:31PM +1000, Russell Stuart wrote: > > On the FTP Team (of which I'm a non-delegated Assistant) it can take > > weeks to get agreement on text to send out on an issue. The email I > > sent relatively recently to d-d-a regarding the team's view on > > listing individual copyright holders in debian/copyright was > > literally months in the making. > You are comparing the workload of the FTP team which has to deal with > many issues a year to workload of imposed by an expulsion process when > has been used only a few times in Debian's history. I trust you see > the obvious problem. > Obvious problem aside, we apparently think it is necessary to insist > the Technical Committee provide similar a justification on the cases > they decide upon each year, yet you are apparently are think asking the > people who expel members to do the same thing is imposing an > unreasonable workload. Is how we deal with each other so unimportant? "We" "insist"? The constitution only defines that the TC has the power to make technical decisions, and the voting process by which those decisions happen. It does not dictate that the TC provide any particular level of detail in their justifications for these decisions, and to the extent that the TC does provide detailed justification, it is because they agree that this is the correct thing to do - *not* because anyone outside the TC "insists" on it. Now, there are some common-sense reasons why the members of the TC *would* want to do this. It's self-defense of their own future time to write decisions in a way that they are less likely to be questioned, and it makes a better precedent when the justification is given, as it allows individual developers to reason more clearly about how the decision does or doesn't apply to future related questions. And I think the DAM will ultimately opt to provide insight into their recent decisions for similar reasons. But that's not because the project per se is formally requiring it. > It probably isn't, because that effort you say is so unreasonable - the > the DAM actually do it. Did see read the their private email to the > person concerned - that would be it. This thing you are focusing on, > the written justification wasn't the change I was asking for as they > mostly do it now. I was asking for something entirely different - > transparency. Should we also require a detailed opinion from the DAM for each person who is admitted to the project, or only for those that were once admitted but who the DAM has subsequently decided to expel? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Censorship in Debian
On Sat, Jan 05, 2019 at 04:24:32PM -0500, Scott Kitterman wrote: > I also have a lot of sympathy for people who feel they have been > marginalized and it being worth working on making them feel welcome/not > marginalized, but I think it has limits (and maybe this is the core of my > concern relative to the CoC). Not everyone can be accommodated. There's > broad agreement that someone who insists on an unfettered right to be an > ass (for most any definition) isn't going to be made to feel welcome, but > there's also a limit to how far the project can reasonably go in catering > to people's concerns without it getting ridiculous. > To pick a completely different type of example of the same kind of issue: > Military pilots of aircraft with ejection seats are limited both to a minimum > and maximum height. It's not fair that if that's your dream job that you are > excluded because you are too tall or too short, but it just isn't > economically > or operationally feasible to develop, test, and maintain a wide variety of > ejection seats to accommodate the full range of the human condition. > All accommodations have practical limits. In my reading of the Diversity > Statement and CoC, I don't see that recognized and I fear how far it will be > taken in the future. I actually think the Diversity Statement does capture this, in the phrase: "as long as they interact constructively with our community". There are people from marginalized groups in our society that have been so traumatized by their experiences that they *cannot* assume good faith from white cis het men. That's not their fault; nor is it Debian's fault. But as a project whose membership includes an awful lot of white cis het men, if someone finds themselves unable to engage constructively around the work of creating a free operating system without blaming their colleagues for past traumas experienced elsewhere, I don't think they are going to find a home in Debian. (In truth, I think they are unlikely to ever make it far enough to apply for DD given the obstacles involved.) The corollary is that white cis het men who are participating in these wider systems of oppression should not be allowed to retraumatize those from marginalized groups within Debian - *including* by mocking or downplaying the significance of that trauma. It's a natural human reaction that when one white man sees another superficially similar white man experience consequences for his behavior towards people from another group while protesting his innocence, the first man worries he will also be unjustly persecuted for doing something that he didn't know was wrong. But just as with the #HimToo movement, this isn't supported by the actual data. Over two decades of Debian history and hundreds of white men, and only one has found himself expelled by the project for this class of conduct. This is hardly the opening salvo of some great purge. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Censorship in Debian
On Tue, Dec 25, 2018 at 11:44:38PM +0100, martin f krafft wrote: > Instead, DAM ruled a verdict, and influenced other people to the > point that "because DAM ruled" was given as a reason for other > measures. This was an unconstitutional abuse of DAM's powers, Regardless of anything else, this is not unconstitutional. The constitution gives the DPL the power to delegate decisions about approving and expelling developers; the DPL delegates this power to the DAM; thus any exercise of this power is constitutional. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
Hi Diane, On Thu, Nov 02, 2017 at 11:48:05AM -0700, Diane Trout wrote: > I only just subscribed and only have read some of the discussion so > this may be a bit off topic or already discussed. > But I was wondering if the project has thought about explicitly > encouraging mentoring in techniques for handling interpersonal conflict > and helping members develop interpersonal skills? > I know there's active research into managing team conflict, and I bet > there are some Debian members who have been more effective at helping > other team members that we might be able to learn from. > I know we have methods to share technical skills via policies and best > practices, but how do we identify and share useful social techniques? > For instance I think active listening is a useful technique when trying > to develop a consensus about a topic. > (e.g. http://ggia.berkeley.edu/practice/active_listening#data-tab-how ) > But I don't know how many others know about it and there would need to > be some adjustment for a distributed team like Debian. Better skills for handling interpersonal conflict can never be a bad thing. However, the Technical Committee exists as a decision-making body of last resort, when consensus is not possible (because two parties have incompatible goals, or because discussion is not converging on agreement fast enough to matter). Do you believe that Debian should not have such a decision-making body of last resort? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
On Fri, Nov 03, 2017 at 03:24:21PM -0400, Marty wrote: > I recall the user debate being shut down before it had even started, > complete with censored posts and deleted threads, because the Maintainers > Have Spoken. Because they "did the work." Your user opinion is "noise." > I recall the slogans and catch-phrases that echoed corporate propaganda > from Red Hat. Debian under new management. Disregard Debian's own > position on init systems. We'll probably just remove it later. > The debate was fierce even within Debian, and the final vote was very > close. The 1% that decide for the rest, couldn't decide. So you're saying that you're a strong proponent of upstart? It's interesting how much support upstart has gotten only in the form of eulogies. But if your actual position is that Debian should have stayed with sysvinit as the default, then you should understand *that* decision was nowhere near close. The Technical Committee was unanimous in their view that *either* of systemd or upstart was preferable to sysvinit as the default init system. Any claim to the contrary is historical revisionism. > I can't see it from your insider perspective but from where I sit the > whole thing looks corrupt to the bone. Instead of adopting corporate > slogans start with "follow the money" and at least remove voting > privileges from paid members. ... and this sort of nonsense is why I agree with Ian about the causes of TC dysfunction. The Technical Committee is a Debian-internal decision making body. People who are neither package maintainers nor voting members of the Debian Project should NOT have weight given to their views, except by invitation from the TC itself; because to have it any other way creates exactly the same failure modes of any other Internet pile-on, where people who have no standing in the first place expect the issue to be decided based on who can shout the loudest, and those who are trying to make a decision grounded in the TC's constitutional authority and duty to act in the best interest of the project can't hear themselves think. 90% of the problem of people feeling they haven't been heard by the TC comes from people who the TC /shouldn't actually be listening to/ investing their time and emotional energy commenting on the process. Removing the opportunity to comment and the expectation of being listened to would make for a much less frustrating process. This doesn't address the question of Debian Developers feeling they haven't been heard. I'm hopeful that the other subthread can make some progress on this point. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: should debian comment about the recent 'ransomware' malware.
On Tue, May 16, 2017 at 11:24:16AM +0100, Ian Jackson wrote:
> I agree with your conclusion that we shouldn't make a public statement
> trying to capitalise on this, but:
> Russ Allbery writes ("Re: should debian comment about the recent 'ransomware'
> malware."):
> > This is not a case where Microsoft did something clearly wrong, or even
> > differently than we would have done, or where free software would have
> > helped significantly.
> I can't let this slide.
> If these systems were running Debian, big organisations like the
> British government could hire people to provide security support for
> their users, even for versions which we no longer support. When the
> obsolete operating system is Windows, they can only hire Microsoft,
> who can set the price at whatever they think the market will bear.
> As it happens this particular vulnerability was indeed fixed by
> Microsoft, and that the UK NHS suffered so much is because of
> government and management failures[1]. But in general, users who for
> any reason are stuck on very old systems are in a much better position
> if those systems are free software.
On the gripping hand:
http://blog.koehntopp.info/index.php/1726-handling-wannacrypt-a-few-words-about-technical-debt/
I don't feel great about telling users that Free Software allows them to
ignore their lack of sound software lifecycle management by paying an
ever-increasing amount for security support, do you?
Now, Canonical has just announced an Extended Security Maintenance product
on top of the EOLed Ubuntu 12.04. There's obviously money to be made
providing a genuine service to customers who find themselves in this
situation. I just don't think we should celebrate that customers *do* find
themselves in this situation, since it reflects a failure up the chain.
> Also, Debian's engineering approaches mean it's easier to support
> obsolete environments, eg via chroots and/or mixed systems and/or
> selective backporting.
>
> Ian.
>
> [1] The NHS has been seriously underfunded and can't afford to hire
> enough good IT people (or indeed enough medics); and there has been a
> drive to replace IT systems with massive centralised IT disaster
> projects, which has starved existing systems of attention and
> resources.
>
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Re: Frustrated
On Mon, Feb 01, 2016 at 11:13:33AM -0800, Russ Allbery wrote: > palmal palmal <ppalma...@gmail.com> writes: > > Here is the answer:why you allowed microsoft to get inwolwe and build > > their product on your operating system? > Anyone have any idea what this is referring to? I think the original > poster has a whole bunch of misinformation (and I'm sorry that they had a > bad experience with jessie), but I have no idea what this specific point > could even mean. My guess was that this was a reference to the availability of Debian images for Microsoft Azure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Renaming the Debian Project
On Wed, Dec 30, 2015 at 02:03:40PM -0800, benjamin barber wrote: > It's unfortunate that Debian is named after Debra and Ian, because having > the project named after a white supremacist, who used his ex-wifes name as > an trophy. I agree in whole with the responses of my fellow developers Dimitri and Russ. I also believe, because the Internet never forgets, that this libelous accusation needs to be addressed directly. In the time leading up to Ian's death, he posted on his now-deleted twitter account about an altercation with police. He described being the victim of police brutality, and expressed the desire that his story be widely known - in the hopes that, where stories of police brutality (up to and including murder) of racial minorities in the United States have failed to lead to the systemic reforms that are needed, perhaps a story of a white, affluent, educated, middle-aged man being a victim of the same systems might tip the scale. In the course of expressing these views on twitter, Ian used a racial epithet. It appears to be this one word that has led to him being branded here as a "white supremacist". It is not racism to call attention to racial bias inherent in systems of unequal power. It is not white supremacy to use a taboo word for its shock value when discussing violations of civil rights that should be shocking to all, regardless of the color of the victim. One can certainly disagree with his methods, but there is no cause for accusing Ian of "white supremacy" when all the evidence suggests he desired to see civil rights abuses corrected for the good of all. His memory deserves better than this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Wiki
Hi Ethan, On Mon, May 25, 2015 at 04:24:01PM -0400, Ethan wrote: So I was trying to access the wiki and was met with a 403. Maintenance, yeah? Was just wondering when I could expect to see the wiki open for use again. You don't mention what wiki you're trying to access, but https://wiki.debian.org is up and running. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Why are in-person meetings required for the debian keyring?
On Fri, Feb 13, 2015 at 09:19:29AM +1000, Russell Stuart wrote: On Thu, 2015-02-12 at 10:57 -0800, Steve Langasek wrote: I'm surprised no one else has brought up this point yet: part of the reason for using cryptographic PKI (web of trust; SSL CAs; etc) is to eliminate man-in-the-middle attacks. Ah, but you see that is one of the beauties of proof of work. It is almost immune to MITM attacks. No, your so-called proof of work provides no protection at all against the MITM attack I outlined. You are saying a personal meeting enhances security, so lets perform a thought experiment. Lets remove the existing parts of system that are proof of work, and instead rely exclusively on the WoT. To do that we will no longer insist people sign their application email. Instead once they are accepted the Debian keyring maintainers pull the key associated with the email address off the key servers, and verify it is signed by two DD's - ie just use the WoT to authenticate the GPG key. This is a nonsensical strawman that proves nothing about whether ID checks improve the security of Debian's web of trust. Understanding why it's nonsensical is left as an exercise for the reader. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Why are in-person meetings required for the debian keyring?
On Wed, Feb 11, 2015 at 11:17:44AM -0800, Nikolaus Rath wrote: I'm a little confused about the need to meet in-person to get a signature that's acceptable for the Debian keyring. I believe that Debian packages are signed on upload to ensure that they have been prepared by a Debian Developer, because Debian Developers are assumed to be trustworthy. However, it seems to me that meeting someone in person isn't actually verifying the relevant identity here. My trust in a Debian developer is not based on him holding a particular legal name, it is in his history of contributions. In other words: just because I'm sure about someone's legal name, I wouldn't trust him to run code on my computer. But if someone has been contributing to Debian for 5 years with a specific GPG key, I'd probably trust him to prepare a package no matter if the name associated with the GPG key actually corresponds to some legal identity or not. Following that argument, I think a key should be signed and included in the Debian keyring if it (the key) has a history of high quality contributions. Meeting the keyholder in person to look at his passport doesn't seem to add anything of particular value here. Why would I care under what name he has been contributing? Am I missing something? I'm surprised no one else has brought up this point yet: part of the reason for using cryptographic PKI (web of trust; SSL CAs; etc) is to eliminate man-in-the-middle attacks. If you haven't met and exchanged keys in person, then how do you know that there isn't a man in the middle? I think recent revelations regarding the systematic compromising of the Internet by governments show that this isn't a tinfoil question. It is conceivable that an attacker would be able to intercept all PGP-signed communications from a target, replacing all signatures with signatures by their own key and thereby creating an unwitting sleeper agent. Given that you want direct exchange of fingerprints via an in-person meeting anyway, the additional verification of a state-recognized identity is only incrementally more inconvenient, and it does provide protection against additional forms of attack on the project. You may only care that the key belongs to the person who has been doing the work; others of us also care that we have some measure of protection against one of these people going rogue and causing millions of dollars of damage to our users. Debian is a high-stakes target. Checking state-issued IDs isn't a perfect guard against infiltration, but it seems to be the best we've come up with so far. People who complain about the value of ID checks never seem to offer anything *better*, they only propose eliminating them and weakening our standards. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: About the recent DD retirements
On Sat, Jan 24, 2015 at 09:59:17AM -0800, Keith Packard wrote: Tollef Fog Heen tfh...@err.no writes: This means that if you use system packages and want to have two applications that both want foo.jar installed, but different versions (since they need different APIs or different bug compatibility), we don't support that well. For C libraries, there are sonames and all, but those largely doesn't exist for other languages and fixing that would be a huge undertaking with, IMO, pretty poor prospects for success. For Java, I'm afraid I've taken to embedding the ABI version in the filename. AKA: ELF shared library semantics, reinvented 20 years behind schedule. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Alternative proposal (+call for seconds): Expire 2-R members every year
On Mon, Dec 01, 2014 at 02:37:30PM +0100, Lucas Nussbaum wrote: Rationale - First, I think that there is wide agreement that a more regular turn-over among TC members would be a good thing. And both Stefano's and this proposal aim at addressing this, by ensuring that at least 2 members of the TC are replaced every year. However, too much turn-over, with more than 2 replacements at one point of time, might have negative effects too. The TC might be temporarily weakened by having more young members; replacing more than two members at one point will cause less replacements later; it increases the difficulty of finding new members. The recent situation, with three TC members resigning, should not be treated as exceptional in the context of this resolution. If it were to happen again, I don't think that we should add one or two automatic expirations to the three resignations. This proposal differs from the original proposal by counting all resignations and removals as part of the desirable 2 per year replacement rate, so that the total number of replacements does not exceed two if only one or two younger members decide to resign. This version of the proposal could even result in an internal TC discussion: OK, the Project wants two members to be replaced. Are there members that feel like resigning now? Or should we just fallback to the default of expiring the two most senior members?. I think that such a discussion would be a healthy way for each TC member to evaluate its status. The orignal proposal could have the detrimental effect of pushing inactive/demotivated members to stay on the TC until their expiration, to avoid causing additional churn. The pathological corner case here appears to be that the longest-serving member of the TC could evade the term limit indefinitely. A scenario that assumes good faith on the part of all TC members is: - The longest-serving member of the TC spends a minimum amount of time engaging with TC issues. They vote on all resolutions, but don't spend much time cross-examining the petitioners, nor do they participate in resolution drafting. From their perspective, they are doing their duty on the TC, but other members of the TC have a faster response time to issues and therefore wind up doing the bulk of the work. - The other members of the TC all are very passionate about their work on the committee. (They've all been serving less than 3 years, so they have a lot of passion for it.) They engage with every issue, spend several hours each week on trying to make the TC serve the needs of the project as best they know how. And once or twice each year, there is a big issue that lands on the TC's desk, with social and technical issues intertwined and that require a lot of energy to pick apart. Once a year, one of these issues further devolves into a public flamewar where the ethics of the TC members themselves are called into question. And as a result, two members of the TC per year resign. - With the minimum turnover requirement met, the longest-serving member continues to serve as long as they are comfortable doing so. Did you consider this corner case in your analysis? If you think this corner case is less important than the risk of high turnover in the TC, could you elaborate why you think this? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
is not a way to decide this matter if Debian's majority doesn't believe it's appropriate to bundle those features in the first place. (N.B.: this doesn't require malice on the part of systemd upstream to be true. It may simply be a difference of philosophy between systemd upstream and the Debian project about what level of bundling is appropriate. That doesn't mean Debian should passively accept scope creep just because it's not malicious.) But whether or not the majority feels this is something that needs to be regulated, we should not be afraid of Debian following the will of the majority. Instead we should be afraid of Debian *not* doing so. Because not voting on the substance of this question, and leaving it to external forces to decide what kind of OS Debian will be in the future, ensures that the same uncertainty, anger and fear that has been distracting us for most of this year will persist for a very long time to come. There are some bad actors on the Internet who will continue to excoriate Debian for any decision they disagree with, and we should certainly not be swayed by those people. But the dissent is not just from the sexist trolls who should crawl back into their cave and let the mountain fall on their knotted heads. There are also a lot of Debian users who are afraid of what the future holds for an OS that they love very much; and they deserve to have that cloud of fear removed from over their heads, to be given closure, even if that closure brings the certainty that they will part ways with Debian rather than being reconciled to it. Here, things change -- it's worst for everyone if nobody does the work, but if someone else is doing the work, it's better for you to let them do it. That's the opposite of the prisoner's dilemma, in that both non-systemd and systemd users are better off if they cooperate by working on non-systemd support (as opposed to defecting by not working on it), but that's only true given there's compulsion in the first place. If you compare with and without the compulsion, the only circumstance that's different is that S is worse off if S and U both choose L, ie not-working on systemd support. I'm not sure that the GR proposals actually setup that sort of payoff matrix, though that's the impression that I get. If it is, I think compelled is a fair description of what's being attempted. It is a form of compulsion that is legitimate under our constitution. There are some times when letting every DD do their own thing is not the right way to build a shared operating system. This may or may not be one of those times; and I'm sure that some DDs will object to any compulsion by the project, whether it's constitutional or not. But I think you've laid out very well how, if one believes this is the OS we want to create, that such compulsion would benefit the project. Being compelled to stay within certain boundaries, and working together toward a common goal instead of treating the archive as a battleground, is not necessarily a bad thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Update to reimbursement procedure (now: max 3 months after expense)
On Mon, Oct 06, 2014 at 04:58:22PM +0200, Lucas Nussbaum wrote: On Montag, 6. Oktober 2014, Lucas Nussbaum wrote: Both 2008 and 2011 are more than a year ago, so I don't see any justification for making this change and would like to see it reverted. /me too Also, I don't think that 3 months is unreasonable. My employer applies a two-week soft deadline, and a one month hard deadline for travel reimbursements. or have it raised to 6 months. 3 month is really not that long, esp for those who are too being busy due to jobs or whatever. (While within a job one can do these request on job-time, so a shorter interval is more reasonable here.) Also we don't want to punish those we want to support :) Sure. But should we punish our Trusted Organizations with reimbursement requests that take several months? In what way is this punishing the TO? The TOs as organizations have a duty to disburse Debian's funds according to Debian's direction. If a six-month-old reimbursement request is not more difficult to administer than a two-month-old reimbursement request, then there is no reason to impose such a limit. You have suggested that this is needed because old reimbursement requests involve email archaeology. I don't think this is a good solution to the problem of not having good tracking of reimbursement requests. I agree that improving the processes (using e.g. RT) would be better, but this hasn't happened yet. If you want to join the auditor@ team to make that happen, you're welcome. But I am already spending far more time than I would like on financial stuff. Assuming this is an open request for help and not directed at Sledge specifically, I volunteer to join the auditor team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Prospective Trusted Organization - Debian.ch
Hello, On Sun, Oct 05, 2014 at 03:52:52PM +0200, Lucas Nussbaum wrote: == The organization should provide accountability on assets held in trust == The yearly financial statements are made public after each AGM. Debian Auditors can ask for detailed account statements on request and we're discussing ways of better integration with them. Where are these financial statements published? (There's an awful lot of public which is nevertheless difficult to find.) Do these financial statements get forwarded automatically to the auditors, or are they published in a well-known location? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: On a policy for non-debian foss content in a mini debconf
Hi Praveen, On Sat, Sep 06, 2014 at 04:31:52PM +0530, Pirate Praveen wrote: There was recent discussions on debian-dug-in list [1][2] on the content of a mini debconf being planned in India during October 17 and 18. The event is being organized in an engineering college with a good track record of free software contributions [3]. I proposed a mini debconf in the hope of getting more contributions to debian. Since we did not get many debian contributors to attend the event and encouraging the student who already contributed to give talks on their Free Software contributions. But many in the community felt mini debconfs and debconfs have been primarily about debian and having other talks would confuse attendees. Some suggested 1/3 of the talks could be about debian as debconfs have a debian day where local community can join. I would like us to define the requirements of calling an event mini debconf as a policy so we don't have to have this debate every time we organize a mini debconf. My suggestion would be to leave that to the local organizers based on the strength of local communities to decide how much debian content would qualify for calling it a debconf. I'm also thinking about creating a new brand like debian utsav which would mean a joint event of debian and local debian community to share each others experiences. I'm surprised that such a question can even arise. It seems obvious to me that an event should only be called a DebConf if its primary topic (i.e., = 50% of content) is Debian. The name DebConf is not a trademark, so if someone wants to call something else a DebConf without it actually being focused on Debian, then we can't prevent them from doing so. But I don't understand why anyone would want to misleadingly describe something as a DebConf if it's not about Debian -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: CoC / procedural abuse
On Fri, Sep 05, 2014 at 12:38:01PM -0400, Mason Loring Bliss wrote: I received a rather dismayed email from Zenaan Harkness last night, saying that he's been blocked from posting to any Debian mailing lists as a result of his emails to debian-project regarding the recent CoC discussion. While I thought his points were entirely valid - the actual offense noted was never brought up, and frankly, the context here was important to understanding the nature and the character of the complaint - the larger point is that evidently there is quiet censorship of dissenting opinion, and presumably this censorship was itself skirting the bounds of the CoC. Debian does not ban people from the mailing lists for expressing dissenting opinions. If Zenaan told you this was the cause of his ban, then he has deliberately misled you. Of course, you may have arrived at this conclusion not because of something he said, but because of the information vacuum around the ban. This is also a trade-off in not announcing bans publicly. In addition to Don's explanation of the current policy, you can find discussion in the debian-project archive explaining how this policy was arrived at: https://lists.debian.org/debian-project/2013/10/msg00090.html -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Code of Conduct violations handling process
On Wed, Sep 03, 2014 at 09:52:44AM -0700, Manoj Srivastava wrote: People associated with the FSF or those who feel i sympathy with them feel offended, I find it somewhat disappointing that we care so little about people being offensive, given the progress we have made. This thread is not about whether we care about people being offensive (which, btw, is terribly subjective). This thread is about whether the CoC should be used to enforce people *not* being offensive. And that is a very slippery slope with no bottom in sight. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Debconf-discuss] Code of Conduct violations handling process
On Wed, Sep 03, 2014 at 12:29:36PM +0100, Ian Jackson wrote: I think more guidance for the teams involved would be helpful. The Debconf and Debian CoC statements are too difficult to amend. The DC and Debian teams should develop a process document which those responsible would use to guide their actions. That document should: * Give some examples of behaviours with in each case the appropriate response. This will greatly assist the decisionmaking team. Has the decisionmaking team indicated that they have any difficulty making decisions in the absence of such a guide? I think this recommendation is motivated by a disagreement with the outcome of the complaint you raised because they did not side with you, and not out of any genuine sympathy for their supposed plight. * Say who is responsible for dealing with complaints about bad behaviour occurring at (or associated with) Debian conferences and meetings. Complaints can be made to the organizers by contacting the registration desk or emailing antiharassm...@debian.org. All complaints made to event organizers will remain confidential and be taken seriously. The complaint will be treated appropriately and with discretion. This doesn't seem ambiguous to me? In the particular incident prompting this thread, I understand that you sent a mail to antiharassm...@debian.org; and that you subsequently followed up with a member of the antiharassment team in person, who told you that they did not consider the incident at hand a CoC violation and did not intend to take any further action against an individual who was no longer at the conference. It's possible that you were unaware that the person in question was a member of the anti-harassment team, and that you were approaching them in their capacity as a member of the DebConf team? See Anti-harassment on https://www.debian.org/intro/organization#support for reference. It's also possible that, as a matter of course, we should ensure that the antiharassment team responds timely in writing to all complaints, even if there is an out-of-band follow-up. It seems to me that a conference raises different issues to the mostly online interactions in the rest of the project. The nature of violations is likely to be different; the evidential basis is going to be different; and the required timescale for a response is much shorter. ISTM therefore that CoC complaints about behaviour at (or associated with) a Debian event such as a conference should be dealt with by the conference team (or a subteam of the conference team). This is a reasonable requirement. It would certainly need to be a subteam, not the team as a whole; if we want responses to such issues that are both timely and measured, the very last thing you want to do is pile the responsibility on top of the general heap of conference-related duties. However, I'm not sure how this proposal differs from what we already have. The folks behind the antiharassm...@debian.org address are there precisely because they've volunteered to be responsible for handling such matters at conferences (not on the lists... if there are problems on the lists, the listmasters already have the authority to take action). And two of the three members of that team were physically present at the conference and were most certainly part of the on-the-ground conference team this year. * State that decisions on the appropriate response to a violation should be made without involvement of the DPL or the press team, and should be without fear or favour (whether towards complainant or accused). It is obviously incorrect for a CoC violation to be referred to either the DPL or the press team. However, in the case at hand, the antiharassment team *did not agree* that a CoC violation had occurred; and AIUI they referred the matter to the DPL on the grounds that you were requesting a specific remedy that was entirely out of scope for the antiharassment team. Perhaps the point is that the antiharassment team should never make such referrals, but instead leave it to the complainant to determine whether they wish to pursue other remedies via Debian's political channels? That seems a reasonable principle, in keeping with the overall expectation of confidentiality. * Outline our approach to violations by guest speakers, or other parties who attend the conference (or associated events) only briefly, where it is not possible to eject the violator (nor to threaten to, in order to extract an apology and promise of better behaviour). To what end? The stated purpose of the CoC is to ensure that our conference is a safe space for all members of the Debian community. In what way would a change in approach to dealing with a violation after the fact, where the offender is no longer at the conference, further that goal? -- Steve Langasek Give me a lever long enough and a Free OS
Re: Updating the DebConf Chairs delegation
Lucas, On Mon, Aug 11, 2014 at 09:41:20PM +0200, Lucas Nussbaum wrote: Dear Developers, As you might be aware, Holger Levsen and Gunnar Wolf resigned from their role of DebConf Chairs earlier this year. I would like to sincerely thank them for their numerous years of contributions to making DebConf such a successful and major event. I'm sure many of us can think of great things DebConf brought to the Debian project and to our wider community, both on technical and social levels, and Holger and Gunnar both had a huge role in those achievements. I am very happy to announce that Martín Ferrari and Tássia Camões agreed to become DebConf chairs. As Tássia is not a Debian Developer yet, she cannot be officially delegated yet, but I expect this not to make any difference for her work as a DebConf Chair. I am not happy at all to see this. In all my feedback to you regarding DebConf chair delegations, I consistently emphasized that the structure of the current delegation is broken, and that many of the problems of the recent past were a direct result of a delegation structure that relied on consensus to get anything done. When two of the chairs resigned leaving a single delegated decision-maker for DebConf, this was an *improvement* over the status quo - not because of any failing on the part of the existing chairs, but because of a failing of the delegation structure. I pointedly asked you in our private discussions: what problem are you trying to solve by appointing additional DebConf chairs? You did not respond to this question. Instead, you have delegated new chairs, reproducing the previous broken structure. I have nothing against either Martín or Tássia - on the contrary, they are long term members of the DebConf team, and I welcome them bringing their perspectives to an active ongoing role throughout the DebConf process. But as DPL delegates, they deserve to be given the support of the project to maximize their odds of success in this role, and I strongly believe this is not what you've done here. I would hope to have a constructive discussion about DebConf governance while we are all together in a week at DebConf14. But I am dismayed by this delegation right beforehand, which I think reflects a misunderstanding of the actual problems that face the DebConf team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Possible Two Color Debian Logo White Vinyl Sticker Group Buy
On Tue, May 06, 2014 at 12:40:24PM -0700, Don Armstrong wrote: I'm considering coordinating a group buy of two color, 54mm x 70mm white vinyl stickers with the Debian Open Logo[logo], and distributing them to other group purchasers at Debconf14. Minimum quantities of 2000 (US$250) are required from the printer which I've found,[printer] which comes to $0.125 per sticker. I'm personally willing to take 500 of them, but I'd like to have enough other parties to take the additional stickers. Please either reply or indicate on the wiki page[wiki] if you are interested with the quantity that you are interested in. I'm also willing to consider larger sizes, shapes, or different printers, too. [If you are not going to be at Debconf14, but are in the US and want enough stickers to justify my time (and your money) sending them to you, I'm willing to consider that too.] What would really be nice would be if someone would make another run of the shaped swirl vinyl stickers. I think I last saw these for sale back in ~2006, and I've gone through enough hardware since then that my current laptop is bare. :( Any chance of someone making some of these, rather than just the square white ones? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Possible Two Color Debian Logo White Vinyl Sticker Group Buy
On Tue, May 06, 2014 at 02:18:40PM -0700, Don Armstrong wrote: On Tue, 06 May 2014, Steve Langasek wrote: What would really be nice would be if someone would make another run of the shaped swirl vinyl stickers. I think I last saw these for sale back in ~2006, and I've gone through enough hardware since then that my current laptop is bare. :( Any chance of someone making some of these, rather than just the square white ones? You mean these ones, right? http://debian.ch/merchandise/ I think these are going to be closer to US$5-10 per for larger ones, but I'm interested in getting a few of them myself. On Tue, May 06, 2014 at 11:20:32PM +0200, Holger Levsen wrote: On Dienstag, 6. Mai 2014, Steve Langasek wrote: What would really be nice would be if someone would make another run of the shaped swirl vinyl stickers. I think I last saw these for sale back in ~2006, and I've gone through enough hardware since then that my current laptop is bare. :( Any chance of someone making some of these, rather than just the square white ones? if you mean those foil stickers, I have quite plenty of regular Debian, Debian women and Debian bsd ones, in three different sizes... I guess I'll bring or ship them to the DebConf14... Ah, those are the ones! Didn't know they were still around - I'll definitely by some if they show up at DebConf :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Sponsoring a Tails hackfest?
Hi Lucas, On Sat, May 03, 2014 at 08:43:07AM +0200, Lucas Nussbaum wrote: The Tails project is a Debian-based live system focusing on privacy and anonymity. For more information about Tails and their relationship with Debian, see: https://tails.boum.org/ https://wiki.debian.org/Derivatives/Census/Tails https://tails.boum.org/contribute/relationship_with_upstream/ https://tails.boum.org/contribute/how/debian/ http://www.wired.com/2014/04/tails/ Tails is organizing a two-day hackfest and a contributors summit in July. They are requesting sponsorship from Debian for the events, in order to cover travel costs for contributors. Their overall budget is between 10kEUR and 20kEUR. Given that: - they are a derivative working closely with Debian (and being a live system, having their own public identity makes sense) - they are doing a lot of their work in Debian -- the hackfest could be seen as a Debian sprint - they are addressing important issues, and clearly contribute to Debian having something to say about such issues I am planning to allocate 5000 EUR. As you say, this is a derivative, rather than a pure blend. While Tails seems to be doing great work, and I'm happy that they're trying to work closely with Debian, the fact that they *are* a derivative rather than a pure blend makes me question spending Debian money on this. Nothing says a pure blend couldn't have its own public identity, and if they were a pure blend, I would have no concern about the expenditure. But since it's a derivative rather than a pure blend, how do we know that in /this/ case, the work at the sprint is going to benefit Debian? The website has a very admirable statement about minimizing the delta with Debian, but is the size of this delta published and tracked anywhere? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Why discussions don't move from debian-private
On Wed, Apr 16, 2014 at 12:01:27PM -0700, Russ Allbery wrote: Jakub Wilk jw...@debian.org writes: Someone complained about a lengthy off-topic discussion taking place on debian-private, and suggested to move it to a public mailing list. A follow-up to this. In response to the question of why so many threads start on debian-private in the first place, I proposed the following two explanations: * debian-private does not contain irritating trolls. While this may indeed be a motivation for some, I absolutely disagree with that assessment. debian-private suffers from the problem that unlike every other mailing list our project uses, new members are autosubscribed to it when they clear the NM queue. As a result, it's perpetually beset by people who have long since stopped being active in more appropriate project discussion forums but who don't have the good sense to (or can't figure out how to) unsubscribe from -private. We should stop autosubscribing new project members to -private and leave it to them to figure out the db.debian.org subscription interface. And we should mass unsubscribe everyone currently on there and let them find their own way back. That means that some discussions can be had more easily on debian-private, or at least with less frustration and annoyance, because the audience who can talk is restricted to people who have some investment in the project. In practice I think the level of ongoing investment implied is very low. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: The Code of Conduct needs specifics
Hi Solveig, On Mon, Mar 24, 2014 at 02:31:54AM +, Solveig wrote: [short version: The Code of Conduct should be vastly rewritten. Yes, *before* voting on it] A few days ago, i saw the proposal for a Code of Conduct. First I was very glad, then I read it and was perplexed. I made some research, which confirmed my suspicion: the Code of Conduct that is actually proposed is in the best case useless. You might say it's better than nothing, but actually it's not: that's giving yourself good conscience without really improving the situation. Oh yes, we have a CoC. It helps in no way to avoid problems, but you can't tell us to improve the situation because hey, we have a CoC. Also, it was such a huge effort to make this happen, we won't put more anytime soon and we would be sad to hear it doesn't work, so shut up. I think if you do something, do it right. Lots of feminists, who work on these questions since years, collectively, and are concerned by the problem, have documented not only *why* have a CoC, but also *how* - not following their advice is silly and wrong. https://en.wikipedia.org/wiki/Not_invented_here While it's worth discussing how the code of conduct can be improved, this is a wholly unscientific appeal to authority. There may happen to be a group that has worked on CoC questions, but where's the evidence that their answer is *right*? Where is the evidence that their approach to CoCs results in materially better outcomes? My interest in seeing a CoC for Debian is not in banning a set of specifically enumerated behaviors, but to improve the overall quality of discourse on Debian mailing lists. Defining the line beyond which behavior will be censured can only ever give you a minimum threshold for behavior, it will never help raise it any higher than that. To inspire people to be their better selves requires a list of dos, not a list of do nots. The latter is something that the listmasters can already handle under their existing authority; it's the former that warrants the Debian project taking a position as a whole. In considering the question of a code of conduct, I personally take my cue from the one in Ubuntu: an affirmative statement of values the community holds itself accountable to. When I began working for Canonical and became involved in the Ubuntu community, I agreed to the Ubuntu CoC, which meant holding myself to a higher standard in my engagements not only with the Ubuntu community, but with the broader Free Software family - including Debian. As a result, I noticed a change for the better in my behavior on Debian mailing lists. The behavior that I see on Debian lists these days that I think is problematic would be unambiguously contrary to such a CoC, and this really has nothing to do with, e.g., sexist jokes. Sexist jokes are bad and should not be allowed on the Debian lists; but I also don't think that's the problem that we need to be worried about solving by ratifying a CoC. So, an Unacceptable Behavior section should be added. Personally, I would not be opposed to the addition of such a section; but I still think this is secondary to the main purpose of ratifying a CoC. I can write specific amendments, if somebody is willing to sponsor them :) If you would like to see change here, I think this is probably the best way forward. Without specific text to consider, this is likely to result in an open-ended discussion that doesn't get us to a usable amendment in time. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On Mon, Mar 03, 2014 at 07:37:53PM +, Reuben Thomas wrote: On 3 March 2014 18:13, Gunnar Wolf gw...@gwolf.org wrote: As keyring maintainers, we no longer consider 1024D keys to be trustable. We are not yet mass-removing them, because we don't want to hamper the project's work, but we definitively will start being more aggressively deprecating their use. 1024D keys should be seen as brute-force vulnerable nowadays. Please do migrate away from them into stronger keys (4096R recommended) as soon as possible. Please could you change https://wiki.debian.org/DebianMaintainer , which currently says a = 2048 bit key is required (I assume this is still correct) but does not specifically recommend 4096? I recently became a DM, and created a 2048 bit key to do so, as that satisfied the advice given on that page, and also happened to be the default length offered by GPG on my system. Only after I'd had it signed and uploaded it did I find advice that new keys should be 4096 bits. (I've already reported this issue in a couple of different places; the page is not user-editable or I'd've fixed it myself!) Done. The page is user editable, provided that you're logged in to the wiki. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 08:22:14PM +, Matthew Vernon wrote: Second, Matthew's proposal explicitly doesn't change the TC decision, so I'm not even sure what you think would be aborted here. It wouldn't have any effect on the choice of default. It dictates in a top-down manner to individual developers how to do their work and undermines the flexibility of Debian contributors in ways that I think are unnecessary and a little condescending, and requires work be done without identifying anyone who is going to do the work, which is why I voted against it. But it's not some sort of end-run around the previous decision. The previous decision does say that it is replaced completely by the text of such a position statement and I do note that the proposed GR does, very carefully, not refer to systemd as the default. It makes for a clumsier construction, which when combined with the level of legal-ish arguments being made here, makes me suspicious. Please don't read anything into the lack of mentioning systemd in my GR proposal. I in no way intend to undermine their decision that systemd is the default linux init for jessie. I thought The TC's decision on the default init system for Linux in jessie stands undisturbed. was clear enough. Given the ambiguity about whether this GR vacates the earlier TC decision, I think it would be best to simply include in your GR text a statement that The Debian project reaffirms the decision of the TC to make systemd the default init system for jessie. (Then I suppose if people don't actually want to reaffirm this, they can propose amendments to the contrary; but AFAICS it's better to be explicit here.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 01:53:06PM -0800, NoTo CTTE wrote: Four people get to decide what operating system debian is. Four. And we have to accept that for some reason. Debian developers don't have to accept it; they can pass a GR choosing a different default if they think that systemd is the wrong choice. *You*, OTOH, have to accept it because you're an anonymous troll whose words carry absolutely zero weight with the Debian community. You are this guy: http://www.penny-arcade.com/comic/2004/03/19 And that guy doesn't get a say in Debian's decisions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Prospective Trusted Organizations - (FFIS), Debian France
Hi Lucas, On Sat, Mar 01, 2014 at 05:41:08PM +0100, Lucas Nussbaum wrote: There are three organizations that never went through that process, and that either we use as if they were already TOs, or they would like to officially become a TO: FFIS, Debian.ch, and Debian France. As previously announced, we (auditors, DPL helpers, myself) have been working on a list of features that a TO is expected to provide, or could provide, in order to use it as a basis for the public discussion. I contacted Debian France and Debian.ch and asked them to describe how they met those features. I propose to not ask FFIS to answer those questions, given they have been successfully handling some Debian assets for a long time (more than 10 years?). If nobody disagrees by the end of the two-week discussion period, I will officially add FFIS to the list of TOs. While I don't think there's any question that FFIS should be one of Debian's TOs, I think having the answers to these questions is important in order to protect both parties, so that there's some record of what the expected relationship is and that things don't drift over time due to turn-over within the respective organizations. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
A recent mailing list ban
A few months ago, we had a discussion on debian-project about how mailing list bans should be handled. https://lists.debian.org/debian-project/2013/10/msg00090.html Although there was no statement from the listmasters to this effect on the public thread, they evidently considered the thread to reach a consensus, and for the past few months mailing list bans (which are infrequent) have been communicated to the project on debian-private. A few days ago, an individual was banned from all Debian mailing lists, and debian-private was informed. What was different about this particular ban is that the banned party responded to the ban, cc:ing me as the initiator of the above thread, and expressed his preference that the ban be made public. Since the main objection to publishing bans was that it would damage the banned party's reputation, and the banned party in this case prefers the ban be made public, I see no reason not to publish this information. I will in any case refrain from naming the banned individual in this mail; his name will of course be visible in the messages linked below. Here is the text used to inform the individual of the ban, shared with permission of the recipient. The listmaster who applied the ban included additional rationale when informing debian-private; I leave it to the listmasters to decide whether they want to provide this information here. I'm writing to you in my role as one of the debian listmasters. We currently have several complaints from users about your behaviour on debian-user-cata...@lists.debian.org [1][2]. This behaviour is not acceptable on our lists and will not be tolerated. You may have a look on the code of conduct [3] and the netiquette, if you plan to communicate with other opensource projects in the future. Therefore we decided to ban you from all of our lists. [name deleted] - on behalf of the debian listmasters P.S. this ban is not public unless you publish it on your own [1] https://lists.debian.org/debian-user-spanish/2013/12/msg00539.html [2] https://lists.debian.org/debian-user-catalan/2014/01/msg00012.html [3] http://www.debian.org/MailingLists/#codeofconduct I would like to publicly repeat my thanks to the listmasters for their continued service in dealing with such thorny issues. I am personally in agreement with the listmasters' decision to impose a ban, not because of the messages cited by the listmaster, but because of a different message in these threads: No, Mònica, no. Són bromes en context, tant per tema com per temps, i fetes amb mesura. Què no t'agraden? Perfecte, ningú us obliga a combregar. [trans] No, Monica, no. They're jokes in context, as much for their theme as for the timing, and made to measure. You don't like them? Fine, nobody is forcing you to go to communion. https://lists.debian.org/debian-user-catalan/2013/12/msg00055.html In other words: in a thread discussing why it was inappropriate, even on Spain's equivalent to April Fool's Day, to make posts suggesting that the upcoming MiniDebConf in Barcelona will be sex testing the speakers, this individual's response is that if you don't like it, you don't have to read it. The original message was unacceptable and worthy of censure; but people make mistakes and learn from them. What makes this ban-worthy is the lack of remorse shown for the upset caused, and the implicit promise to continue such posts as he sees fit. Debian has ratified a diversity statement which says that all contributors will be treated with respect, and that all contributors should feel safe and welcome in Debian regardless of background or identity. This ban demonstrates that the diversity statement is not empty words; it is a principle that the Debian community has made a committment to. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Please update the DSA delegation
On Thu, Dec 05, 2013 at 03:53:42PM +0100, Gerfried Fuchs wrote: * Steve Langasek vor...@debian.org [2013-12-05 03:32:19 CET]: In most cases, well-functioning teams will make non-controversial nominations, and the DPL will accept them without question. But that's *not* the same thing as the delegation being a rubber stamp. Maybe I get you wrong - and maybe you got Lucas wrong - but are you implying that Hector is a controversial nomination? No, I am not. I don't have an informed opinion on whether Hector should or shouldn't be made part of DSA; I was only responding to Joerg's characterization of the delegation process, which implied that the DPL is a figurehead who didn't need to be consulted before changes were made to delegated teams. I.e., Joerg's description is problematic not for how it handles the controversial cases, but for how it handles the non-controversial ones. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Please update the DSA delegation
On Wed, Dec 04, 2013 at 11:02:50PM +0100, Joerg Jaspert wrote: 3) I was a bit surprised to see Martin's announcement that Hector was now a member of DSA, and his request to update the DSA delegation. The usual process is that the appointement of delegates is usually discussed between the DPL and the team. Of course, for well-functioning teams that propose a new delegate who already went through a training process, that discussion is rather likely to be short. But that's not a valid reason to suppress it completely and make it sound like a public demand that the DPL does the required paperwork (I'm sure that it was not Martin's intent, but it's still worth clarifying, I think). Really. Interesting. Honestly, for functional teams the DPL is nothing but putting his stamp on team changes the team wants. It shouldn't be anything else there. It absolutely should. The constitution stipulates that authority flows from the developers, through the DPL, to the delegated teams. To say that the DPL delegation is nothing than a rubber stamp is to say that the team does not recognize the constitutionally-defined power structures. In most cases, well-functioning teams will make non-controversial nominations, and the DPL will accept them without question. But that's *not* the same thing as the delegation being a rubber stamp. If I remember correctly the DPL learned about the last ftpmaster promotion around 2 weeks after it happened.[1] If the ftp team is a delegated team, then this is a miscarriage of Debian procedure. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Code of Conduct: picking up
On Tue, Nov 26, 2013 at 10:21:38PM +0100, Wouter Verhelst wrote: Op 26-11-13 11:21, Cyril Brulebois schreef: Steve Langasek vor...@debian.org (2013-11-26): [...] Note that many of our Contributors are not native english speakers or English, I suppose? I fall in the category of not native here, but so do you ;-) I thought it was supposed to be lower case, but I could be mistaken. Anyone? Upper case. from communicating through Debian's systems. Complaints should be made (in private) to the administrators of the Debian communication forum in question. Can we avoid forum, which can be misleading? Do you have a better suggestion? I think forum is fine personally, but medium could also work. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Code of Conduct: picking up
On Wed, Nov 27, 2013 at 06:52:10AM +0900, Norbert Preining wrote: What does poor behaviour mean? That which is socially disruptive. You exchange one undefined term against another, but that doesn't change the underlying problem, which is, *what* is socially disruptive? An example: I was living long years in Siena, Italy, and some of my friends used *very* commonly very strong words for daily greetings, like che c fai porco *** etc (those speaking Italian will understand). In many regions of Italy, and in other circumstance, like my current living environment in Japan, this would be *extremly* socially disruptive, but back there it was normality. The whole point is that all these pseudo definitions of normality are just fake, fake, fake. We are cheating ourselves if we believe that even the most simple facts are globally socially acceptable. Go to Chechnya and or some remote provinces of Georgia, and you will be tought something else. Changing tags, names, words does not change the fundamental problem. You are using cultural relativism to justify behavior that is against the norms of *this* culture (the Debian one). I'm sure you will find, when this is put to a vote, that you are distinctly in the minority in holding this position. argumentum ad hominem, if that's clearer? I.e., this is to say play the ball, not the man. See above, same same. What is consider personal attack in one surrounding is just a friendly greeting between close buddies in the other? Example: In America hip hip society if I meet my buddy and greet him with Hi boy, you got a belly that big that you cannot see your b***s, in most of the cases I would be considered extremely rude, while in other surroundings this is a honorific term. The people on this mailing list are your peers in a very prominent Free Software project, not your buddy. Even if someone on this list *is* your buddy, it's not appropriate to address them that way /on this list/. This is not a difficult concept to grasp, and I think your protestations here are nothing but an excuse for ignoring the obvious social norms. I also happen to believe that this is currently not the status quo in Debian; and if it were, then that would be an even better reason why we need a code of conduct. We don't want bad behaviour; not from random mailinglist participants, not from Debian Developers, and certainly not from people in a position of power. You missed the point. It was that the code of conduct can be used against critical voices. Too easily. That's an important problem to guard against when formulating a CoC; but there is a difference between criticism and personal attacks / abuse, and there is no fundamental reason we can't draw a line in the sand against abuse without having a chilling effect on criticism. If you have concrete suggestions for improving the CoC language to *not* have the side effect of suppressing criticism, I for one would be interested in hearing them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Code of Conduct: picking up
On Fri, Nov 22, 2013 at 12:39:32AM +0100, Wouter Verhelst wrote: Op 08-11-13 23:30, Wouter Verhelst schreef: Op 05-11-13 16:25, Wouter Verhelst schreef: [...draft CoC...] To avoid spamming this list with one draft after another, I've put my current draft in a git repository which people can now find at http://anonscm.debian.org/gitweb/?p=users/wouter/coc.git;a=blob;f=coc.markdown This will be updated as the discussion moves along. Patches in git am format are welcome, as are regular comments on this list ;-) With the last mail to this thread now two weeks old, I've not received any further comments on my draft. Can I interpret that as people think it's ready, or is something else going on? For a full week of that two-week period, alioth was completely down, so this draft was inaccessible. This is normally the least of the reasons why I would argue that the full text of drafts should be posted to the mailing list for discussion, instead of referring to VCS URLs. I quote the current draft below for people to comment on. # Debian Code of Conduct ## Be respectful In a project the size of Debian, inevitably there will be people with whom you may disagree, or find it difficult to cooperate. Accept that, but even so, remain respectful. Disagreement is no excuse for poor behaviour or personal attacks, and a community in which people feel threatened is not a healthy community. ## Assume good faith Debian Contributors have many ways of reaching our common goal of a [free](http://www.debian.org/intro/free) operating system which may differ from your ways. Assume that other people are working towards this goal. Note that many of our Contributors are not native english speakers or may have different cultural backgrounds; see also our [diversity statement](http://www.debian.org/intro/diversity) ## Be collaborative Debian is a large and complex project; there is always more to learn within Debian. It's good to ask for help when you need it. Similarly, offers for help should be seen in the context of our shared goal of improving Debian. When you make something for the benefit of the project, be willing to explain to others how it works, so that they can build on your work to make it even better. ## Try to be concise Keep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. When a long explanation is necessary, consider adding a summary. Try to bring new arguments to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made. Try to stay on topic, especially in discussions that are already fairly large. ## Be open Most ways of communication used within Debian allow for public and private communication. As per paragraph three of the [social contract](http://www.debian.org/social_contract), you should preferably use public methods of communication for Debian-related messages, unless posting something sensitive. This applies to messages for help or Debian-related support, too; not only is a public support request much more likely to result in an answer to your question, it also makes sure that any inadvertent mistakes made by people answering your question will be more easily detected and corrected. ## In case of problems While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the rules in this code of conduct. When that happens, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful. Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion. Serious or persistent offenders will temporarily or permanently banned from communicating through Debian's systems. Complaints should be made (in private) to the administrators of the Debian communication forum in question. # Further reading The links in this section do not refer to documents that are part of this code of conduct, nor are they authoritative within Debian. However, they do contain useful information on how to conduct oneself on our communcation channels. - The [Debian Community Guidelines](http://people.debian.org/~enrico/dcg/) by Enrico Zini contain some advice on how to communicate effectively. - link to documentation on what to do in case of technical problems -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer
Re: Proposed MBF - mentions of the word Ubuntu
On Sun, Nov 10, 2013 at 09:53:32AM +0100, Martin Quinson wrote: I think I understand your point of view, and I really appreciate your moderation here as I like to be moderated myself when possible. I have an additional question here: is this position really the best to protect our downstreams? What will we do if Canonical get over-enthusiastic against a Debian derivative that is e.g. not Ubuntu-based? I agree that the question may be completely artificial at this point, but I think that ensuring that there is no legal threat over Debian derivative (neither now nor in the future) is a neat goal for our ecosystem. This hypothetical situation isn't a legal threat in the first place, it's an extralegal one. The case under scrutiny here is a domain name that referenced the trademark; and even that, everyone agrees, is a case for which Canonical's response was the wrong one. There's no real risk of Canonical going after Debian derivatives over something as far removed from the domain of trademark law as references to 'Ubuntu' within the distribution. This thread isn't about risk mitigation. It's about trying to punish Canonical for what was perceived as an attempt to suppress criticism on the Internet (but which was in fact nothing of the sort). If a Debian derivative started calling itself, e.g., Debuntu, then of course that becomes a trademark infringement matter that Canonical would need to address. But that's nothing to do with the contents of Debian, and it's not something that Debian could prevent. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposed MBF - mentions of the word Ubuntu
On Sat, Nov 09, 2013 at 11:25:03AM -0500, Scott Kitterman wrote: On Saturday, November 09, 2013 15:00:24 Colin Watson wrote: On Fri, Nov 08, 2013 at 05:35:36PM +, Ian Jackson wrote: (Posted to -project because I'm writing with my tongue in my cheek. Actually renaming and rewording things would be making our own life difficult to spite Canonical. Much better to stick up two fingers. But nevertheless, I would like to suggest that the DPL contact Mark Shuttleworth and tell him that this kind of shit is very damaging to our good relationship.) I was fairly unhappy too when I heard about this. I happened to notice via Twitter this morning that Mark responded to this, and nobody appears to have linked to it yet in this thread: https://plus.google.com/116812394236590806058/posts/5jdibY5iR9b It appears there's still some misunderstanding there. Under US law (where the site is hosted and the poster is based) it's protected speech. Full stop. No permission needed. IANAL, but I have studied this a bit. Nominative use doesn't require any permission under US law, but US jurisdiction is not the only one that matters for Canonical, which is not a US-based company. So as a US website, fixubuntu.com doesn't need permission, but it's less clear to me what Canonical's obligations might be on the policing side. In Debian we have tended to focus on the US rules for trademarks because they are more liberal than in other jurisdictions and because we can rely on this providing sufficient cover for Debian, our users and our downstreams even when they're based in other jurisdictions with other rules. But that doesn't necessarily mean that Canonical, in *policing* its trademark, should be following the US standards; nor does trying to follow a different standard imply either that Canonical's legal team misunderstands the law, or that Canonical is trying to suppress protected speech. As I hope Mark's post makes clear, the trademark policy on the Ubuntu marks is intended to strike that very same balance that we take for granted on the Internet between freedom of speech and protection of trademarks, it just arrives at it by a somewhat different route than it would from a strictly US-centric POV. FWIW, the site owner also claimed that the use of the Ubuntu logo on the front page of the site was protected as nominative use. It's not at all clear to me that this was the case under US law; there's no obvious need to make use of the logo mark when referring to Ubuntu instead of just the name, which is what nominative use is intended to protect. I think the use of the logo does introduce confusion, and it was reasonable to ask fixubuntu.com to discontinue use of it. So despite the ham-handed approach, I think the ultimate outcome here is a good one. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Proposed MBF - mentions of the word Ubuntu
On Sat, Nov 09, 2013 at 06:00:01PM -0500, Scott Kitterman wrote: Both the original letter and Mark Shuttleworth's comments make trademark ownership claims that overreach. It's overreach based on the recipient's governing local law, not based on the sender's. Isn't it the responsibility of each of us to know our rights under law? If a corporation is attempting to police their trademarks internationally and someone hosts a site in a jurisdiction that doesn't recognize trademark rights at all, does the corporation have an obligation to *not* try to protect their trademark by dissuading this person? Does the answer change if your local law says that not policing your mark against them could result in you losing the mark back home? Does it change when the site is hosted in a jurisdiction that recognizes some subset of trademark rights that you consider reasonable, but that nevertheless doesn't meet the standard for trademark defense in the corporation's home jurisdiction? I think it's entirely appropriate for Debian to work preemptively to protect itself from future bursts of enthusiasm from the Canonical legal department. I write the following as a Debian developer, not as an employee of Canonical. Anyone who doubts this is welcome to check the Debian archives for my posts in similar threads, because I have been consistent on this point for years. In the event that an over-enthusiastic mark holder tries to tell Debian that their nominative use of a trademark (in a package name, file name, etc.) is infringing, the appropriate course of action for Debian to take is to *reject these claims*, and continue using the mark. Not to buckle under pressure and set a bad precedent for other mark holders to follow; not to rename the software and cause confusion for our users. When we know we're on the right side of the law, we should be resolute in our defense of our rights. It shouldn't become a game where we pick and choose which names we will and won't allow into the distribution based on how friendly the trademark holder is. (Firefox, FTR, was a special case where the maintainer had a clear choice to make between losing any autonomy to change the upstream source of the package, and losing all rights to the marks due to the copyright license on the logos. Contrary to how this has been represented by the Mozilla community since then, it was never a question of a trademark license per se.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Should mailing list bans be published?
On Sat, Oct 26, 2013 at 05:27:25PM -0400, Joey Hess wrote: Bart Martens wrote: I suggest we keep things civil, with respect for the persons involved. It's really not up to Debian to harm someone's reputation, and that could reflect bad on Debian's reputation. Approaches I could support : - post the bans with reasons on debian-private - or maintain a list of bans with reasons in a text file on a Debian machine where DDs can read this info. Simply obfuscating the name on the list of banned users (or not posting any names at all, only links to the posts that led to the ban) would eliminate most reputational damage. Ie, random searches for that person would not turn up a high pagerank debian.org page listing their youthful indiscretions. Using eg J. Hess would probably be fine in most cases. This also seems like a good compromise to me. Do the other folks who object to publishing information that could damage the poster's reputation (e.g., Bart, Ingo) think this is ok? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Should mailing list bans be published?
On Sun, Oct 27, 2013 at 10:33:42PM +0100, Florian Weimer wrote: * Joey Hess: Simply obfuscating the name on the list of banned users (or not posting any names at all, only links to the posts that led to the ban) would eliminate most reputational damage. Ie, random searches for that person would not turn up a high pagerank debian.org page listing their youthful indiscretions. Using eg J. Hess would probably be fine in most cases. I recommend to use a web page, and not announce bans on public mailing lists because such announcements invite subsequent discussion, likely decloaking the banned poster. Reducing subsequent discussion is inseparable from reducing both oversight and the closure given to other list participants. I don't consider posting such content on a web page to suitably address the concerns. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Should mailing list bans be published?
Hi folks, Was discussing with one of the listmasters (Alexander Wirt) on IRC today about mailing list bans, because it turns out that someone I was just about to ask the listmasters to ban from debian-devel had just been blocked in response to a request from someone else. 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: - Debian is not responsible for the reputation of someone who has gotten themselves banned for their behavior; their reputation is already in the mud if employers read their actual posts to the Debian lists. - It brings closure to the rest of our community to know that action has been taken against an abuser, showing that we've stood up for the principle of civil discourse and that the problem hasn't just gone away on its own because a troll got bored. - It gives Debian contributors confidence that bad behavior doesn't have to be silently endured as a cost of participating in Debian lists. - It improves *Debian's* reputation to the rest of the world, by showing that our mailing lists are not anything goes. - It provides a reference point for newcomers to the Debian community to judge their actions by, to understand what kinds of things will get them banned from participation (although I expect few of the people who need such guidance will actually take advantage of it...) - It casts sunlight on the kinds of decisions that the listmasters are making WRT bans, so that we collectively have oversight of these decisions and can ensure our principles are being applied fairly and consistently. So I don't think bans need to be posted anywhere prominent like debian-devel-announce, but I do think basic facts like who is banned, for how long, and the rationale (with links to specific mailing list posts as reference) should be made public. What do the rest of you think? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Should mailing list bans be published?
On Sat, Oct 26, 2013 at 08:56:59PM +0200, Ingo Jürgensmann wrote: Am 26.10.2013 um 19:46 schrieb Steve Langasek vor...@debian.org: 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 agree with Alexanders concern here. I understand Alexander's concern, but why should it outweigh all of the benefits to the project that I listed? Particularly given that anyone can already see the behavior that got them banned, why is it bad to also disclose publically that they've been banned? Publishing other peoples personal data without prior allowance might even violate privacy legislation in some countries. That's a red herring. They've already posted their name and email address publically by engaging in the behavior that got them banned in the first place. Posting that same name and email address with a statement that they've been banned is not a violation of privacy under any reasonable interpretation. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Should mailing list bans be published?
Hi Bart, On Sat, Oct 26, 2013 at 07:33:34PM +, Bart Martens wrote: 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 join Alexander on the above. What do the rest of you think? I suggest we keep things civil, with respect for the persons involved. It's really not up to Debian to harm someone's reputation, and that could reflect bad on Debian's reputation. I don't understand this argument. What harm comes to Debian's reputation from showing publically that we do not tolerate abusive behavior on our mailing list? If the world knowing about a ban would harm our reputation, then maybe we should pause to think whether the ban itself is correct. But I see no harm to Debian's reputation from banning people for the kinds of mailing list behavior that they are actually getting banned for. It can only improve Debian's current bad reputation for having a take-no-prisoners mailing list culture! As for respect for the persons involved: I don't believe the project owes anything to someone who can't behave with the minimum of civility required on our mailing lists to avoid being banned. We should be guided by what's best for the Debian project, not worry about hurting the feelings of someone whose behavior is so far beyond the pale that we find it necessary to ostracize them. Approaches I could support : - post the bans with reasons on debian-private - or maintain a list of bans with reasons in a text file on a Debian machine where DDs can read this info. I think posting this on debian-private is not as good as posting it publically, for some of the reasons mentioned in my original mail. (E.g., making it clear to outsiders that certain behavior will not be tolerated.) But it's a compromise I could support, if that's the consensus in the project. I don't think maintaining a list somewhere is sufficient; there should be some notification to the project when the bans take place. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Should mailing list bans be published?
On Sat, Oct 26, 2013 at 10:08:42PM +, Bart Martens wrote: What do the rest of you think? I suggest we keep things civil, with respect for the persons involved. It's really not up to Debian to harm someone's reputation, and that could reflect bad on Debian's reputation. I don't understand this argument. What harm comes to Debian's reputation from showing publically that we do not tolerate abusive behavior on our mailing list? The harm that could come to Debian's reputation is that Debian could be perceived as an organization that harms people's reputation by judging them in public about their behavior on the mailing lists. Ok, thanks for explaining. This isn't something that concerns me at all, but I understand that it concerns you. Approaches I could support : - post the bans with reasons on debian-private - or maintain a list of bans with reasons in a text file on a Debian machine where DDs can read this info. I think posting this on debian-private is not as good as posting it publically, for some of the reasons mentioned in my original mail. (E.g., making it clear to outsiders that certain behavior will not be tolerated.) That can be made clear without harming individuals' reputations. How do you think it can be made clear? We do have a list code of conduct already (http://www.debian.org/MailingLists/#codeofconduct), but the rules are vague; past attempts to make them more explicit have foundered. So while in theory there are other ways to make this clear, in practice it seems to be quite difficult. I don't think maintaining a list somewhere is sufficient; there should be some notification to the project when the bans take place. I can imagine that some DDs prefer to receive notifications, which can be obtained by simply using diff in crontab. That would fail to provide any of the benefits outlined in my original mail. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: debian patent policy?
Hi Paul, Forwarding your message on to debian-project, which is where project policies are discussed. On Fri, Sep 27, 2013 at 04:33:44PM -0500, Paul Elliott wrote: Policy Statement 1)Debian will not knowingly distribute software encumbered by patents; Debian contributors should not package or distribute software they know to infringe a patent. 2)Debian will not accept a patent license that is inconsistent with the Debian Social Contract or Debian Free Software Guidelines. 3)Unless communications related to patents are subject to attorney-client privilege, community members may be forced to produce them in a lawsuit. Also, patent concerns expressed publicly may turn out to be unfounded but create a good deal of fear, uncertainty, and doubt in the meantime. Therefore, please refrain from posting patent concerns publicly or discussing patents outside of communication with legal counsel, where they are subject to attorney-client privilege. This is very confusing. I have some ideas in my head that I am thinking about patenting, but I only want to torture the proprietary software people with it. I would certainly license all free software and free software users. But according to 1) that would not do any good, because 1) read literally means that if software is patented at all and software infringes on a claim, debian will have nothing to do with it. The key word here is infringe. Reading on a patent is not the same thing as infringement; if a piece of software implements a patent, but we have a valid license for that patent, that's not infringement. But 2) read conversely, implies that there could be a patent license that debian will accept. Yes, it must be a patent license that conveys to all downstreams the same rights that Debian is granted, and that transfers when the user exercises their freedom to create a (free) derivative work. After all, if debian accepted absolutely no patent licenses, the clause about inconsistant with the DSC or DFSG would be unnecessary, and 2) would read: Debian will accept no patent licenses. So what would a patent license consistant with DSC and DFSG look like? And what good would it do? 1) read literally means that if software infringes on the claims of a patent debian would have nothing to do with it, consistant license be damned. It is all very confusing. And 3 means I can't even ask anyone about this confusion. Can anybody clarify? 3) says not. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Authorizing minor expenses by DSA without prior DPL approval
On Thu, Sep 12, 2013 at 10:44:36AM -0700, Josh Berkus wrote: On 09/12/2013 10:17 AM, Lucas Nussbaum wrote: On 12/09/13 at 09:58 -0700, Josh Berkus wrote: On 09/12/2013 04:46 AM, Lucas Nussbaum wrote: DSA does not need to wait for DPL approval to make such expenses. The DPL will always approve such expenses, provided that the total outstanding amount spent in advance of DPL approval never exceeds US$400. $400 over what period of time? Over no specified period of time, other than until the DPL approves the expense. So the brake against possible craziness is the DPL approval, not a time-limit. That will be very hard for the SPI treasurer to track, so you'll need to be aware that SPI can't realistically enforce the policy. Leaving aside that the DSA can request reimbursement from the other NPOs. The only policy we can enforce would be if the DSA asks for any individual expense under $400, pay it, unless they ask for $400 severl times in quick succession, in which case query the DPL. Also, we will need the DPL to officially inform SPI who the DSA is, and whenever there is a DSA change. If that all works for you, then I have no further comment. It would certainly make things easier for the Treasurer to be able to just pay these expenses without needing to look for, and track, approval from the DPL. The proposed change doesn't require SPI to reimburse requests before they've been officially and individually approved by the DPL; it only allows the DSA team to spend the money in the knowledge that it fits Debian's guidelines and *will* be approved by the DPL. In fact, if I understand Lucas's proposal correctly, it does *not* authorize SPI or other Trusted Organizations to directly reimburse DSA expenses before they've been signed off by the DPL. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian companies group
On Thu, Sep 05, 2013 at 11:14:11AM +0200, Michael Meskes wrote: On Wed, Sep 04, 2013 at 08:39:00PM +0100, MJ Ray wrote: On 03/09/13 19:14, Michael Meskes wrote: Right and we already have a debian-consultants mailing list, don't we? Yes, and that list is also struggling, so why fork it? Because the list may be struggling because its definition is too wide open. Do you think this because you've surveyed companies that you think would like to participate in such a list and this is feedback they've given you, or is it merely speculation? From where I sit, the whole thing looks like a solution in search of a problem. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian companies group
On Tue, Sep 03, 2013 at 08:14:10PM +0200, Michael Meskes wrote: On Dienstag, 3. September 2013, Raphael Hertzog wrote: But I don't understand why interested DD aren't allowed to subscribe to it. I also don't understand what the minimum size requirement brings. me neither. why are small debian companies no debian companies (in this context)? Why shouldn't they? We had one person companies sponsoring DebConfs several times. Right and we already have a debian-consultants mailing list, don't we? The idea was that bigger companies may have other topics and ideas. But then maybe not, but it's worth a try imo. The numbers are not set in stone btw, but I strongly believe in the beginning we should not start with everyone, but a group that is not really represented so far. I was unaware that this list existed. It seems that it was created over a year ago at Zack's request: http://bugs.debian.org/650082 I don't understand the value of such a list at all, or why, if it's a closed list, it should be run on Debian infrastructure. What do Debian-using companies need to discuss that they can't already discuss on the existing public mailing lists? Why should Debian host such private discussions? It's not in the spirit of the Debian project to encourage such private forums. Companies who are not willing to have their discussions out in the open should take those discussions elsewhere, not have them hosted privately on a Debian server. Companies, or their representatives, are as welcome as anyone else to participate in the discussions which shape Debian. But what's set up here seems to encourage companies to direct their energies towards a forum that is not integrated into the mainstream of Debian, disenfranchising them instead of empowering them. Before worrying about changing the mailing list subscription rules, I think it would be more important for the project to evaluate the results of the first year's experiment. Has the list been used at all? What has it been used for? Have companies been effective in achieving their goals using this list? The graphs on lists.debian.org seem to indicate that the list has not seen much use: http://lists.debian.org/stats/debian-companies.png I don't see how the proposed changes to list subscription policy will help with that. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Authorizing minor expenses by DSA without prior DPL approval
On Tue, Aug 20, 2013 at 04:08:05PM +0200, Lucas Nussbaum wrote: I would like to change that process to: DSA is allowed to make expenses for up to USD 300 (total) every 7 days to support the operation of Debian infrastructure (pay shipping costs, purchase of cheap hardware such as cables, replacement disk, etc.). leader@ and auditor@ must be notified of the expense as soon as possible (typically, just after the expense is made, at the same time as asking a Trusted Organization's treasurer for reimbursement). This process can be revoked at any time by the DPL, but that revocation does not affect the reimbursement of expenses that have already been notified. This process can be temporarily suspended at any time by auditor@. $300/week doesn't seem all that small; that adds up to an annual cap of $15,600/year. Is that in line with actual DSA expenditures? Is it actually sustainable, wrt revenue from Debian donations? I think $15k/year is a rather large amount for the petty cash budget for an organization the size of Debian, and wonder if this should be more conservative (e.g., $300/2 weeks, $500/mo?) so that DSA has the flexible spending cap they need without risk of accidentally running the accounts dry. Right. I clearly do not expect DSA to spend $15k/year using that process. I do not expect the procedure to be be used more than 10-15 times a year. If it looks like DSA is using this process a lot more than this expectation, or that DSA is trying to game the system by artificially splitting larger expenses to keep them under the limit, I will of course reconsider the whole process. If it is used 10 to 15 times per year, it means at most $3000 - $4500 per year, and that's something we can afford. If that's your expectation, then I think it makes sense to structure the approval to match. Better to be too conservative and have them have to come to you once or twice a year for approvals, than to have money spent that shouldn't have been due to a misunderstanding of expectations. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Authorizing minor expenses by DSA without prior DPL approval
Hi Lucas, On Fri, Aug 16, 2013 at 12:27:49PM +0200, Lucas Nussbaum wrote: Context: according to Constitution §5.1.10: The Project Leader may: [...] In consultation with the developers, make decisions affecting property held in trust for purposes related to Debian. (See §9.). Such decisions are communicated to the members by the Project Leader or their Delegate(s). Major expenditures should be proposed and debated on the mailing list before funds are disbursed. The Debian System Administrators sometimes need to make small expenses for things such as buying cables or replacement hardware, paying shipping fees for moving hardware around, etc. As an example, this happened three times in July [1]. [1] https://lists.debian.org/debian-devel-announce/2013/08/msg2.html The current procedure is that they ask for leader@ approval before making the expense. Even if I try hard to act quickly on such requests, it still requires a round-trip of emails that slows down their work (look up the exact price, send mail, wait for approval, go back to make the purchase). I would like to change that process to: DSA is allowed to make expenses for up to USD 300 (total) every 7 days to support the operation of Debian infrastructure (pay shipping costs, purchase of cheap hardware such as cables, replacement disk, etc.). leader@ and auditor@ must be notified of the expense as soon as possible (typically, just after the expense is made, at the same time as asking a Trusted Organization's treasurer for reimbursement). This process can be revoked at any time by the DPL, but that revocation does not affect the reimbursement of expenses that have already been notified. This process can be temporarily suspended at any time by auditor@. $300/week doesn't seem all that small; that adds up to an annual cap of $15,600/year. Is that in line with actual DSA expenditures? Is it actually sustainable, wrt revenue from Debian donations? I think $15k/year is a rather large amount for the petty cash budget for an organization the size of Debian, and wonder if this should be more conservative (e.g., $300/2 weeks, $500/mo?) so that DSA has the flexible spending cap they need without risk of accidentally running the accounts dry. In any case, I have no objection to the principle of streamlining the approval process for DSA's day-to-day expenses. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Revising the Code of Conduct
On Tue, May 21, 2013 at 06:37:39PM +0900, Norbert Preining wrote: 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? As one of the most routinely abusive posters on Debian lists towards your fellow developers: not you. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Revising the Code of Conduct
On Wed, May 22, 2013 at 12:24:51AM +0900, Norbert Preining wrote: On Di, 21 Mai 2013, Steve Langasek wrote: As one of the most routinely abusive posters on Debian lists towards your fellow developers: not you. Thus neither you ..., logic wins. Wow, being told most abusive posters ... would you kindly use your browser and browse my posts on debian-tex-maint lists and let me know the ratio of you-consider-abusive to you-consider-ok?!?!? Abuse does not become acceptable by being embedded in a mass of politeness. Abuse is abuse and is always unacceptable. The ratios do not matter. Likewise, debian-tex-maint has no relevance to my comment. Even if you're perfectly polite there, all that establishes is that you're nice to people when you're in charge. It doesn't excuse your abusive posts on other lists (like debian-devel). On Wed, May 22, 2013 at 09:44:31AM +0900, Norbert Preining wrote: I openly request an apology from you. That is unbearable: You publicly defamed me by stating: On Di, 21 Mai 2013, Steve Langasek wrote: As one of the most routinely abusive posters on Debian lists towards your fellow developers: not you. Onto which I asked for evidence: On Mi, 22 Mai 2013, Norbert Preining wrote: Wow, being told most abusive posters ... would you kindly use your browser and browse my posts on debian-tex-maint lists and let me know the ratio of you-consider-abusive to you-consider-ok?!?!? If you cannot come up with support for the insult you posted here (which was btw the first personal insult in these threads!) I will take further steps necessary. You don't think it's a bit excessive to escalate to the DPL after 9 hours with no response? I do have other things to do with my day besides digging up references to mailing list posts. However, I do agree with you that, having accused you of being abusive to your peers on mailing lists and being asked for evidence, I have a responsibility to back up my statements. So, here we go: https://lists.debian.org/debian-devel/2011/06/msg00441.html And I am pissed that the alioth people are soo crazy ... https://lists.debian.org/debian-devel/2011/06/msg00442.html It is simply SNAFU!!! In fairness, once you recognized you had a local configuration error, you apologized to the alioth admins. And perhaps as a non-native speaker, you don't know the expansion of SNAFU, or recognize that it's offensive. But it is; and this is disrespectful of the work of the alioth team, and would be an inappropriate way to approach this problem even if the error had not been on your side. And this is not the only instance of such abuse from you. https://lists.debian.org/debian-devel/2009/12/msg00771.html Can someone of the proposers of this (nice? stupid? rubbish?) format explain me please why on earth: - git-buildpackage - dpkg-buildpackage - and in fact at the bottom dpkg-source fuck around in my git repository, applying patches, just for builing a source package? You tried the 3.0 (quilt) format and you didn't like it. That's understandable; it's not a perfect solution, many other people don't like it either, and its interactions with a package VCS are particularly frustrating. What's not ok is to refer to the format as nice/stupid/rubbish, which is not made nicer by using the word nice as an option; or to describe what dpkg-source is doing as fuck[ing] around in [your] git repository. This is rude, and disrespectful of the work of the dpkg maintainers. And again two years later: https://lists.debian.org/debian-devel/2012/01/msg00478.html So what is it that dpkg-buildpackage, dpkg-source, and all the quilt 3.0 stuff is s braindamaged Calling other people's work braindamaged is not respectful. And finally, in the most recent example: https://lists.debian.org/debian-devel/2013/05/msg01138.html Of course, RM will go hell for another embedded copy, but I don't give a big cake of chocolate or so for that. You may think this is just a matter of you being honest in a technical discussion. But it isn't; you went out of your way to mention that you don't care what the release team thinks of your plan. You later go on to explain why the upload you've done is perfectly safe and is not a security issue (https://lists.debian.org/debian-devel/2013/05/msg01225.html) - so why do you describe this as another embedded copy and claim that the release team will have a problem with it? Either you think the release team is too stupid to recognize that this copy included *only* in the source is a non-issue; or you're deliberately antagonizing them. All of this is inappropriate, abusive behavior towards your fellow developers. It does not belong on our mailing lists. And the fact that you don't realize this (as evidenced by the repeated occurrences, and that you challenged me for examples) is exactly why you should not be the arbiter of what's acceptable under a code of conduct. -- Steve Langasek
Re: Revising the Code of Conduct
On Wed, May 22, 2013 at 01:42:04PM +0900, Norbert Preining wrote: Wow, I am impressed, 5 emails out of 15150 (current search result on lists.debian.org) makes me: As one of the most routinely abusive posters on Debian lists towards your ^ That is your definition of routinely: 0.033% ? Assuming that you missed 100 other emails that would still remain 1% Thanks for this enlightment on what routinely means in English, for you. Thanks for continuing to be a walking case study of why we need an enforceable code of conduct on Debian mailing lists. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Registering the Debian Logo as our trademark?
Hi Brian, On Mon, Apr 22, 2013 at 04:04:34PM -0400, Brian Gupta wrote: I have been helping to field trademark inquiries for Debian since late February, and the issue of our Logo has come up a number of times. Currently, our logo is not a registered Trademark, but is considered (and treated by our current Trademark policy) as a common law trademark, in that we have been using it to represent Debian for many years, and many people see it and recognize it as Debian's logo. I know there have been discussions in the past about moving forward with officially registering the logo, but these discussions seem to have not ended with a clear decision or agreement one way or another, hence the status quo of unregistered common law trademark. Generally speaking, as a matter of law, it would be better if we registered our logo as our Trademark. We had also gotten advice from our legal counsel (SFLC) encouraging us to do so. I don't believe any changes would be required to our Trademark policy to accomodate the change from common law to registered trademark, we'd just have the benefit that we'd have an easier time protecting it, if we ever found a need to do so. Thanks for tackling this perpetually murky issue. I agree that we should pursue getting a registered trademark for the Debian logo, putting to bed once for all the questions around its use. A one-time $700 cost seems reasonable to me; our logo is nearly as important to our brand as our name is. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: ditching the official use logo?
On Mon, Oct 08, 2012 at 08:48:40PM +0200, Thijs Kinkhorst wrote: On Mon, October 8, 2012 16:52, Paul Tagliamonte wrote: Right now, the way I understand it is that you can, in a DFSG and legal way, create a document with the Debian logo brand, and create a certificate that looks to be from Debian, and sell them as some sort of certification from Debian without recourse from the Debian project. This is possible whether the official use logo exists or not: right now anyone can create a certificate with the open use logo, which is what everyone and their dog recognises as the Debian logo. The current open use licence does not allow you to misrepresent yourself as being Debian. The Cc license summary even mentions prominently that it you may not use it to claim endorsement by Debian: http://creativecommons.org/licenses/by-sa/3.0/ I find it therefore doubtful that keeping the bottle logo solves any real world problem. I find it doubtful that getting rid of the bottle logo solves any real world problem. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: trademark policy draft
Hi Stefano, On Mon, Aug 13, 2012 at 08:07:02PM +0200, Stefano Zacchiroli wrote: On Mon, Aug 06, 2012 at 03:25:55PM +0100, Ian Jackson wrote: Thijs Kinkhorst writes (Re: trademark policy draft): On Wed, August 1, 2012 18:54, Russ Allbery wrote: We can choose to abandon our trademark and make it indefensible, but we should do that intentionally and not under an illusion that we're just creating a better usage policy. I would not be in favour of this. FWIW, I agree with Ian's position here. Generally speaking, I think there is room in Free Software for project marks and that, in principle, there is nothing wrong with defending them. As observed elsewhere in this thread, it is just hard to defend them in a reasonable way, given that the law is what it is. Oddly enough, trademark policies that try to embrace Free Software principle are still relatively uncharted territory, which is slowly getting better in recent years. By giving it a try, working together with lawyers that do understand Free Software, I think we can actually contribute something useful for other Free Software projects out there. Down to the specificities of Debian procedures, I consider my duty to take care of Debian assets, including trademarks. I would not take the responsibility of acting in a way that --- according to our legal advisors --- might endanger them.. Even if there was a clear consensus that endangering the trademark was the Right Thing To Do? I'm hoping to write a longer response to the proposed policy where I can do justice to the specifics, but for the moment, suffice it to say that I think that some of the recommendations for how to protect our trademark cross the line from things it's reasonable for everyone to do to protect their mark into jerky things that you do because there's some bit of case law somewhere that led to a mark being invalidated and you're paranoid that the same thing will happen to you. Sometimes the right answer is that the case law is *bad* and needs to be overturned - which never happens if no one is willing to take a stand against it. For a free software project like Debian, I believe it's more important to uphold the principle of not being jerky to our neighbors than it is to have an ironclad assurance that our trademark could never be invalidated. I don't think the argument we could lose our trademark unless we [...] is complete unless it also includes some examination of how likely that outcome really is. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: RFC - Changing current policy of debian.net entries
On Fri, Jun 29, 2012 at 06:18:15PM +0200, Wouter Verhelst wrote: I don't think that's the best way forward. I see three common uses of the debian.net namespace: - As a testing playground for services which intend to eventually be integrated into debian.org. - People who use it as some sort of personal playground or personal mail domain or similar things. I'm not sure this should be allowed at all (and most people would seem to agree), but it is happening. - As a name for a default setting in a webbrowser (default home page), collaboration tool (e.g., gobby could default to gobby.debian.net), default server for a Debian-packaged game (tetrinet.debian.net), download URL for installer packages in non-free (I believe flashplugin-nonfree uses a debian.net URL to download the flash plugin, but could be mistaken), or similar things. Calling stuff in the first category in incubation stage would seem to be reasonable, as would banning the second category. I don't think there's anything at all reasonable about banning the second category. This is historically a large part of what the debian.net domain was *for*. It's a perk of being a member of the Debian project, which hurts no one. We should be happy that developers are proud enough of being members of Debian to advertise it in their domain usage, instead of trying to suppress the usage for fear that it will tarnish Debian's reputation. If there are uses of the .debian.net domain that reflect poorly on Debian, let those be taken up with the individuals responsible. I think it's silly to try to impose a policy on this domain because end users can't keep the domains straight. As long as developers are taking appropriate care not to confuse our users about the status, I don't see the problem; and if developers aren't taking appropriate care, that should be dealt with on a case-by-case basis - escalating to the DAM if necessary. But I don't think running a game server as a service to Debian users is something DSA should do (so it's not strictly in incubation), nor that it should be considered bad usage of the debian.net domain; and changing those to include a DD name in the URL would require an update of a package in stable if the person who used to maintain it is now no longer interested in running that service, the avoidance of which probably being the main reason why you'd want to be using a debian.net URL. Yes. Moving either pioneers.debian.net or pdx.debian.net to a login-specific subdomain would defeat the purpose of having them at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Draft] GR: diversity statement for the Debian Project
On Mon, May 07, 2012 at 08:05:33PM +0200, Francesca Ciceri wrote: I agree that this should go out. Just, we have our community twice in the text. punAny linguistic expertise with us we could possibly welcome?/pun LOL Anyway, it sounds strange enough to me to suggest substituting the first occurrence with just us. And, since we also want new contributors to also interact constructively between themselves, and since to me it is somewhat redundant in the first place, I would even feel inclined to remove the with our community. I'm not sure about removing the with our community, but as this is a style problem (and not a content one) I'd postpone the discussion on it (asking for proofread on -l10n-english) after the vote. I can't agree with this. The wording of position statements matters - what we ratify should be posted word for word on the website. But I also think the crowdsourced review on debian-project has already been more than sufficient and don't think there's any point in further proofreading on -l10n-english. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Draft] GR: diversity statement for the Debian Project
On Thu, May 03, 2012 at 12:32:03AM +0200, Francesca Ciceri wrote: DRAFT TO BE VOTED STARTS HERE The Debian Project welcomes and encourages participation by everyone. It doesn't matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community. While much of the work for our project is technical in nature, we value and encourage contributions from those with expertise in other areas, and welcome them into our community. DRAFT TO BE VOTED ENDS HERE Seconded. I know you haven't called for seconds yet, but I don't see any reason to wait when this has already reached broad consensus on debian-project. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: xth wrap-up about statement on diversity, statement may be issued without general resolution
On Sat, Apr 21, 2012 at 05:52:37PM +0200, Alexander Reichle-Schmehl wrote: Hi! There seems to be only two ways out of this: (1) have a GR, or (2) turn a blind eye on the Constitution recommended procedure, accepting we made a mistake (of which I'm ready to take the blame), and move on. While I still see the advantage of not doing a GR, I don't think they warrant doing (2) as that will set a pretty bad precedent. Well, in theory you could also send a mail to d-d-a, announcing your intention to publish the statement, and wait if someone proposes a GR to override you. But I agree, that 1 should be preferred over that, just mention it for completeness ;) As a strict constitutionalist, I would feel compelled to propose a GR on principle, even though I also support having such a diversity statement. So I would much prefer that Stefano simply start a GR in favor of the diversity statement instead. He does have a leg up in that as DPL, he can propose the GR without waiting for seconds. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: xth wrap-up about statement on diversity, statement may be issued without general resolution (Re: Diversity statement for the Debian Project)
On Fri, Apr 20, 2012 at 09:25:21AM +0200, Stefano Zacchiroli wrote: On Thu, Apr 19, 2012 at 09:47:04PM -0400, Filipus Klutiero wrote: The message from Stefano Zacchiroli quoted below includes a wrap-up (of the wrap-up (of the...)) about the statement on diversity in contributors proposed by Francesca Ciceri. Stefano asked to publish it in #669011, although the statement is not approved. I beg you pardon? It's been approved by me with that mail, after having given time to comment on that to readers of this list. Also, please note how -project was Cc:-ed on my request already (see https://lists.debian.org/debian-project/2012/04/msg00073.html) so it's not clear to me why you felt there was a need to give this warning kind of mail. Perhaps because under the constitution, position statements are a power that the developers exercise under GR, not a power that the DPL has? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#649679: [copyright-format] Clarify what distinguishes files and stand-alone license paragraphs.
On Mon, Dec 19, 2011 at 10:34:24AM +0100, Jakub Wilk wrote: * Charles Plessy ple...@debian.org, 2011-12-19, 10:12: Of course, I agree that making a stand-alone License paragraph with an extra Fiels field would be an horror. But I am inclined to think that it is obvious enough that we do not need to constrain the syntax. With the change you propose extra checks are needed while parsing. I thought it was obvious when I implemented lintian checks, but it turns out to not be so easy after all. The problem is with paragraphs like this: | Copyright: 2042, J. Random Hacker | License: BSD-6-clauses | Redistribution and use in source and binary forms, with or without | modification, are permitted provided that the following conditions | are met: blah, blah, blah, blah, blah and blah. In early DEP-5 drafts, Files field could be ommited in certain circumstances, so this could have been a perfectly valid files paragraph. But with the current DEP-5 version, if we allow any extra fields, this suddenly becomes a valid stand-alone license paragraph. Please see bug #652380 for a real-world example. Meh. When someone writes their debian/copyright with this line at the top: Format: http://dep.debian.net/deps/dep5 then they have no business complaining when parsers and validators reject the file as not being compliant with the current version of the spec. More to the point, lintian should *not* be trying to accept such files on the basis that this was once considered valid. Lintian should be enforcing the current spec on anything that claims to be a DEP5 file, not trying to support all kinds of intermediate forms as valid. Now if there were a Format: line at the top pointing at a url that lintian doesn't know about, it would be reasonable to skip the rest and simply note that an unrecognized format is being used. But when the file says it's using DEP-5, it should be DEP-5. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#649679: [copyright-format] Clarify what distinguishes files and stand-alone license paragraphs.
On Mon, Dec 19, 2011 at 10:12:52AM +0100, Charles Plessy wrote: I don't think that should be legal either however; we allow extra fields to be added to any paragraph, but I don't believe the intent is to allow *defined* fields to be used in paragraphs where they are not specified to be permitted - only to allow new field names to be used. So I think something like the attached patch should be applied. Thoughts? I am sometimes using an extra Source field in some Files paragraphs, when they define works that are not the creation of the main authors, especially when it was difficult to find their original upstream location. Why use the same field name (Source) in the Files paragraphs as in the header paragraph when this is not defined - instead of using, say, 'Component-Source' (or even just 'Comment')? Have you proposed making this use of Source part of the standard? If so I'm afraid I missed that. I can understand that you would want to document the source of individual components in cases where the whole work is no longer available, but I think that reusing an already-defined field name for the purpose just makes it harder for validators to distinguish between accidental errors and deliberate extensions. Indeed, there is already one recommendation in the spec for exactly this purpose: No prefixing is necessary or desired, but please avoid names similar to standard ones so that mistakes are easier to catch. There's nothing more similar to a standard field name than one which is identical. ;) Of course, I agree that making a stand-alone License paragraph with an extra Fiels field would be an horror. But I am inclined to think that it is obvious enough that we do not need to constrain the syntax. With the change you propose extra checks are needed while parsing. If nevertheless the consensus is to apply your changes, I would like to suggest to normalise the vocabulary: either “extra fields” or “additional fields”, but the current patch uses both. The Policy's chapter 5 uses “additional”, so this is where my choice would go even if it will increase the difficulty to search for previous discussions on the topic. That's fair. Updated patch attached. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org === modified file 'dep5/copyright-format.xml' --- old/dep5/copyright-format.xml 2011-12-18 17:38:43 + +++ new/dep5/copyright-format.xml 2011-12-19 18:23:14 + @@ -108,14 +108,17 @@ mandated upstream information, copyright notices and licensing details. /para para - The syntax of the file is the same as for other Debian control files, as - specified in the Debian Policy Manual. See its ulink + The syntax of the file is the same as for other Debian control files, + as specified in the Debian Policy Manual. See its ulink url=http://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax;section - 5.1/ulink for details. 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 filenamedebian/copyright/filename specification will attempt to - avoid conflicting specifications for widely used extra fields. + 5.1/ulink for details. Additional fields can be added to any + paragraph, but the fields defined in this document are only allowed in + the paragraphs where they are specified to be present. No prefixing + is necessary or desired for new field names, but please avoid names + similar to standard ones so that mistakes are easier to catch. Future + versions of the filenamedebian/copyright/filename specification + will attempt to avoid conflicting specifications for widely-used + additional fields. /para para The file consists of two or more paragraphs. At minimum, the file signature.asc Description: Digital signature
Re: [DEP5] Format of Copyright header
On Wed, Dec 14, 2011 at 03:05:58PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: On the other hand, while a formatted text field type *may* be reflowed for display, is there any software doing that today wrt DEP5? Maybe it's enough to rely on the absence of such formatting in DEP5 parsers for the time being; if and when something starts to care about formatting the Copyright field, we can always scan the archive to detect files that look like they'll wind up formatted poorly. And of course, anyone who cares about formatting to this degree can always add that extra space at the front of the line. I notice, in fact, that all our examples of multi-line Copyright: fields in the draft already do this. So the suggestion is to make it formatted text and recommend that the whole field be pre-formatted text (indicated by two leading spaces)? Hm, yes, that would work and is probably the simplest. It occurs to me that an alternative would be to say that line-based lists support something akin to RFC 5322 continuation semantics: if a line starts with two or more spaces, it's taken as a continuation of the previous line. Then you could do: Copyright: 2001 Russ Allbery 2004, 2005, 2011 The Board of Trustees of the Leland Stanford Junior University and have that considered two lines, one of which has a continuation line. That would preserve the structured semantics, if anyone cares about them, at the cost of introducing new syntax to line-based lists that isn't supported by the other control fields that use line-based lists (like Files or the checksum fields). It would preserve the capacity for structured semantics, but it would change the meaning of many files already in the wild. On that basis, I would like to avoid making such a change before 1.0 and think that formatted text is the best option here. Would the attached patch do the job? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org === modified file 'dep5/copyright-format.xml' --- dep5/copyright-format.xml 2011-12-14 07:46:52 + +++ dep5/copyright-format.xml 2011-12-17 07:04:26 + @@ -486,12 +486,12 @@ section id=copyright-field titlevarnameCopyright/varname/title para -Line-based list: one or more free-form copyright statement(s), one -per line. In the header paragraph, 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. In the Files paragraphs, it gives the copyright -information that applies to the files matched by the +Formatted text, no synopsis: one or more free-form copyright +statement(s), one per line. In the header paragraph, 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. In the Files paragraphs, it gives +the copyright information that applies to the files matched by the varnameFiles/varname pattern. If a work has no copyright holder (i.e., it is in the public domain), that information should be recorded here. signature.asc Description: Digital signature
Re: [DEP5] Format of Copyright header
On Fri, Dec 16, 2011 at 11:09:04PM -0800, Russ Allbery wrote: It would preserve the capacity for structured semantics, but it would change the meaning of many files already in the wild. True. On that basis, I would like to avoid making such a change before 1.0 and think that formatted text is the best option here. Works for me. Would the attached patch do the job? +Formatted text, no synopsis: one or more free-form copyright +statement(s), one per line. Well, except this still isn't true. The statements may be split across multiple lines. Maybe just say: Formatted text, no synopsis: one or more free-form copyright statement(s). Any formatting is permitted; see the examples below for some ideas for how to structure the field to make it easier to read. instead? Looks good to me, committed. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [DEP5] clean up the document structure
On Mon, Dec 12, 2011 at 02:45:09PM -0800, Russ Allbery wrote: Does this look ok? Does anyone think there's a better way to do this? Have I introduced any errors in the conversion? Yes, please. This looks great. Thank you! On Tue, Dec 13, 2011 at 04:11:49PM +0900, Charles Plessy wrote: this is a good idea. The patch applies well and before or after conversion to HTML, I have not seen errors. Thanks for the review. Pushed to the DEP repo. While proofreading it, I found the part where it is written “Copyright alone makes no sense”. Perhaps it could be clarified whether, regardless of sense, a file where the Header paragraph has a Copyright field but no License field is syntactically valid or not. Yes, this is also something I want to fix but wanted to treat separately from the restructuring. I'll propose a patch soon. I also noted that in the description of the Format field, it is written “Required in header paragraphs”, but the such information is not given in similar cases, for instance the Files field. Perhaps this could be normalised. Agreed. The simplest way to normalize is to drop the comment in the description of the Format field, since that's an artifact of my earlier thinking on how to structure this. Do you agree, or do you think we should instead add this information to all of the field definitions? If the latter, would you be willing to provide a patch? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [DEP5] clean up the document structure
On Wed, Dec 14, 2011 at 07:30:34AM +0900, Charles Plessy wrote: Le Tue, Dec 13, 2011 at 10:36:00AM -0800, Steve Langasek a écrit : On Tue, Dec 13, 2011 at 04:11:49PM +0900, Charles Plessy wrote: I also noted that in the description of the Format field, it is written “Required in header paragraphs”, but the such information is not given in similar cases, for instance the Files field. Perhaps this could be normalised. Agreed. The simplest way to normalize is to drop the comment in the description of the Format field, since that's an artifact of my earlier thinking on how to structure this. Do you agree, or do you think we should instead add this information to all of the field definitions? If the latter, would you be willing to provide a patch? I would prefer to drop the comment. This would give the DEP a more similar structure as in the Policy's chapter 5, that defines the syntax of control files. Ok, committed to the repo. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [DEP5] Format of Copyright header
On Mon, Dec 12, 2011 at 02:50:17PM -0800, Russ Allbery wrote: I noticed in reviewing another patch that the Copyright header is a line-based list. One unfortunate implication of that is that this means lines are required to be longer than 80 columns if the name of the copyright holder is long. For example: Copyright: 2004, 2009, 2011 The Board of Trustees of the Leland Stanford Junior University Previously in DEP-5-converted files, I've been writing that the same way that I usually write it elsewhere, namely: Copyright: 2004, 2009, 2011 The Board of Trustees of the Leland Stanford Junior University but formally that's two separate lines, one that doesn't have a copyright holder and one that doesn't have a date. Yes, I noticed this myself when preparing the patch. :) On Tue, Dec 13, 2011 at 10:14:37AM +0900, Charles Plessy wrote: among the four “types of values” defined, only “line-based list” preserves all newlines at any step of the data flow. Using the other muliti-line type, “formatted text”, one would need to prevent word wrapping by separating each copyright notice with escaped empty lines, or to ensure they are displayed verbatim by starting each line by at least two spaces. Good point. On the other hand, while a formatted text field type *may* be reflowed for display, is there any software doing that today wrt DEP5? Maybe it's enough to rely on the absence of such formatting in DEP5 parsers for the time being; if and when something starts to care about formatting the Copyright field, we can always scan the archive to detect files that look like they'll wind up formatted poorly. And of course, anyone who cares about formatting to this degree can always add that extra space at the front of the line. I notice, in fact, that all our examples of multi-line Copyright: fields in the draft already do this. Given that there is no easy and systematic way to associate specific copyright notices with specific files, my personal opinion is that for the 1.0 version, it is safer to consider the whole field free-form, under the “line-based list” syntax, but without its syntactic implications. I find this overloading of line-based list unsatisfactory. On balance, I would prefer to see it made a formatted text field. If there is agreement, perhaps the current draft could be amended to reflect this. It is a normative change, but that will not invalidate any existing file. I agree that bugfixing this is worthwhile right now since it doesn't invalidate existing files; I only prefer a different bugfix. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
[DEP5] Clarification of the minimum required structure
Hello, Currently the DEP5 draft includes the following text: The Copyright and License fields in the header paragraph may complement but do not replace the files paragraphs. This implies, but does not state explicitly, that there must be at least one Files paragraph in the file to be compliant. I would like to see this corrected by making it explicit in the section on File syntax what the minimum required structure is; but it's possible others have a different understanding of this text. Is the attached patch ok to commit? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org === modified file 'dep5/copyright-format.xml' --- old/dep5/copyright-format.xml 2011-12-12 07:48:31 + +++ new/dep5/copyright-format.xml 2011-12-12 08:01:32 + @@ -118,6 +118,12 @@ avoid conflicting specifications for widely used extra fields. /para para + The file consists of two or more paragraphs. At minimum, the file + must include one link linkend=header-paragraphheader + paragraph/link and one link linkend=files-paragraphFiles + paragraph/link. +/para +para There are four kinds values for fields. Each field specifies which kind is allowed. /para signature.asc Description: Digital signature
Re: [DEP5] Clarification of the minimum required structure
Hi guys, On Mon, Dec 12, 2011 at 12:51:59AM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: This implies, but does not state explicitly, that there must be at least one Files paragraph in the file to be compliant. I would like to see this corrected by making it explicit in the section on File syntax what the minimum required structure is; but it's possible others have a different understanding of this text. Is the attached patch ok to commit? During the discussion of allowing Copyright and License fields in the header paragraph, one of the things that was raised is the possibility of using the DEP-5 format with *just* a header paragraph as a structured way of representing the level of detail found in a lot of old-school debian/copyright files. It would let people convert the copyright files that just say here's the copyright and license for upstream to DEP-5 without implying that they've actually reviewed each file and confirmed they are all covered under that license (and not, say, some compatible one). I see two options that we could choose for a minimal file: - single header paragraph with License and Copyright fields (both would have to be required in the case that there are no other paragraphs). In this case, it is assumed that the License/Copyright fields in the header paragraph include all required notices, but no conclusions can be drawn about whether there's a compilation copyright here. - single header paragraph plus a single Files: * paragraph. In this case, any License/Copyright fields in the header paragraph are used only to document compilation copyright and whole-package license terms (e.g., the effective license of a package whose individual files are dual-licensed but only one of these licenses is compatible with the rest of the work; or when a maintainer is choosing to sublicense or redistribute a package under different terms than the obvious ones). This implies that the maintainer must make the additional effort of working out what a correct copyright notice is that covers Files: *. I have no preference between these two, but I do think it's important to pick one so that the semantics are consistent. Given the current language and the feedback in this thread, I think there is a general preference for the second option. Russ, does this meet your needs? And if not, do you think this is important to address in 1.0? Now, this is a really nit-picky and strange edge case, and I don't really mind if we decide that it's not important and rule it out. There isn't that much difference between what I describe above and just using a Files: * stanza, and the distinction is probably too particular to be worth explaining. Well, both of these options still allow for License/Copyright in the header paragraph; it's just a matter of whether Files: * is required with it. On Mon, Dec 12, 2011 at 10:05:15AM +0100, Stefano Zacchiroli wrote: Agreed. It is an exception to the general rule that each file in a source package has a matching File: section of debian/copyright, with very little benefits. Allowing such an exception calls for unneeded, if..then..else clauses both in DEP-5 implementations and in the head of humans when reading/writing debian/copyright files. It is true, as you imply, that forcing to write Files: * might be felt a stronger statement than just stating a global Copyright / License. But I do see such a feeling as a good thing: it'd be an incentive to do such a review, and to do so in a more principled way. The counterargument is that if this requires maintainers to do more work in order to create a dep5 copyright file which is both valid and accurate, it may slow adoption of the format for some cases. From previous discussions, I gather that for some of Russ's upstreams, this could be a prohibitive amount of work. But personally I don't think that's a blocker for 1.0. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
[DEP5] clean up the document structure
The current DEP5 document is awkward to read with an eye towards implementation. Several field names are common to more than one paragraph type, yet the definitions of these fields are given as part of the definition of one paragraph type or the other; and as a result, the definitions of each paragraph type are very long and easy to get lost in. I propose to refactor the document to add a new top-level Fields section, and to split the definitions of the fields out from the information about their usage in each paragraph type. Patch is attached. Does this look ok? Does anyone think there's a better way to do this? Have I introduced any errors in the conversion? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org === modified file 'dep5/copyright-format.xml' --- old/dep5/copyright-format.xml 2011-12-12 08:10:20 + +++ new/dep5/copyright-format.xml 2011-12-12 18:32:57 + @@ -181,100 +181,66 @@ section id=header-paragraph titleHeader paragraph (Once)/title - section id=format-header-field -titlevarnameFormat/varname/title -para - Required single line: URI of the format specification, such as: - literalhttp://www.debian.org/doc/packaging-manuals/copyright-format/1.0//literal -/para - /section - - section id=upstream-name-header-field -titlevarnameUpstream-Name/varname/title -para - Optional single line: the name upstream uses for the software -/para - /section - - section id=upstream-contact-header-field -titlevarnameUpstream-Contact/varname/title -para - Optional 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 RFC5322 addresses or URIs. -/para - /section - - section id=source-header-field -titlevarnameSource/varname/title -para - Optional 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. The Debian Policy section ulink - url=http://www.debian.org/doc/debian-policy/ch-docs#s-copyrightfile;12.5/ulink - requires this information unless there are no upstream sources, which - is mainly the case for native Debian packages. If the upstream source - has been modified to remove non-free parts, that should be explained - in this field. -/para - /section - - section id=disclaimer-header-field -titlevarnameDisclaimer/varname/title -para - Optional formatted text, no synopsis: this field can be used in the - case of non-free and contrib packages (see ulink - url=http://www.debian.org/doc/debian-policy/ch-docs#s-copyrightfile;12.5/ulink) -/para - /section - - section id=comment-header-field -titlevarnameComment/varname/title -para - Optional formatted text, no synopsis: this field can provide - additional information. For example, it might quote an e-mail from - upstream justifying why the license is acceptable to the main archive, - or an explanation of how this version of the package has been forked - from a version known to be DFSG-free, even though the current upstream - version is not. -/para - /section - - section id=license-header-field -titlevarnameLicense/varname/title -para - Optional formatted text, with synopsis: in the header paragraph - (no varnameFiles/varname specification), this field gives the - license information for the package as a whole, which may be different - or simplified from a combination of all the per-file license - information. See also varnameLicense/varname below in the - link linkend=files-paragraphFiles paragraph/link section. -/para - /section - - section id=copyright-header-field -titlevarnameCopyright/varname/title -para - Optional line based list: in the header paragraph (no - varnameFiles/varname 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 varnameCopyright/varname below - in the link linkend=files-paragraphFiles paragraph/link - section. -/para -para - The varnameCopyright/varname and varnameLicense/varname fields
Re: [DEP5] Clarification of the minimum required structure
On Mon, Dec 12, 2011 at 12:28:51PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: - single header paragraph plus a single Files: * paragraph. In this case, any License/Copyright fields in the header paragraph are used only to document compilation copyright and whole-package license terms (e.g., the effective license of a package whose individual files are dual-licensed but only one of these licenses is compatible with the rest of the work; or when a maintainer is choosing to sublicense or redistribute a package under different terms than the obvious ones). This implies that the maintainer must make the additional effort of working out what a correct copyright notice is that covers Files: *. I have no preference between these two, but I do think it's important to pick one so that the semantics are consistent. Given the current language and the feedback in this thread, I think there is a general preference for the second option. Russ, does this meet your needs? Yup. That option seems fine to me. Thanks, patch pushed to the DEP repo then. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: copyright-format: with keywords exception underspecified
On Sat, Nov 26, 2011 at 11:17:40AM +0900, Charles Plessy wrote: Le Fri, Nov 25, 2011 at 02:19:34PM -0600, Steve Langasek a écrit : I've committed the below patch to the dep repo on svn.debian.org. This is a HTML document that you modify, Yes, and I'm very unhappy with you for that. You committed that change to the DEP repository without consulting the driver of the DEP in question. but it has a DocBook source, indicated in the DEP header. With your changes, the information is not accurate anymore. Yes, it seems I will need to correct this. Please explain to the project why you are forking a work that is now developed in the debian-policy package. This is not a finalized DEP and I have not agreed to have it developed in the debian-policy package using the policy process. This transition was impulsed by Lars at a time where you were co-drivers, and you have not objected to it. That is incorrect. I have objected repeatedly to it. Message-ID: 1302460191.2441.111.ca...@havelock.liw.fi Message-ID: 20110911084518.gd22...@havelock.liw.fi Message-ID: 20110912095305.ga14...@virgil.dodds.net Lars asked contributors to open bugs on debian-policy, and patches were committed by the Policy maintainers, showing their approval to that workflow. It's fine that the Policy maintainers approve of that workflow; they are not the DEP drivers and it's not their decision. Nor is it yours. If time is pressing to change the latest version, why not asking on the debian-policy if the Delegates would have time to commit it ? In my experience they always have been very helpful. Because this is not part of policy and it's not ready to be part of policy, nor is it ready for us to use the policy process on it; therefore there is no reason to involve the policy delegates. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#633797: copyright-format: with keywords exception underspecified
On Wed, Nov 16, 2011 at 09:31:05AM +0900, Charles Plessy wrote: Le Tue, Nov 15, 2011 at 09:16:18AM +0900, Charles Plessy a écrit : Le Wed, Jul 13, 2011 at 10:21:58PM +0200, Jakub Wilk a écrit : copyright-format reads: | Exceptions and clarifications are signaled in plain text, by appending | with keywords exception to the short name. However, it is not specified how different keywords are separated. For example, should one write: License: GPL-2+ with OpenSSL and Font exception or License: GPL-2+ with OpenSSL, Font exception or maybe License: GPL-2+ with OpenSSL Font exception? I looked at how my favorite parser, config-edit, is doing with exceptions, and if I add a ‘OpenSSL and Font’ or an ‘OpenSSL, Font’ exception, it stops with error at loading… I inspected the 11,575 packages available on the Lintian Lab. 489 License statements had the word “exception” in. None of them were double exceptions. Is there a concrete example where we need to support multiple exceptions ? If not, I propose to follow and document the current practice, which is to support only one. This has the advantage that it will not be needed to implement new functions in parsers, nor to correct copyright files. I have no objection to this for 1.0, provided we at the same time clarify that if more than one exception is in use, you need to use a custom shortname instead of an ORed or ANDed list of licenses. Is there a consensus for this position? I think for future versions of the standard, it's worth covering this case even if it's only a hypothetical; but there's no reason to hold up 1.0 for something that's going to require parser changes and isn't in use anywhere. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#633797: copyright-format: with keywords exception underspecified
On Tue, Nov 15, 2011 at 09:16:18AM +0900, Charles Plessy wrote: Le Wed, Jul 13, 2011 at 10:21:58PM +0200, Jakub Wilk a écrit : copyright-format reads: | Exceptions and clarifications are signaled in plain text, by appending | with keywords exception to the short name. However, it is not specified how different keywords are separated. For example, should one write: License: GPL-2+ with OpenSSL and Font exception or License: GPL-2+ with OpenSSL, Font exception or maybe License: GPL-2+ with OpenSSL Font exception? I think that this is a good point, but I am unsure if we have the capacity to fix it before releasing version 1.0 of the format. I definitely would not object. There's no point in declaring the spec 1.0 while ambiguities like this one remain. This is in fact on the list of issues that I consider blockers for DEP5. On Mon, Nov 14, 2011 at 06:24:18PM -0600, Jonathan Nieder wrote: As a workaround, with keyword exception might work, making this GPL-2+ with OpenSSL exception with Font exception. :) Does GPL-2+ with OpenSSL and Font exceptions work (note the plural)? I would be happiest if GPL-2+ with anything worked, as free-form text. You can always say GPL-2+-with-anything as a custom license name, but the value in spelling out standardized license tags at all as part of the spec is that it allows for mechanical extraction (and eventually, automated checking of license compatibility and accuracy of license information). If it's going to be extended in a free-form manner, what's the value in partially specifying the name? One benefit, certainly, is that you can assume that GPL with foo exception(s) gives you at *least* all the same rights that the GPL does, since GPL exceptions can only grant additional permissions and not take them away. However, the history of the draft shows that people are concerned about knowing whether *specific* common exceptions are in effect, so I think the spec should include a standardized way of expressing these common exceptions, including in combination. Of the various options suggested above for combining exceptions, I have no strong preferences; I think it would be bikeshedding to spend overly long discussing the options. Does anyone else have a preferred option that we could quickly reach consensus on and enact? I have a slight preference for: GPL-2+ with OpenSSL and Font exceptions because it's both easy to parse and reads naturally in English. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#633797: copyright-format: with keywords exception underspecified
On Tue, Nov 15, 2011 at 03:16:50PM +0900, Charles Plessy wrote: SPDX uses one short name per combination of license and exception. I did not like it at the beginning as I find it inelegant, but in the end it would be simpler. With that syntax, ‘GPL-2+ with OpenSSL and Font exceptions’ would be written ‘GPL-2.0+-with-font-exception and GPL-2.0+-with-OpenSSL-exception’. This is a substantive change to the syntax, not a clarification, and as such is not on the table for consideration in DEP-5 at this time. I also disagree that this syntax offers any clarity at all. GPL-2.0+-with-font-exception and GPL-2.0+-with-OpenSSL-exception expresses that use of this code must simultaneously comply with the two named licenses. It does *not* express that the same code is simultaneously covered by two exceptions to the GPL. Nor does use of or instead of and fare any better, as that suggests that you can only make use of one license exception or the other. I would recommend against having ‘Y with X exception’ making Y compatible with X, because it would deviate with how SPDX uses exeptions. For instance, GPL-2.0-with-bison-exception does not mean that there is a special exception to use the GPL-2 with a so-called ‘bison’ license. That has not been proposed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian page at Google+
On Tue, Nov 08, 2011 at 02:30:59PM +0100, Ana Guerrero wrote: Since there seem to be some demand there (the page has 300 followers while writing these lines), I am planning to mirror there the stuff from identi.ca at least. Hum. Just my $.02, but I think that makes it significantly less useful. If I wanted to follow identi.ca, I would follow identi.ca - the value to me of G+ is that it's *not* a microblogging stream. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: trademark licenses and DFSG
On Tue, Oct 11, 2011 at 09:11:21AM +0900, Charles Plessy wrote: Le Sun, Oct 09, 2011 at 08:02:01PM +0200, Stefano Zacchiroli a écrit : My own proposal, that I submit to your consideration, is as follows: - DFSG applies to copyright license; trademark restrictions should not make a package DFSG non-free (philosophical part) - however, trademark restrictions that get in the way of usual Debian procedures should not be accepted in the Debian archive (practical part) The DFSG stem from our Social Contract, where they are introduced as a tool to determine if a work is free. We can decide that they apply to copyright licenses only, and that would leave on our archive administrators the burden of determining if a trademark license is free. No, it would not, because *Debian is not in the practice of licensing trademarks*. The controlling principle is that we are not trading on the names of the upstream works and as a result we have no need of a license - so it doesn't matter what kind of hare-brained restrictions upstreams include in their trademark licenses because we don't need a license. A trademark license is a license to use a *brand*, not a license on a work of software. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: trademark licenses and DFSG
On Sun, Oct 09, 2011 at 08:02:01PM +0200, Stefano Zacchiroli wrote: Problem statement = The question we need to answer is whether DFSG should be applied to trademark licenses or not. Our answer to this question has always been no and should continue to be so. The Debian logo --- As part of the impact analysis, we should also consider what it would happen to the trademarks that *we* own. At present, the version of our own logo with the Debian label is not DFSG-free [4]. This is unfortunate both because of the message it sends and because we cannot use the Debian official logo as part of Debian without making exceptions to DFSG (which is ridiculous either way). The reason of the non-DFSG-freeness of the Debian logo is that its *copyright* license tries to do some sort of trademark protection as part of its terms. Reifying trademark protection in a copyright license is a bad thing per se, and I've been working with SPI lawyers to fix that. The goal is to release the Debian logo under a common DFSG-free license and have a separate, new, trademark policy [5]. This is a long overdue change; I'm glad to see some movement here. Renouncing to trademark protection for Debian is another option, but it'd be equivalent to giving up Debian trademarks. I don't think that would be a wise choice. I agree. Proposal We need to decide together what to do about the presence of software with trademark restrictions in the Debian archive. It would be nice to reach consensus through simple discussion, but we can of course also decide to vote on this matter. My own proposal, that I submit to your consideration, is as follows: - DFSG applies to copyright license; trademark restrictions should not make a package DFSG non-free (philosophical part) - however, trademark restrictions that get in the way of usual Debian procedures should not be accepted in the Debian archive (practical part) What I've in mind here is stuff like having to either rebrand or ask for permission before adding a security patch or other kind of restrictions on changing code that has nothing to do with the identity of upstreams that trademarks are supposed to protect. Practically, I think the set of unacceptable restrictions should be proposed by the people who would actually have to deal with this kind of issues: security team (that might need to apply impromptu patches), release team (that might be forced to rename packages in past release upon change), ftp-masters (same reason as before), etc. Has the project received competent legal advice stating that a package name would be interpreted as infringing a trademark, and that we might have to rename it? Note that I am not talking about violating the terms of a trademark *license* here, which I maintain we generally have no reason to seek (or accept), but about whether such use infringes actual trademark rights directly. If we haven't received such advice, then I don't think there's any reason to worry about the possibility of patching a package resulting in a requirement to rename it, *unless* there are particular reasons that we believe we need a trademark license in the first place. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Question about GNOME Trademark and GNOME project packages in Debian
, especially given that this is the second major instance of a similar issue. This case is not congruous to the firefox case. In that case, there was a copyright license on the logo which enforced trademark-like restrictions which as a result did not meet the DFSG. We obviously need a free copyright license for the works that we distribute, and since we didn't have one the necessary course of action was to remove that logo from the source. And since that constituted a very visible change to the software itself, it was reasonable to question whether it should continue to be called firefox under the circumstances. For GNOME, whose logos are all distributed under free licenses, there is no such compulsion to avoid their inclusion, no matter what license GNOME offers for the trademark represented by those logos, and we should not be scared into removing them (or the GNOME name) for no reason. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Reminder: Debian FTPMaster meeting
On Thu, Mar 17, 2011 at 08:20:39AM +0100, Raphael Hertzog wrote: On Wed, 16 Mar 2011, Joerg Jaspert wrote: multi-arch implementation, see http://lists.debian.org/debian-devel/2011/02/msg00504.html On Wed, 16 Mar 2011, Steve Langasek wrote: On Wed, Mar 16, 2011 at 11:44:46PM +0100, Joerg Jaspert wrote: Compared to my last post about this meeting, we did rework our agenda a little bit, so it currently reads like the stuff I paste below. We guarantee nothing from it, but we try to at least have a few short words about each. Well, a report after the meeting might tell you more what we got from it. :) multiarch doesn't seem to be mentioned here, did it not make the cut? You missed it. See above. Oops, forgot to filter punctuation in my search ;) Thanks. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20110317172838.gc2...@virgil.dodds.net
Re: Reminder: Debian FTPMaster meeting
On Wed, Mar 16, 2011 at 11:44:46PM +0100, Joerg Jaspert wrote: Compared to my last post about this meeting, we did rework our agenda a little bit, so it currently reads like the stuff I paste below. We guarantee nothing from it, but we try to at least have a few short words about each. Well, a report after the meeting might tell you more what we got from it. :) multiarch doesn't seem to be mentioned here, did it not make the cut? http://lists.debian.org/debian-devel/2011/02/msg00556.html Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20110317053813.gd28...@virgil.dodds.net
