Re: Banning Norbert Preining from planet.d.o

[Dr. Bas Wijnen]

This entire thread makes me worry quite a bit about the current state of
Debian, so I feel the need to respond to several posts in it.

Tl;dr: Debian should be a project where everyone can feel comfortable to
contribute. That is not possible if we allow bullying to stand unchallenged.

On Wed, Mar 23, 2022 at 07:23:25AM +0100, to...@tuxteam.de wrote:
> On Tue, Mar 22, 2022 at 09:01:27PM +0100, Thomas Goirand wrote:
> In my opinion it seems better to let it be. Granted, Norbert's
> behaviour comes across as resenful, which isn't very constructive,
> but trying to respond in kind risks making things worse rather
> than better.

I understand this impulse and in my personal life, this is often what I do.
However, it is wrong, especially in an environment where more people are
involved. If someone tries to make me feel bad and I ignore it, there is not
much harm. However, if they do the same to someone else, it's different. This
is because the other victim may not be in a position to ignore it. For whatever
reason, they may not be able to mentally defend themselves as I can. So while I
might conclude "they're ignoring it, so it's probably not a real problem", that
conclusion may be incorrect. Therefore, it's up to people like me, who can
handle the abuse that may result from it, to speak out and try to stop the
behavior.

Because of this, while I'm sympathetic to your impulse of ignoring bad
behavior, that is in fact a very counterproductive thing to do.

On Wed, Mar 23, 2022 at 06:01:02PM +, Martina Ferrari wrote:
> I saw this message yesterday, and left me thinking how nobody seems too
> concerned with how Preining's actions have impacted and continue to impact
> members of this project.

Indeed. Thanks for posting this. I have not followed Norbert's interactions
with the project closely, but the things you mention here make it
overwhelmingly clear that he is indeed the abuser, not the victim.

> It is funny (not) to see the person I called an asshole back then -for
> stating publicly that he chooses to intentionally misgender transgender
> people- is still having opinions in this thread. It is all very polite, of
> course; after all, nobody really cares about the people who get hurt.

It's not entirely clear to me if Norbert was the one doing the misgendering or
someone who defended him, but I'm leaving this quoted as an example of behavior
that is extremely hurtful, and for which the victims typically aren't in a
mental state to defend themselves properly. Anyone who cares about the
wellbeing of our contributors should realize this. "This person misgendered
someone on purpose" and "someone complained about it" are not equally
offensive. On the contrary: the former is offensive and because of that the
latter is a positive thing to do.

> Debian keeps showing for anybody to see that as long as you keep your tone
> down, you will be allowed to bully, harass, and generally make others
> miserable; that nobody cares enough to stop it.

Again, thank you for posting this. I hope you're able to handle everything.
Let's all make sure that this problem goes away.

On Wed, Mar 23, 2022 at 05:07:06PM +0100, Diederik de Haas wrote:
> On woensdag 23 maart 2022 14:05:57 CET Antonio Terceiro wrote:
> > ¹ of course correlation is not causation, I am not saying the perceived
> >   growth is happening *because* of the CoC etc.
> 
> Indeed. It could also be *in spite of*.
> There's an equal amount of evidence for that: zero.

Your post suggests that until causation is proven, correlation should be
ignored. Why would you think that?

There was an assertion that we are losing lots of contributors because we
trying too hard to be nice. Instead of going "no they aren't", "yes, they are",
Antonio got the numbers that can show such an effect. I thank him for that,
this is how we want to debate among smart people. But of course those numbers
aren't purely showing one effect, so he adds a disclaimer about it. Even
better. To go from there to "those numbers mean nothing at all" is nonsense
though. They are still the best way we have to check if the assertion is true.
Even if they don't give a definitive answer, they do give an indication. That
has value. And the alternative is a fact-free opinion war, which has zero
value.

> > > Mailing lists seem to be really quiet compared to older times, traffic
> > > on IRC is also far less traffic than it used to be. Maybe
> > > communication shifted to other media or maybe DDs are more silent
> > > because they fear to be punished in some way or another for what they
> > > say.
> > 
> > I see that being thrown around a lot, yet nobody has never received any
> > real sanction in the project for giving their opinion on a topic,
> 
> Self-censorship is also a thing.
> I could say there's a correlation between self-censorship and lower ML 
> traffic, 
> but for that there's also an equal amount of evidence: zero

Yes, self censorship is the entire point here. Antonio's statement was that
it's 

Re: Debian and Non-Free Services

[Dr. Bas Wijnen]

On Thu, Sep 12, 2019 at 07:49:26PM +0200, Ansgar wrote:
> >   Subject: Free Software Needs Free Tools
> >
> >   No Debian contributor should be expected or encouraged, when working
> >   to improve Debian, to use non-free tools.
> 
> Does this include:
> 
>  - non-free firmware on Debian hardware,
>  - non-free software for interacting with hardware,
>  - non-free backup systems?

As far as I'm concerned, yes. But note that the proposal is not to say "our
users must not be allowed to use github". It's "our developers must not be
allowed to force contributors to use github".

I think that is very reasonable, at least for tools (including services) where
free alternatives are available.

> AFAIK Debian uses all of these and you are probably expected to deal
> with them when contributing to relevant parts in Debian.

You may be correct. In that case, this GR, if passed, declares that we want to
change that. Is that controversial?

> >   This includes proprietary
> >   web services.  We will ensure this, insofar as it is within Debian's
> >   collective control.
> 
> Does this include use of proprietary CDN networks, DNS services, cloud
> services (such as VMs or storage) or social network services (Twitter)?
> Again, you probably cannot avoid them when contributing to relevant
> parts of the project.

Yes, it should mean that. Again, it doesn't mean people are not allowed to use
them. It means that people who don't want to use them can still contribute to
Debian. So for example, it would not be allowed to ignore the bts and only
accept bug reports through Twitter. 

> >   For example, Vcs-Git fields in source packages must not refer to
> >   proprietary git code management systems.  Non-Debian services are
> >   acceptable here so long as they are principally Free Software.
> 
> That would just lead to packages using these to no longer including the
> Vcs-* fields...  There are some valid reasons to host packages on
> services such as GitLab or GitHub such as when they are hosted there as
> part of the upstream project and/or for better cooperation with
> upstream.
> 
> I would not like to make cooperation with upstream more complicated.

I agree with that. However, I'm not sure if it would make it harder. How does
this cooperation work, where you need your packaging to be on the same host as
upstream?

I usually download their release and work on that. It really doesn't matter
where I do that. Of course I report issues upstream in their issue tracker, but
that doesn't need to be on the host where my packaging is.

On Thu, Sep 12, 2019 at 10:19:46PM +0200, Marc Haber wrote:
> Count my vote in as a firm "No". This is going the same road as the
> "editorial changes" two decades ago, the first occasion where my
> motivation in Debian was damaged.

The problem with that GR was that at the time of voting, people did not realize
what they were deciding. With this GR that won't be the case, if people like
you explain what the problem is. So I don't believe it is a similar situation.

But please, in order to avoid the problem, elaborate on what the problem with
this proposal is.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Automatic downloading of non-free software by stuff in main

[Dr. Bas Wijnen]

On Fri, Dec 01, 2017 at 06:09:12AM +0100, Adam Borowski wrote:
> On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote:
> > Over the years, d-legal has discussed a number of packages which
> > automatically download non-free software, under some circumstances.
> > 
> > The obvious example is web browsers with extension repositories
> > containing both free and non-free software.
> > 
> > We have also recently discussed a media downloader/player which, when
> > fed a particular kind of url, will offer to automatically download a
> > proprietary binary-only protocol module to access the specified
> > proprietary web service.
> [...]
> > I would like to establish a way to prevent this.  (There are even
> > whole Debian derivatives who have as one of their primary goals,
> > preventing this.
> 
> No, those derivatives are damage.  While their hearts are in the right
> place, they cause data loss and security holes by at least making people on
> Intel and AMD machines use known-buggy microcode.

This is a different subject, though.  We had a discussion about software
supporting non-free hardware a while ago.  I'm still planning to propose a GR
for that, but have been distracted so it's taking a while.

What Ian is talking about is not "this software is non-free, but I need it
because I have hardware that won't run properly without it", but "this software
is non-free and my program from main just installs it on my computer".  Ian
didn't talk about hardware supporting software, so he didn't exclude it
explicitly, but I think we should do that.  Because with hardware you make
valid points, but they are irrelevant for pure software, such as the example of
a web browser downloading non-free add-ons.

I believe Ian's intent was to discuss the pure software problem (Ian, please
correct me if I'm wrong).  So if you want to talk about microcode and wifi
firmware, please do so in a different thread.

> Even Debian is not without fault here: for example, the ftpmasters accept
> such a blatantly non-free licence as AGPL[1] into main.

In today's digital environment, a lot of programs are moved from the user's
machine to a network service.  The purpose of the GPL is to give all downstream
users freedoms.  This can be circumvented by putting the code on a remote
server and never installing it on the user's machine, because the GPL only
talks about code that runs on the user's machine.  The AGPL fixes that problem
by requiring those hosting such programs to pass the freedoms on to their
networked users.  This is a necessary fix for a problem that didn't exist when
the GPL was originally written.

There may be some issues with the way it is written, but the fact that
networked users deserve the same rights as local users is self evident in
today's networked world.  So while you can advocate for minor modifications to
the license so that it becomes legally better, advocating against it entirely
is not reasonable IMO.

> [1]. AGPL fails FSF freedom 0: you can't reuse snippets of code from an
> AGPLed project in anything networked that has no, or cumbersome, ways to
> pass advertising statements to the user (such as, eg, an IMAP server).

The AGPL only says it must "prominently offer" an opportunity to receive the
source code.  I think it is possible to do this for example on the web site
that tells the users about the address of the server.  What "prominent" means
depends on how the service is normally used.  That's why they used such a
subjective description.

> It also fails the Dissident Test: take a blogging software with
> steganographic features, that you provide hosting for, for two classes of
> users: fellow dissidents, and public at large.  The former receive the code
> (both binaries and source), the latter do not.  Even revealing the existence
> of your changes is a serious risk for the life of you and your friends.
> Regular GPL has no such problems.

Yes, it does have these "problems" and they're the main difference between the
GPL and BSD-style licenses: the GPL requires users to have access to the source
code, so if you don't want your users to know that changes to the source were
made, you cannot let them run your code.

The AGPL closes the loophole that the GPL did not cover networked users.  But
if we take your example and run it locally (for example, make it a message
board on a multi-user machine that is used by students of a university in a
country with an oppressive regime), you have the exact same problem and with
your logic now the GPL is failing the dissident test.

I don't agree that it does.  For dissidents, just like anyone else, things are
easier without copyleft, because they are more free personally (at the cost of
the freedom of their users).  However, if they choose to host the software
without changes for the public and an extra copy with changes for fellow
dissidents, there should be no problem.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Mon, Aug 14, 2017 at 08:51:06AM -0400, Holger Levsen wrote:
> you are running this on a computer with non-free software (*). Should 
> everything
> now be in contrib?

No, I explained before that I think we should be pragmatic.

> Or can we maybe rather bury this thread?

I do not see how "you run non-free software" should imply "you cannot care
about software freedom in anything, ever".

If there is disagreement about what software freedom means, I think it is
important that we know each other's positions.  We may eventually agree to
disagree, but at the moment I don't think we understand each other yet.

If you don't care, of course feel free to ignore the thread.  But please don't
tell others that they must not talk about it.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Sun, Aug 13, 2017 at 05:28:29PM -0700, Russ Allbery wrote:
> Miles Fidelman  writes:
> 
> > Getting past all the obfuscatory count and counterpoint, there seem to
> > be two clear questions on the table:
> 
> > 1.  Given a piece of FOSS client software, that has no purpose other
> > than to interface with a proprietary back-end service (say a FOSS
> > twitter GUI), should that be considered "free software" for the purposes
> > of placement in main vs. contrib vs. non-free?  (Or alternatively, where
> > should it reside?)
> 
> > 2.  Given a piece of FOSS client software that interfaces to, among
> > other things, a proprietary back-end service (e.g., a multi-protocol
> > chat interface that includes AIM and MS Messenger among the back-ends it
> > supports), be placed in contrib or non-free, simply because its
> > description mentions those services?

Yes, thank you for this summary.  One correction: I don't think anyone claims
that mentioning a non-free service in the description is a problem.
Recommending it is a different story.

It was also mentioned somewhere (here or on -devel, I don't remember) that RMS
agreed that an ICQ client can still be free software, even if there is no free
server.  I agree with that.  But being free is not enough to be in main.  I'm
not saying that an ICQ client should be in non-free.  It should be in contrib
(if it is free software).  That does not conflict with RMS's view that it is
free software.

> The point that I think may not yet be clear enough is that if the answer
> to 2 is that such software should not be moved to contrib (as has
> historically always been the case), the answer to 1 *also* has to be that
> the software is not moved to contrib.

I don't agree that this automatically follows.  You make a good argument, but
it is still a policy choice to do one or the other.

> Because the way you get software of type 2 is that it uses a variety of
> libraries of type 1, so if those libraries are moved to contrib, the main
> software of type 2 would also have to be moved to contrib.
> 
> Writing a library specifically to interact with a non-free service is
> *good software engineering* (do one thing and do it well), and the correct
> way to implement software of type 2.  So unless you want to see all
> software of type 2 kicked out of Debian, at least libraries of type 1 also
> need to be allowed in Debian.

That depends on the reasoning for letting 2 be in main.  It was my impression
that it is a matter of convenience: ideally, we have a clear separation of free
and non-free software.  Software of type 2 would then need a plugin system and
the part interacting with the non-free service would be in contrib, while the
rest can be in main.  This is done by several programs, including the Linux
kernel.  Debian is often a driving force behind such splits, and I am proud of
that.

But before the non-free parts were removed from the main Linux binary, it was
software of type 2, and it was still in main.  With your logic,
linux-firmware-nonfree should now also be in main, because it was acceptable in
main when it was part of the kernel-image package.  That is obviously not
correct: the entire reason for splitting the package was to put it in non-free.

Following this logic, it seems logical to me that we can accept non-free
interfacing programs (and libraries) in main as a workaround for the bug that
the non-free part cannot be split yet.  However, it is a bug, it should be
fixed (when someone considers it important enough to work on it) and when it is
fixed, the plugin library should indeed move to non-free.

> I believe this would be hugely counter-productive for free software.  It
> would hurt us way more than it would hurt proprietary services.

I don't care about hurting proprietary services, so I'm also not interested in
knowing who is hurt more.  If it hurts us, we shouldn't do it.  But I disagree
that it does.  I think in the long run, making Debian free not only in terms of
what runs on the local cpu, but also what runs remotely, would be beneficial
for software freedom overall.  Especially because many services are moved to
the network, it means that local software is less and less relevant.  If we
ignore remote software for the purpose of our rules, we can soon as well not
have rules.

Thanks,
Bas

P.S: I just wrote a post on -devel explaining that I do not mean to say our
rules should apply to external software.  If that is not clear when reading
this post, please read that post for clarification.


signature.asc
Description: PGP signature

Re: Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Sat, Aug 12, 2017 at 12:07:51PM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 09:12 GMT, "Dr. Bas Wijnen" <wij...@debian.org> :
> > No, it doesn't.  2.2.1 says "None of the packages in the main archive area
> > require software outside of that area to function."  In other words, if
> > software outside of main would not exist, the program would still work.  
> > But if
> > that software wouldn't exist, the non-free service would not be available 
> > and
> > the free client would be useless.
> 
> Then, please file bugs against offending packages, severity
> serious. Otherwise, all this discussion is useless. A starting point
> could be golang-github-datadog-datadog-go and golang-google-api
> packages.

My purpose of this thread (which is a question asked elsewhere) is to find out
if there is consensus about this issue.  If there isn't, I don't want to bother
everyone with a mass bug report.  Which, as Russ pointed out, would be a pretty
large operation.

Also, I don't want to move lots of software to contrib.  I would much rather
have it fixed by removing the support for the non-free services, or by having
plugin systems that allow only the non-free-interfacing part to be in contrib.
However, that is still a large operation, so I still do not want to do a mass
bug filing unless there is consensus that it should be done.  So far, it
doesn't seem like there is consensus at all.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Sat, Aug 12, 2017 at 09:55:17AM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 07:37 GMT, "Dr. Bas Wijnen" <wij...@debian.org> :
> > Your argument seems to be:
> >
> > Debian cares about free software.
> > Therefore, Debian does not enable contrib and non-free by default.
> > Therefore, users may not see non-free related software.  This is a problem.
> > Let's fix it by pushing that software into main anyway.
> 
> No, _your_ argument is that contrib and non-free are part of Debian and
> are just a fine recipient for random software. I just emphasize the fact
> they are not part of Debian.

I agree that they are not part of Debian, but they are indeed fine as recipient
for software (free software in the case of contrib).  Debian is a
self-contained system that does not require anything outside it.  This is not
true for a client of a network service that is not packaged in main, so such a
client cannot be in main.

> My argument is that services are not software.

How do you think those services are implemented, if not as software?

> > In other words: We care about free software, therefore we should put 
> > non-free
> > (related) software in main.  What?
> 
> Strawman argument. Please, refrain from that.

If you read my message, I explained that this was what I understood your
argument to be.  Instead of accusing me of rhetorical tricks, please just point
out that I misunderstood you.

> > If you believe it is a problem that our users don't have access to the 
> > software
> > in contrib by default, then propose to fix that.  The obvious way to do that
> > would be by enabling contrib by default, not by moving software that 
> > belongs in
> > contrib into main.
> 
> Contrib cannot be enabled by default, it is not part of Debian.

So?  You just said that there is no problem whatsoever with Debian packages
using non-free services, which I hope we agree are not a part of Debian either?
Isn't contrib just a network service?

> It's an additional service using Debian infrastructure. Policy is quite clear
> about that.

Yes, and your position is that programs using additional services outside of
Debian can be in main.  So how is this a problem for you?

To be clear: I like to ship main-only by default, but I would understand if
contrib was enabled by default and I don't think it would be against the SC,
DFSG, or Policy.

> And honestly, I don't have to do a thing. Nothing will change. Free
> software using "non-free services" will stay in main because they meet
> the proper requirements (policy 2.2.1).

No, it doesn't.  2.2.1 says "None of the packages in the main archive area
require software outside of that area to function."  In other words, if
software outside of main would not exist, the program would still work.  But if
that software wouldn't exist, the non-free service would not be available and
the free client would be useless.

> >> Debian is about free software. There is nothing in DFSG about "free
> >> services". How do you know if a service is implemented with free
> >> software or not? Amazon S3 could be free software, but only distributed
> >> internally at Amazon.
> >
> > They can be, but that is irrelevant to this discussion.  There is no 
> > question
> > that the client is free software.  If the server is not packaged in main, 
> > that
> > means this free client software belongs in contrib.  Whether that is 
> > because it
> > is non-free or for some other reason does not matter.  That is, unless you 
> > are
> > claiming that their service is not "software".  Are you?
> 
> Yes, I am! They are services. Even the FSF acknowledges they are
> different. They have created the AGPL for that.

They have created the AGPL to close a loophole, namely that it was possible to
move a program into the cloud and thereby the users lost their freedoms.  The
idea of copyleft is to guarantee those freedoms to downstream recipients and
this trick made that impossible.  So the AGPL says "if you access software over
a network, you're still considered a user and need to receive all the rights".
In other words, the AGPL is created specifically _because_ they acknowledge
that a network service is also software.

On Sat, Aug 12, 2017 at 10:06:40AM +0200, Christian Seiler wrote:
> Because it's so fun, let me play devil's advocate for a bit:

Sure. :)

> On 08/12/2017 08:29 AM, Dr. Bas Wijnen wrote:
> > No.  The question is not "is there non-free software that the program can 
> > work
> > with?"  That would be much too broad, and it would make anything that 
> > touches
> > the network non-free.  Instead, the question is "is non-free software 
> > required
&

Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Sat, Aug 12, 2017 at 08:55:01AM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 06:29 GMT, "Dr. Bas Wijnen" <wij...@debian.org> :
> 
> > That is a disservice to our users.  While for many users this is true, those
> > users will have contrib (and probably non-free) enabled in their 
> > sources.list.
> > So moving the package to contrib doesn't change anything for them.  The only
> > people who see a difference are the ones who asked not to see this kind of
> > software, and they will no longer see it.  That is a great outcome, not
> > something to get upset about.
> 
> By default, contrib and non-free repositories are not enabled. They are
> also unsupported from the security team. They are not part of
> Debian. They are an additional service provided to users requesting it
> specifically.

Your argument seems to be:

Debian cares about free software.
Therefore, Debian does not enable contrib and non-free by default.
Therefore, users may not see non-free related software.  This is a problem.
Let's fix it by pushing that software into main anyway.

In other words: We care about free software, therefore we should put non-free
(related) software in main.  What?

If you believe it is a problem that our users don't have access to the software
in contrib by default, then propose to fix that.  The obvious way to do that
would be by enabling contrib by default, not by moving software that belongs in
contrib into main.

Another solution for those users is to install one of our many derivatives,
most of which don't care about non-free software like we do.

> Debian is about free software. There is nothing in DFSG about "free
> services". How do you know if a service is implemented with free
> software or not? Amazon S3 could be free software, but only distributed
> internally at Amazon.

They can be, but that is irrelevant to this discussion.  There is no question
that the client is free software.  If the server is not packaged in main, that
means this free client software belongs in contrib.  Whether that is because it
is non-free or for some other reason does not matter.  That is, unless you are
claiming that their service is not "software".  Are you?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

First of all, a clarification: This post (like most in this thread) is
primarily about Debian's philosophy, not about certspotter (but I do talk about
that at the end as well).  For this reason, I'm not CC'ing the bug.

On Fri, Aug 11, 2017 at 05:26:58PM -0400, Faidon Liambotis wrote:
> On Fri, Aug 11, 2017 at 08:03:09AM -0400, Wouter Verhelst wrote:
> > If a free software implementation of the remote service exists that a
> > package can work with, then it can remain in main. If not, it cannot.
> 
> There are no free software server-side implementation of e.g. the ICQ
> protocol, as far as I know, but multiple client-side implementations in
> main.

That is a bug as far as I'm concerned; a client designed purely (or mostly) for
such a non-free service should not be in main.

> For that matter, there is no free software server-side implementation of
> QUIC, so I guess by that rule, Chromium should be in contrib as well.

No.  The question is not "is there non-free software that the program can work
with?"  That would be much too broad, and it would make anything that touches
the network non-free.  Instead, the question is "is non-free software required
for major functionality of the program?"  With an ICQ client, it is.  With a
web browser, it's not.

Also note that the reason we split our free packages between main and contrib
is a service to our users: those who do not want to depend on non-free software
can disable contrib.  Not showing an ICQ client to those users is a service to
them, not a burden: it's what they ask for when putting only main in their
sources.list.

Now if an upstream or a maintainer gets upset about software being moved from
main to contrib, that is a sign that they (like Debian) would prefer to live in
a world where all software is free.  Because of that, they don't want to
support non-free software, which means (if all dependencies are packaged) that
their software should be in main.  So when people tell them "your software
belongs in contrib", especially if the reason is that it requires non-free
software (as opposed to non-packaged software), it hurts their pride.

I think that is a good thing: it should be an incentive for them to get rid of
the dependency.  However, I've seen on multiple occasions that the response is
to deny the problem and to push for keeping the software in main anyway,
claiming something to the effect of "it's more important for our users that
they have access to this software than it is to have a completely free system".

That is a disservice to our users.  While for many users this is true, those
users will have contrib (and probably non-free) enabled in their sources.list.
So moving the package to contrib doesn't change anything for them.  The only
people who see a difference are the ones who asked not to see this kind of
software, and they will no longer see it.  That is a great outcome, not
something to get upset about.

> As for certspotter [...]

It has become clear a while ago (to me anyway) that certspotter belongs in
main.  From the start, the bug report was about the description, not about the
program itself and thus the fix would be to change that, not to move the
package to contrib.  I agree with the bug that descriptions of Debian packages
(even those in non-free) should not advertise non-free software or services.
If there is a free option (and there must be for it to be in main) that should
be mentioned as the recommended way to use the program.  If there also is a
non-free option, it can be mentioned as an alternative, especially if many
users are expected to know about it.  If it is unknown to most users, I think
it should be left out.

> the conversation has derailed quite a bit [...] Not cool.

Actually, that is "cool".  Jonas made the larger community aware of the issue,
which means we can discuss it.  On our mailing lists, the tangents this went to
are not off-topic.  Perhaps the bug should be removed from the Cc, but that's a
minor issue.

> - People called SSLMate "non-free" and objected to the certspotter
> description pointing to it.

No, pointing does not need to be a problem.  Recommending it (in effect
advertising for it) is.

> - I don't have any personal or business connection to SSLMate or
>   certspotter, other than using the software and maintaining the
>   package. I haven't communicated with my upstream about this issue
>   either and my comment on the bug report are just my views. I just want
>   to be fair to a nice upstream, who has graciously released part of
>   their business as free (as in speech and as in beer) software, for
>   anyone to use instead of using their service.

I agree that it is unfortunate that people get so upset over discussions like
this one, and I appreciate that you keep it away from upstream, so they are not
bothered with it; this has nothing to do with them.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

On Tue, Aug 08, 2017 at 07:58:06AM -0700, Don Armstrong wrote:
> On Mon, 07 Aug 2017, Dr. Bas Wijnen wrote:
> > Ah, that's good then! Still, I think its description has the same
> > problem as certspotter, namely that it recommends the use of a
> > non-free service. In Debian, I would prefer to see a recommendation
> > for the free alternative, while the non-free alternative may be
> > mentioned (or not, depending on what users need).
> 
> An important counterpoint is that the long description helps with the
> discoverability of a package. Mentioning a famous non-free service helps
> users discover the package and also notice that there are free
> alternatives.

Yes, I agree.  If the non-free service is famous, I think it makes sense to
mention it.  However, even in that case I think we should still recommend the
free option(s).

If the free options are limited to a point where it does not make sense to
recommend them to our users, that means the non-free service should be
recommended and IMO that means the program should be in contrib.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

On Tue, Aug 08, 2017 at 02:25:51AM +0800, Shengjing Zhu wrote:
> The description of s3cmd is outdated. It's *not* useless without AWS.
> It can be used with self-hosted S3 protocol compatible service, such
> as Ceph RGW, minio[1]. Both are free softwares, and Ceph is in our
> main archive.

Ah, that's good then!  Still, I think its description has the same problem as
certspotter, namely that it recommends the use of a non-free service.  In
Debian, I would prefer to see a recommendation for the free alternative, while
the non-free alternative may be mentioned (or not, depending on what users
need).

Thanks,
Bas


signature.asc
Description: PGP signature

Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

On Sun, Aug 06, 2017 at 02:15:17PM +0200, Vincent Bernat wrote:
>  ❦  4 août 2017 20:03 +0200, Jonas Smedegaard  :
> > No, at worst this is misuse of Debian ressources for commercial gain - 
> > i.e. using long description field for advertising a non-free service.
> 
> We have all kind of software advertising non-free services. Search for
> "Google" or "Amazon". The comparison is even unfair as the service
> advertised here is available as free software (not the case for most
> services from Amazon and Google we advertise).

If other packages are worse, that means they should be fixed, not that this
should be allowed.

> Example: [s3cmd]

How is this not in contrib?  This software is useless without the non-free
service (which is also software, and it is not in main) from Amazon.  Policy
even mentions as an example for things in contrib: wrapper packages or other
sorts of free accessories for non-free programs.  That's exactly what this is.

I didn't know that this was in main, and I expect most others to not know
either.  But I don't think they should be.  I wouldn't expect this to be
controversial, but it seems that it is, given that you suggest they obviously
belong in main?

To be clear: the sort of software (of this type) I expect in main is like
mumble: it connects to a server, and you can connect to a commercially hosted
server if you want to, but you can also run your own server, because it's free
software.  If the mumble server would not be free, and the only way to use the
client was to connect to a commercial server, mumble should not be in main.

As I wrote, I expected there to be consensus on this.  Am I incorrect about
that?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Aug 05, 2017 at 09:38:45AM -0400, Paul Wise wrote:
> > No, at worst this is misuse of Debian resources for commercial gain -
> > i.e. using long description field for advertising a non-free service.
> 
> I got the impression that Faidon is not involved with SSLMate so this
> and the relevant DMUP clause does not seem to apply in this case.

While perhaps not strictly against the letter of any of our rules, that doesn't
make it any less an advertisement for a non-free service and that certainly is
against the spirit.  Similarly to not adding a Recommends: from a package in
main to one in non-free, we should not recommend non-free services either IMO.
I don't think that is controversial?

I would make an exception for source files from upstream.  If they want to
advertise a non-free service, they can do that.  For Debian, IMO we should
remove such advertisements as part of packaging the software.  That means it
should not be in the binary package at all.

> In this case, the advertisement is also present on the upstream github
> page, via the README, which is also in the Debian package, so removing
> it from the Debian package description will not remove the
> advertisement entirely. Personally I'd prefer to not have it present
> in any of the locations, but leaving it in the README in Debian and
> upstream seems like a reasonable compromise.

Agreed; I would remove it from the program itself or its upstream-written
manpage if it would have been there (and of course it should definitely not be
in a manpage created by a maintainer), and while removing it from the source
(or its documentation) would be nice, I think it's acceptable to leave it
there.

Then again, it's similar to having non-free software in a release tarball, and
we do repackage the source for that.  So perhaps that would be the preferred
way to handle it.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZhr4gAAoJEJzRfVgHwHE6jTwQAJGgJL0vKRlcGj70YhjoDDrR
/pQiDALVRq0wiQqx+9MNy0px2OeA89TgTtfvm6fh+ibSI+9cC/+FO8GruqGPrxjK
NKgyUVUvVNqvSupIzEpbnLQE1QVzi31dvYVzir+lLjJB8sN4oUbNOtTjUWlO4rhT
XH8ixzLADqT3VWC30TPUoE8UJ+Nf82eHF67h/4sEwrZWMZgfVfqPR3qTAF0AZsnS
ezOtkHl8a3E/QlxOGeMZJ/g2zLVlcRnXU7svEAWdhuSZUT7D9t9I3m5KGwwE1ZLj
Kzmlly59DdhyWkqsvWdpifo97avQXlIna4MJeGZW9U8JRdw0V0taWxv1oZ1auprA
Cm3hWi/X8DTtvUwOVqEW4aarvvC26dk1uyIz7Z+qHqKF5amir7HxfG81cGNiryyz
bBjp6MJAYnnfUeYnn1ZM4qlnJFPNqYSUgoZ/S0uLtOwZGTjaBQsqwewPWKr5pON9
hlG+at1u6wcxTfYJ3guzhB04bp4cISL5Ze3WZwXH3nmTPJi5Rnd7dXaQvkwdzziJ
DVcGjZqb3G1LQKABpWmwCxGEXiEgfjki/DmlSDaonX0SUN1lvtfsQ9COcp7kczU1
gb+jcJCR3uerLHvNnmKT8RowQe7j4AHpFGDJuPKid1B+fdYqpNO8/yqE7kScpI97
82ed9JaRCIbFYfXoL+YT
=YnvG
-END PGP SIGNATURE-

Re: Debian contributor Register of Interests

[Dr. Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, May 09, 2017 at 11:51:23PM +, Scott Kitterman wrote:
> On May 9, 2017 8:09:28 AM EDT, Ian Jackson  
> wrote:
> >Jonathan Dowland   wrote:
> >> However in the interests of transparency I feel that a voluntary,
> >> opt-in "Register of Interests" is a good idea for the project. I feel
> >> that such a list (populated) would demonstrate the transparency and
> >> openness that are part of our project's values.
> >
> >I think this is a good idea.
> 
> I think it's a horrible idea.  One of the major draws of Debian is that we
> are all here for our own reasons.  I don't judge your motivations and you
> don't judge nine.

It's voluntary, so you decide what you want to share.  If you don't want to
share anything, that's fine.

> If this became a requirement, I'd have to terminate my relationship with
> Debian.  These are frankly none of anyone's business.  

Nobody is suggesting that it would be a requirement.  But I disagree that we're
not allowed to know your motivations.  The NM process spends considerable time
to check that applicants agree with the project's philosophy.  If they do, we
can conclude that this will motivate them to work on Debian.  While also having
other motives is perfectly fine, we require people to have at least those
motives before we let them join the project.

> I've packaged software because a project I was being paid to work on needed
> it and I was able to convince them it made sense to put it in the Debian
> archive.

That's great, and as far as I'm concerned, just disclosing that you have been
paid for certain packages would be nice (but again, not doing it is also fine).
Whether or not it's relevant to mention who's paying is up to you.  I can
imagine that some companies would like to be mentioned, because they can use
that to show they are favorable to free software.  But if they don't wan't to
be mentioned, then don't mention them.

> If there were a case where I had an actual conflict of interest (e.g.
> recommending Debian spend funds with an organization that I had a financial
> interest in), that should be disclosed.  That's oddly missing from the list.

That's a good point, and while I agree it should be on the list, I don't think
it will have the effect you expect: this list is voluntary and therefore
incomplete.  People who intentionally misbehave aren't going to declare their
conflict of interest.  They wouldn't do that if they had to, either.

Finally, I'm not sure how useful this list would be, but I don't see a problem
in setting it up.  If someone makes good use of it, great.  If not, nothing is
lost.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZEu4bAAoJEJzRfVgHwHE6bZAP/jm7P7v9kEazuuiQaUKnpMFc
yLW0Es6IalXmQVNJ/AHe4rwDMuC28CppECEejJVt4SiHkUclYMt++QzUWHLmNrCf
WraVuUGh27SMpnlacC0AxyDLXTtTGHHeA/0dwS/C4UHynRwTyVgIjuwwapwbofGi
IJqcUQlnAiVO7mzCLSZUTyEwxtY6kRjBx8QJ/0vd8lZ9+uh4nPtmq4+m3P0kziTb
A6vrTnJwUjLWbPhBsEbVtnTDcCK+fNcnNMjbXJYWIo8a13pJvZu6krtXGgoWLxmE
zImwySagYZC1XIxis1AV6exLYWCmHdJYvbvaBFk7Y2UielPntOV3ps+AflZmAoXX
Cy2+gAJAR8X5bzEqluHwvqA5V2YSMeDv6BKYBtUdoq3BSc7NcmfdTGXMCIkwrGPC
ylvlhMck015f/TW6BeqZOVeyV02/0zZRPLAZUAbB2dhV1c8CyctVnRCrZcPPQx1s
5F9eqlHqFQgLoVL/grLFYUYWnGbixQ4++Vy79ENV1GngvA7h9XJ5wNnI3owUgBYA
BuEJSljBj6YudqIrzO4QPwuMlsv2BaiI2c7U9WcvmbJnfbS2iMwHcfhPRbuI+DF4
xqb7cuvulHUZxrc2HCqktdg7GSfqFTaCPVDYZAvwakvvXThA9lUFYdjHDo/HaQX8
9Bo8P6pq3YEs6vqtABvC
=Fmz0
-END PGP SIGNATURE-

Re: GR: Declassifying debian-private: second call for votes

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks Ian, for summarizing the options.  I have a slight disagreement with
your interpretation though.

On Mon, Oct 17, 2016 at 02:16:15PM +0100, Ian Jackson wrote:
> I support both Option 2 ("Acknowledge difficulty", my proposal) and
> Option 3 ("Remain private", Iain's proposal).  I firmly oppose
> Option 1 ("Repeal previous GR", Gunnar's).
> 
> I think Option 1 is quite bad.  I will rank option 1 below the FD (ie
> the status quo).  I recommend everyone else do so.

I don't.  While I agree with your criticism that option 1 isn't good, I believe
it is still better to repeal the 2005 GR than to keep it around.  Just
repealing the GR doesn't change anything in practice (and that would be
unfortunate), but it does clean up some junk, so IMO it's still better than FD.

Personally, I want -private to be a private channel.  That means I voted for
option 3.  Under this proposal, posts can still be made public if all
participants to the thread agree to it.  As I see it, something like tagging
each message with an embargo date is explicit agreement, so such a method would
still be possible when this option wins.

As for a rebuttal of option 2: people who post to -private expect their posts
to be private.  I want that to be true.  Option 2 allows the listmasters to
come up with a plan to declassify some posts without the authors explicitly
consenting to it.  I believe that to be dangerous for two reasons:

1. It makes the list less safe to post on.  I want us to have a channel where
   we don't need to worry about things being made public.  Adding rules like
   "if you didn't say the magic words, you're in danger" means we need to be
   more careful when posting, and that is bad, IMO.

2. I don't think the listmasters should take the burden.  Now that I think of
   it, it really seems like it keeps the 2005 GR, but instead of saying "anyone
   can do it", it says "the listmasters can do it".  They could have done it
   before and didn't, I have no reason to expect them to do it now.  If I were
   them, I would also not want this extra job, but I haven't heard them
   speaking out, so perhaps they do.

> When this GR is out of the way, I think some of those contributors who
> care a lot about improving our transparency will want to revisit this
> issue.

I think they will no matter what the outcome is.  They were asked to provide an
option for this ballot, but unfortunately no such option was proposed.

> I think all of these are quite reasonable points of view; and without
> a clear statement from the GR about where the majority of the
> projects' opinion lies, who is to say that these contributors are
> wrong ?

This GR would still give some information about that.  If option 1 wins, but FD
is not next (and especially if option 3 is above option 2), I believe it means
"we don't want to make formal statements about it, but this is how we feel".

> The main difference [between options 2 and 3] is that Option 3 would make it
> impossible to invent, or experiment with, new ways of handling -private in
> the future.

No, I disagree.  Ways that include explicit consent of all authors can be
implemented under those rules.  For publishing posts where explicit consent
cannot be obtained, a new GR would be required.  I believe that is reasonable.
Consent is normally easy to obtain.  If it's not (for example because the
person has died) and the thread is of great value, a GR does not sound like an
unreasonable requirement to me.

> That would be a shame.  There are some threads on -private which I think the
> participants would be quite happy to see declassified at an appropriate time
> (for example ones discussing security vulnerabilities).

If the participants all want to declassify a thread, they can under every
option on the ballot.

> Several people have suggested forms of subject-line tagging, for example,
> which might make that possible, while still allowing people to post messages
> which will never be disclosed.

Option 3 allows for this, as long as the tag is an opt-in for disclosure; it
does not allow implicit consent by not using a tag.

> If you feel that benefits of possible improvements to the transparency of
> -private are negligible, or that they are outweighed by the risk of madness
> on the part of listmaster, or even by the necessary discussions (arguments)
> about the shape of such a scheme, then you should rank 3 ahead of 2.

Just to add here: I have full confidence in the listmasters and believe they
would not abuse their powers that option 2 gives them.  But that doesn't mean I
think they need those powers.

I haven't heard anyone say they don't trust listmasters, so I'm not sure if
that is even true for one voter.  This doesn't seem to be something that needs
to be considered.

> I think people who are very keen on transparency should vote
> along with me,
>   2 > 3 > FD > 1

I think they should have proposed an amendment. ;)

But now that they 

Re: third-party packages adding apt sources

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 19, 2016 at 07:15:01PM +0200, Daniel Pocock wrote:
> Another thing comes to mind: making sure that even if the user
> explicitly allows some other repository, they are protected from package
> updates that come along and replace other things like apt itself, libc,
> bash, gnupg, ...

I don't think we want to prevent that.  If they want to install a package that
does that, they can.  However, I think it is reasonable to warn them that they
should get ready for trouble when installing a package that isn't from Debian,
and especially if they install a new entry into sources.list from an external
source.

I don't see how to technically do such a thing though; the problem is that
these kind of upstreams often don't care about our (or their user's) systems
and will inject any code in their package that makes the warnings go away.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPfugAAoJEJzRfVgHwHE61mcQAKQzjwht59J73zievxLTlqoz
QNMnmorJJb5vvx1PDwJzfqqL4rqRPu5/h9wiHjYhi+O3YM2J8W4phKxyMNIDYR1R
p+BA1CwSUuGX3/4je1QWaNpHa6IpgU9HxlUtrLNnjhJvtAuRR4PXfv15tPxsGgxi
AT5770XMSuCjNSehpC5nhp2l9HFiaRnaTa8tIENf6Bj1NrXrH/Em2/3CKbZiTkTf
S5C0IHWPTJyIYGqRALub+DiVvYd/d2ZNdFAwRW3/8nyJeBLwEkQ9BO8mNOdBHZWF
Fbvi0WJ5bBo1mcIVc9vO/4QvrFGPqxXYo8Sf+dI2O/NmzKdQ6XXwcy30HL8R/DhD
gZzhOJLnJFmUTpvqUAv1ywt9mfqNE4ed7/9ccN+4nTVHNSbxqJZyEimIi6x7dZop
dYZvdjoDgHRBFG7cBaGGH0Dqb+r0fSkP05Foxxy3ShITMzYQRPDzRPmxRxaU6ojB
Y5+GLQ3wlEMmiNsK34y1pQcJYKI5B7d+LYS1B/K5/Enkv7Z+4n8CX2AHtRMDmpHt
wQYKKaHjOktGZQonE1fF0vb4WE4otoidAyyN0jnlQDlq9aTp4OHDFcx5o8u6ppgG
LmKw7YTosFwzd37kHmH7icwvXiPHwIvHwR+9Vt/0wra/juD9Xktom2TtuA02MwIY
nPAD/aVlO95tD43+9EQP
=54DY
-END PGP SIGNATURE-

Re: third-party packages adding apt sources

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, May 19, 2016 at 11:46:53AM -0400, Paul Tagliamonte wrote:
> [cc'ing devel, since this is a rant that involves technical topics, and
>  god knows I only go on so many rants a year these days]

You didn't actually do this.

> > Sometimes there is good reason their
> > package doesn't belong in Debian but sometimes it is more about inertia
> > in Debian or the upstream isn't aware about backports and thinks their
> > package will be stuck at a particular version forever
> 
> Frankly, I have a hell of a lot of sympathy for this.

So do I, but I disagree with your solution.  Here's how I see it:

Debian stable is for users who want a rock solid system.  It is out of date by
the nature of how it is built.  Users who want to get the newest versions of
their software should not be running stable; testing is probably better for
them.

When programs get packaged outside of unstable, we should look at why that
happens, and try to convince the packager to do it inside Debian instead.
(This convincing may take the form of adding features to our system that solve
their problems.)

When users or upstreams complain that the version in stable isn't up to date,
we should explain to the users that they probably want to use testing.  If this
is a common problem for upstreams, our user documentation about this is not
sufficiently clear.

When users want to run stable with one or two packages cherry-picked from
backports, that is something which we may want to make easier for them.

> Backports are a whole thing. People have to be actively aware of them.
> Users have to be told to add a new thing in the sources by hand, and
> install something explicitly. It's calories, and explaining a Debian
> process to a user isn't fun. Why would upstreams want to do this?

Agreed, we should make this easier; allow DDs and the package uploader to
trigger building a backport for any package that is in testing by sending an
e-mail, perhaps?

And aside from that, I agree that it should be easier to install a system that
includes backports in the sources.list.

> My claim, as I'll outline below, is, if the upstream wants to give the
> user an up-to-date software package, and they have to teach them how to
> add a new archive, they'll give them an archive *they control*, because
> they're now on the hook for delivering through that channel. Upstream
> wants to spend as little time as they can with this, so they make it
> easy - they make a deb.

Yes.  I do this myself for some experimental packages that I don't consider
ready for the general public yet.  That is IMO a valid reason for having a
private repository.  "Doing it right is too hard" is not; that is something we
should fix.

> Backports are present when a package is in testing, and backports are a
> single channel. Backports are not for upstream's releases, whenever they
> want to ship a thing.

If we make it easy for them to become DDs or DMs and for uploaders to trigger
backports builds, backports can be what upstream wants.

> We have zero procedure in place for the following:
> 
>   - Totally unsupported very old version of ${FOO} in stable, maintainer
> isn't patching bugs, bugs are going to upstream, and upstream is
> annoyed Debian has out of date, perhaps insecure thing X.

Yes, this is a different problem.  We may want to shield upstream from
bugreports for those packages somehow.

IMO it would be good to recommend our users to file all bugs with us, and leave
it to the maintainer to pass them to upstream.  I have upstreams that follow
our bug tracker, which is great.  But if they don't, it should be up to me to
decide whether the report is worth their time.

>   - Leaf package ${BAR} has a robust upstream community, where releases
> are very well tested, with a mature stable/unstable release cycle.
> Our stable release freeze was off by a few months, so we've been
> shipping their 'oldstable' in our 'stable' for years. The
> maintainers are annoyed we don't use the latest stable in our
> stable.

If the bugreports go through us, they shouldn't have a problem with this.  It
is up to the users to choose who they trust.  If they trust upstream not to
break things (which for some upstreams is totally justified, but for others it
isn't), they can get the new package from backports (assuming that we made that
easy, so the new version is in there).  If they only trust us, they use the
older version and there is nothing wrong with that.  If upstream doesn't want
that to happen, tough luck.  It's our job to give users what they want, not to
force onto them what upstream wants.

> Largely, I think the first situation is a common one that our culture
> has forced people to group-think "Well, that's bad and the system is
> working as intended". We can't let software change on our stable
> installs, so this situation is bad, but the intent of stable.

I think it is the intent of stable, and it's good.  

Re: What it means to be Debian

[Bas Wijnen]

On Wed, Jun 17, 2015 at 10:47:09PM +0500, Andrey Rahmatullin wrote:
 On Wed, Jun 17, 2015 at 03:59:57PM +0200, Bas Wijnen wrote:
  The above has nothing to do with beliefs.  Beliefs are about people who 
  believe
  that using non-free services is better for some ethical reason.
 Do such people exist or that's a straw man?

I'm not sure if they do.  I know Microsoft tries to convince people of this
(but I don't think they believe it themselves), and I suppose they succeed
sometimes.

  So I agree with the illness statement (although I don't think illness is a
  good word for it): if people (believe they) need non-free software, we 
  should
  try to make free alternatives better. 
 Yes, we should, instead of preaching and scolding.

I disagree that preaching is always bad.  I would like a healthy balance of
trying to convince people of our position (that's preaching) and working on the
technical side of it.

  None of this means we should tell people they can't use non-free software, 
  but
  it may mean suggesting free alternatives (as was done in the post that 
  started
  this discussion).
 I'll quote the relevant part of the post that started this discussion:

Oh, I missed that.  I saw a different mail with a friendly suggestion that
another platform would probably be more successful, including a suggestion.  I
thought that started this, but I was wrong about that.

I agree that the part you quoted is not helpful.

 No free alternative was suggested here. Not to mention insecure and
 untrusted which can probably be classified as FUD

That depends who you want to trust.  If you don't like the NSA, you definitely
shouldn't send your data to Google.  Whether or not those with access are
trusted is a personal issue.

  The problem with services such as Google docs and YouTube is that the site
  owner allows the service provider to violate the privacy of the visitors.  
  This
  shouldn't be a decision that the site owner is allowed to make.
 This, of course, has nothing to do with four freedoms or with your
 favorite definition of free.

It is.  Privacy violations do not pass the
https://wiki.debian.org/DissidentTest .  Services that violate privacy are by
definition not free.  (Even though the DFSG doesn't seem to have anything that
says so, but that's why they're guidelines, I suppose; it's all about the
spirit, not the letter.)

Thanks,
Bas


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150617185951.gl4...@fmf.nl

Re: piece of mind (Re: Moderated posts?)

[Bas Wijnen]

[Moving this to -project, where it belongs; please follow up only
there, not on -user or -devel.]

On Sun, Oct 12, 2014 at 06:18:01PM +0200, lee wrote:
 Why doesn't Debian just do a GR on this issue?

Because for a GR, a member of Debian has to request it and it needs to
be seconded by at least 5 other members (constitution 4.2.1, 4.2.7).
This has not happened.

 It would be interesting to see what the devs/maintainers would vote for,
 and it might give everyone quite a bit a of re-assurance and
 piece-of-mind.

Given that there have not been 6 members asking for this vote, I don't
see a lot of unrest.

 Considering that the users are Debians' priority, couldn't this issue be
 a case in which significant concerns from/of the users about an issue
 might initiate a GR?

No. Debian is a very elitist organization.  The members decide what to
do, and nobody else does.  As a whole we rule over our users with
enlightened absolutism.  The main difference with rulers of countries is
that our users can go away more easily. ;-)

Debian is extremely democratic for its members, but it is utterly
undemocratic for its users.  And there's nothing wrong with that, IMO.

 Wouldn't it speak loudly for Debian and its ways and for what it
 stands for, or used to stand for, if it was established procedure that
 issues arising significant concerns amongst the users can lead to a
 GR?

I'll speak for myself here: I don't really care about the init system.
I am unhappy with the emotions that this debate is causing, but I'm not
very interested in the technical parts.  From what I see on the mailing
lists, it seems that a few users are very unhappy and they keep bringing
this up.  But if this would be a big issue for many people, then there
should be no problem finding 6 members to start a GR (our members are
users, too).  That still hasn't happened, so I conclude that it isn't a
big issue.

 I'm sure we could find quite a few supporters for having a GR amongst
 the users (here).  And after all, we're all kinda stuck in the same
 boat.  A GR might have the potential to make the gap between users and
 devs/maintainers a lot smaller.  Otherwise, this gap will only continue
 to become wider and wider.

There are many members.  If you can't manage to convince 6 of them, we
don't consider it a big issue.  You may disagree, but that's Debian's
rules.

Thanks,
Bas


signature.asc
Description: Digital signature

Re: Can CC BY 2.0 be upgraded to 3.0 ?

[Bas Wijnen]

Ok, I'm not sure how I could not see that you meant this before.  I understand
the point now.  Thanks for the explanation.

I still don't understand the problem, however.  With clause 4b, I can include
any significant piece of code to the work, thereby creating a derivative work,
which I can then relicense under CC BY 3.0.  After doing that, I can modify
that work again by removing the code.  Every step should be fine, and the
result is that I relicensed the code of the original work as CC BY 3.0.

It would seem to me that the fact that this is legally possible means that we
don't actually have to do those steps (who can check if we did, anyway?), and
relicensing is simply allowed.

Then again, lawyers are weird, so I may be wrong.

Thanks,
Bas

On Sun, Sep 15, 2013 at 09:04:20AM -0700, Russ Allbery wrote:
 Tollef Fog Heen tfh...@err.no writes:
 
  No.
 
#! /bin/sh
echo hello world
 
  is not a work.  It is not copyrightable.  It does not bring anything new
  and original into the world.  Norwegian copyright law talks about «work
  threshold» as in a bar you need to clear for something to be
  copyrightable.
 
  I believe this is what Russ is talking about.  (Russ, please correct me
  if I'm wrong here.)
 
 Correct, that's what I'm getting at, but I ran out of words to try to find
 a good way to explain it.
 
 Maybe an analogy works better.  Suppose that I have a hugely complex Perl
 program.  I modify the first line of that Perl program from
 #!/usr/bin/perl to #!/usr/local/bin/perl.  That modification itself is not
 copyrightable.  It doesn't contain any creative or original work in the
 sense of copyright law.
 
 Is the result a derivative work?
 
 My argument, and I think Paul's, is that it's not a *derivative* work.
 It's still the *original* work, with a trivial modification.  The word
 derivative is defined fairly uniformly in the legal bits I was reading
 as being a transformation, performance, or other substantive modification
 of an original work that adds original creative content or interpretation.
 I believe that means that, to be a derivative work, it has to bring new
 copyrightable material to the table, not just trivial changes.
 
 Another analogy: a novel is clearly a creative, original work.  If I take
 that novel and repaginate it mechanically, is that a derivative work of
 the original novel?  Or is it just the same novel, repaginated?
 
 Normally this doesn't matter at all, since all normal free software
 licenses give people all of the same rights on the original work as on
 derivative works (except that some additional requirements may be placed
 on derivative works, such as documentation of changes).  However, the
 CC-BY-2.0 license is fairly unique in that you can do things with
 derivative works that you're not (at least obviously) allowed to do with
 the original work.
 
 Another general principle of law, as I understand it, is that there is a
 bias, in interpreting contracts, towards having all the words of the
 contract mean something.  In other words, one should generally assume word
 choice is for a reason.  It would have been easy for CC-BY-2.0 to let you
 relicense the original work or any derivative work, but that's not what
 the license said.  That seems to imply that some distinction was being
 drawn, and if the original work is trivially also a derivative work, that
 destroys that distinction.
 
 -- 
 Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/
 
 
 --
 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/87vc22dqbf@windlord.stanford.edu
 

-- 
/** mastermind. input 4 numbers 0-5. output right.in the right place **/

 main(){int  c[4]   ,x=3  ,l=getpid()  ,i;;   for(  srand(l);c[  x]=-   rand
()%6 ,x--   ;);;  for( ;44   x;){  char a[9] ,*p=
 %.1f\n,   b[9];x=i=0;  gets(a);for   (l=4 ;l--   ;)x+=-(a[l]  -=48)==
   (b[l  ]=c[   l]);  ;for   (l=0;16i;l =++i %4)x
+=(b[i/4]+   a[l]   ?0:(  a[l]=b[i/4] =10)) ;printf(p,x  *.1)   ;};}

/** This signature should be viewed in a monospaced font, e.g. courier.  **/


-- 
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/20130915170113.gj21...@fmf.nl

Re: Can CC BY 2.0 be upgraded to 3.0 ?

[Bas Wijnen]

On Fri, Sep 13, 2013 at 01:37:36PM -0700, Russ Allbery wrote:
 Paul Tagliamonte paul...@debian.org writes:
  On Fri, Sep 13, 2013 at 01:28:19PM -0700, Russ Allbery wrote:
 
  Er, I don't understand why you think this is significant.  The work
  formed by taking the original and putting it under a different license
  is trivially a derivative work.
 
  While it's not defined to my liking in the CC* set, it defines a
  derivative work as::
 
  | Derivative Work means a work based upon the Work or upon the Work and
  | other pre-existing works,

I would say the same thing with a new license is based upon the Work.  The
rest is a list of examples what _is_ included, not about what isn't.  How does
it imply that adding creative content is required?

  | such as a translation, musical arrangement,
  | dramatization, fictionalization, motion picture version, sound
  | recording, art reproduction, abridgment, condensation, or any other form
  | in which the Work may be recast, transformed, or adapted,

And there's this limitation, but it's not relevant here (or are you saying that
it is?):

  | except that a work that constitutes a Collective Work will not be
  | considered a Derivative Work for the purpose of this License.
 
  I'm not convinced a relicense is considered a work based upon the work.
  Just like a patch, I'd assume this to be a creative work / modification
  to the work.

Are those not Derivative Works then?

 Ah, I hadn't ever thought about it from that angle.  Basically, the
 argument is that if there's no original creative addition, it can't be a
 derivative work?  On first glance, 17 U.S.C. § 101 appears to support
 that:

I don't see how you read it in there either...

 A “derivative work” is a work based upon one or more preexisting
 works,

one or more implies that no second creative work is required.
The rest is examples of what is a derivative work, but doesn't exclude
anything.

 such as a translation, musical arrangement, dramatization,
 fictionalization, motion picture version, sound recording, art
 reproduction, abridgment, condensation, or any other form in which a
 work may be recast, transformed, or adapted. A work consisting of
 editorial revisions, annotations, elaborations, or other modifications
 which, as a whole, represent an original work of authorship, is a
 “derivative work”.
 
 The definition does require that it be an original work of authorship,
 which isn't true of trivial changes to the original.

You're talking about the definition of a work here, I presume?  I don't see
how that makes any difference.  It doesn't say two or more works; just one is
enough.

Thanks,
Bas


-- 
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/20130913220947.gz21...@fmf.nl

Re: Can CC BY 2.0 be upgraded to 3.0 ?

[Bas Wijnen]

On Fri, Sep 13, 2013 at 03:31:19PM -0700, Russ Allbery wrote:
 Bas Wijnen wij...@debian.org writes:
 
  You're talking about the definition of a work here, I presume?  I
  don't see how that makes any difference.  It doesn't say two or more
  works; just one is enough.
 
 The key phrase is original, not work.  Original work generally means,
 in US copyright law, that there is some creative component or content that
 makes it copyrightable.  It's the same phrase used to determine whether
 something is copyrightable in the first place.

Sure, but if you have a program, then that is an original work.  Slamming a new
license on it creates a new original work (there is still creative content in
it), which is based on the original original work.  You didn't quote anything
that said the derivation must itself be an original work.  In fact, the
statement that only one original work is required for making a derivative means
that it doesn't need to be, as far as I can see.

Thanks,
Bas


-- 
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/20130913230428.gc21...@fmf.nl

Re: Can CC BY 2.0 be upgraded to 3.0 ?

[Bas Wijnen]

On Fri, Sep 13, 2013 at 04:11:45PM -0700, Russ Allbery wrote:
  Sure, but if you have a program, then that is an original work.
  Slamming a new license on it creates a new original work (there is still
  creative content in it), which is based on the original original work.
 
 I believe that this is not true based on my reading of that section of the
 US code because the derivative is not original.

I thought original was defined by having creative content in it?  Nothing
changed in that respect.

 A derivative work has to be, itself, an original work of authorship, at least
 as I read that section of the code.

I didn't see any part of the quotes that confirms this; in fact, what you
quoted seemed to show the opposite.

 I think we'll have to agree to disagree on this.

We can't, because for that we need to understand each other's positions, and
I'm still trying to understand how you can read it the way you do; I just cant
bend the text to mean what you say it does, even if I try to understand words
in a creative way.

And that's really all I'm trying, too; I don't have an opinion on what is good
or bad, or what Debian needs to do in this matter.

So if you don't feel like trying to explain any further, that's fine. :-)

Also, probably needless to say, I'm not a legal expert either.  I suppose I
would have been able to read anything into that text if I was. ;-)

Thanks,
Bas


-- 
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/20130913235538.gd21...@fmf.nl

Re: The Unofficial (and Very Simple) Lenny GR: call for votes

[Bas Wijnen]

On Mon, Dec 15, 2008 at 09:35:44PM +0100, Adeodato Simó wrote:
 If more people do share your concerns, though, maybe abandoning the poll
 would be the right thing. If it's only you, I can't but offer all my
 explanations above, assert that they're true, and hope they can bring us
 somewhere.

I believe you have good intentions, but agree with Frans that this poll
only adds extra confusion to the issue.  For that reason, I am not
voting in it.  Also, I don't understand the point of ranking FD above
options you actually want in the official vote.

Especially if you want an option which requires a 3:1 majority, it seems
quite important to me that you vote it according to your preference.
I'm not really complaining, I'm only voting options 5 and 1 above FD, so
this boycott would help my preference.  But I think it would be a bad
idea to get things my way, if the developers don't actually want that.

So I ask everyone to just vote how they want things to go.  If you
don't, the only result is that things happen that you don't want.  If
you really do think that FD is better than any of the options, please
vote it highest.  But if you don't, boycotting the vote seems like a
very bad thing to do.

 One final thing: these two mails of you have brought a fair amount of
 stress on me, because of the way you say things. (Maybe you don't feel
 it's reasonable for me to feel stressed, but it's simply true that I
 was.)
 
 I have swallowed hard and replied calmly to them, because I believe
 developers, and particularly those holding key positions, should not
 ignore other developers, even if their concerns don't come in with a
 wrapping of sugar. (I don't want to ignore people in my Debian work, and
 if it ends up being impossible to deal with somebody, I'll clearly let
 them know.)
 
 However, the same way I've made an exercise and considered your views on
 actions of mine that I felt were right, I'm going to invite you make an
 exercise and consider what your style may bring onto other fellow
 developers (even if your points are right), because I know you've felt
 stressed with interactions with other developers yourself in the past,
 and it'd be bad to bring to others what you so much loathed.

I'm impressed by the way you handle this.  Thank you.

Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Developer Status

[Bas Wijnen]

On Fri, Oct 24, 2008 at 12:02:57AM +0200, Stefano Zacchiroli wrote:
 On Thu, Oct 23, 2008 at 10:55:55PM +0200, Bas Wijnen wrote:
   Given how rooted is the acronym DD in the Debian community, I doubt it
   is a good idea to change it or even to get rid of it.
  
  True, but the proposal splits the current DD in two types, namely DDM
  and DNDM.
 
 No, it does not split (to be precise, it does not partition) the
 current DD class.

 rather then splitting adds a new class of people able to vote.
 
 Hence, I still don't by your argument.

I admit that that wasn't the strongest point.  The main reason is the
part you didn't quote, though:

On Thu, Oct 23, 2008 at 10:55:55PM +0200, Bas Wijnen wrote:
 It would be very nice to have a naming where DDM (or perhaps just DM)
 would still be DD, but I couldn't think of a scheme where that was
 possible while still showing the logic of the roles.  Calling every
 member a developer just doesn't make sense.

To be more clear, I am trying to accomplish:
1 - a naming scheme which makes sense, instead of the current scheme,
where more confusion is added with each new name.
2 - a scheme where DNDM and DDM are not normally separated, so when we
talk about DDs, we aren't leaving an important group out.
3 - not too much confusion due to name changes.

1 and 2 have equal priority; 3 has lower priority, IMO.  I agree with
you that my proposal doesn't do well on that point.  The reason I accept
this, is that this confusion is not permanent; it will be gone once
people are used to the new names.  The confusion of 1 on the other hand
will exist until the naming scheme is replaced.

You're saying that 3 should have a higher priority (right?).  In the
short term, I can see that this avoids problems.  But in the long term,
ignoring the proposal, it leaves problem 1.  And with the proposal, it
makes problem 1 even bigger, and more importantly, it introduces problem
2.  That is, with the naming Jörg proposed, DNDM and DDM don't have a
common name, so when talking about all DDs, we're missing the DNDMs.
As was remarked elsewhere, this will result in them being looked upon as
second class.  Since Jörg's proposal is exactly meant to show them that
we value their contributions, I think it is actually very important to
do this Right.  And that means
A - that they aren't called developers.
B - that they are full members, and that their title (DM) is used when
talking about them.

Calling every member a DD (as it is now) would need a new meaning for
DD, because as I wrote, not every member is a developer.  If you have a
suggestion for a better name, I'm open for suggestions.  I couldn't come
up with anything better than member, because that's what it's really
about.

By the way, do you agree to renaming DM/DC/DME to more logical names, or
do you dislike that as well?  My main problem with the naming is with
DM/DME.  Do you share my concern about this?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Developer Status

[Bas Wijnen]

First of all, a suggestion from me.  I would like to change names a bit,
so there are names for some groups as well.  Here's my proposal:

- Debian Developing Contributor (DDC) = what's currently called DM
- Debian Non-Developing Contributor (DNDC) = what's called DC in the
  proposal.
- Debian Contributor (DC) = DDC + DNDC.
- Debian Developing Member (DDM) = what's called DD in the proposal.
- Debian Non-Developing Member (DNDM) = what's called DME in the
  proposal.
- Debian Member (DM) = DDM + DNDM.
- Debian Key-owner (DK) = DM + DC

I'll be using these abreviations below, and to limit confusion I changed
quotes so they use it as well.  When really talking about current
things, I use them unabreviated.  I suggest others to do the same.
(This is my view of Debian-style consensus-building: just do things how
you consider them right, and hope others will follow your lead.)

To avoid confusion about DM (which has a meaning in both naming schemes,
which is not the same), I recommend everyone to explicitly say which
naming scheme they're using.  If you don't mention this, I'll assume
you'll be using the same scheme as the post you reply to (if any).

On Wed, Oct 22, 2008 at 10:23:24PM -0200, Margarita Manterola wrote:
 I'm quite disappointed on this being informed as a done thing, without
 the project as a whole being asked for an opinion.

The mail talks about a proposal.  I took that as something which is open
for discussion.

On Wed, Oct 22, 2008 at 11:29:53PM -0300, Felipe Sateler wrote:
  Debian Contributor
  --
 Basically, they need to pass the ID check, agree to the Social
 Contract/DFSG and have successfully answered a set of questions
 similar to the ones used in the current first PP step, to keep doing
 the same thing they have been doing all this time.

No.  Current Debian Maintainers also need an ID check, agree to
SC/DFSG/DMUP and be advocated.  The only thing that is added (and that
was made clear by Joerg), is that they need to answer a very limited set
of questions.

Also, I don't think this is supposed to change anything to the
sponsoring system, so people who use sponsors can continue to do so as
well, without the questions (or the other checks).

I do have one question: the current Debian Maintainer process has some
features which the New Maintainer process does not have.  I'm mostly
thinking of the fact that advocation mails must include reasons why the
prospective DC is a good candidate.  Another post mentioned the yearly
ping.  I would like to keep those things (and thus add them to the DC
process).

 So this basically requires Debian Maintainers to do the (somewhat
 reduced) PP and TS questions, and I don't see the real reason for
 this. The idea behind Debian Maintainers is to maintain a package one
 knows how to maintain.

Those people are getting upload rights to the archive.  Don't you think
it's reasonable that the project wants people to show that they won't
mess things up before giving such a priviledge to them?

Becoming a Debian Maintainer is supposed to be a light-weight version of
the New Maintainer process.  It's not a I'll skip the New Maintainer
process entirely-version.

 The only reason I can see here is that DDs are not being trusted in
 their advocations, which is a far worse problem that won't get solved
 by this.

We have over 1000 members.  That's way too much to use the if you have
1 invitation, you're in-system.  Looking at the recent flamewar, I'm
pretty sure almost every DM has at least one other DM whose advocation
they don't trust.

So I don't think one advocation is not enough is a problem at all.
It's just a result of having many members.  Don't forget that this is a
quick thing.  People who don't care enough to answer some quick
questions (or show in some other way that they can handle the
responsibility) aren't interested enough to get the priveledge we're
talking about, IMO.

   - ensures that the interest in Debian isn't short-term.
 
 Why do people keep thinking this is a good thing?

If people only have short-term interest, that's not a bad thing in
itself.  But in this case we're talking about giving them long-term
priviledges (upload any package; vote; become DPL, that sort of thing).
We want members of our project to have a long-term interest, don't you
agree?

   - enables them to learn more about the workings in Debian and generally
 helps them for the next step.
 
 They should be doing this on their own, and not force an arbitrary limit on
 them. What if they did this _before_ applying for DC/DM status?

In the proposal, there is no help during these 6 months.  So basically,
if people want to do this on their own, the project will ask them to say
so before doing that (in the proposal).  Saying so means applying for DC
status.  Applying for DM is not possible before those 6 months are over.

You seem to want to rush total outsiders into the most priviledged
positions of the project.  Why would that be a good thing?  What is 

Re: Developer Status

[Bas Wijnen]

On Thu, Oct 23, 2008 at 12:03:13PM +0200, Gerfried Fuchs wrote:
 * Bas Wijnen [EMAIL PROTECTED] [2008-10-23 09:59:09 CEST]:
  First of all, a suggestion from me.  I would like to change names a bit,
  so there are names for some groups as well.  Here's my proposal:
 
  This is misleading because a DME is (also) an enhanced version of a DM,
 i.e. a DME is allowed to upload their own packages and can be a
 developing contributor.

Not according to my reading of Joerg's proposal.  People go from DC to
DME.  It is possible to also do DM, which means that person has two
roles (DM and DME).

 Your distinction doesn't make it clear between
 DDs that can upload any package and those that can only upload a
 specific set of packages.

In my terms, it would mean someone is DNDM and DDC at the same time.  If
it is expected that this would happen a lot, it can get a name by
itself, but I thought I was using enough new names already. :-)

 Where Joerg's proposal (which I wholeheartly
 support) made the clear distinction between the full DD state that isn't
 limited in any sense and the limited upload allowance (even as limited
 as no package at all) you draw the line between no-upload right and any
 upload right, even limited.

I don't think I changed anything in the roles, I only changed the names:
DC  = DNDC
DM  = DDC
DME = DNDM
DD  = DDM

And I add names for groups, so you don't have to say DC and DM or DME
and DD.  At least I did not intend to change the meaning, I am just
worried that DC/DM/DME/DD are not very logical names, while the
underlying structure is in fact two orthogonal elements:
- Is this person a member? - D*C / D*M
- Does this person do package development? - DND[CM] / DD[CM]

And because that last question is often irrelevant, I propose to use
standard names for people depending on their member-status only (DC/DM).

Finally, I think it is useful to have a name for all people in Debian,
which is why I added DK.  I'm not sure if it's useful, and I'm not happy
with the name, nor with the fact that it completely ignores sponsored
maintainers.  So perhaps that last one should be removed.  It'd probably
never be used anyway. :-)

  Personally I am not sure if your distinction is the better one,
 personally I prefer the one that Joerg proposed.

I didn't intend to change his proposal; I'm happy with the roles he
describes, I just want to give them different names.

 About the naming, I'm not sure if we really should change everything
 everywhere completely, I don't see the real gain,

The gain is that we're finally done with the confusion about people in
Debian.  Currently we have new maintainers who are debian
developers, and debian maintainers who are not.  Now we'll add
debian members, who are not debian developers, even though all
developers are members of the project (but not considered debian
member as in DME).  Also, people who hear the full names will be
confused by debian member/DM which are two totally different things.

 rather the drawback that we will be faced with endlessly outdated
 documentations that won't get noticed about using the old terms.

Yes, I agree that this is a drawback, and we should not lightly do this.
However, given the current confusion about the naming already, this
seems to be the perfect moment to solve it: new names are added, the
whole thing will be changing anyway.  The current proposal is to make
things even less clear.  My proposal is to accept the extra work of
getting old documents up to date (or accepting the this is an old
document, it uses the old naming excuse for not-so-important
documents).

So just to be clear: I am, like you, totally in favour of the proposal.
I just see the opportunity to fix an other problem along the way.  If
people disagree that the names should be changed, I'm still in favour of
the proposal. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Developer Status

[Bas Wijnen]

On Thu, Oct 23, 2008 at 07:27:03PM +0200, Stefano Zacchiroli wrote:
 On Thu, Oct 23, 2008 at 09:59:09AM +0200, Bas Wijnen wrote:
  - Debian Developing Member (DDM) = what's called DD in the proposal.
 
 Given how rooted is the acronym DD in the Debian community, I doubt it
 is a good idea to change it or even to get rid of it.

True, but the proposal splits the current DD in two types, namely DDM
and DNDM.  Currently DNDM doesn't exist, but people who aren't using
upload rights because that's not what they're doing for Debian are also
DD.  So at least one of them is going to get a new name.  It would be
very nice to have a naming where DDM (or perhaps just DM) would still be
DD, but I couldn't think of a scheme where that was possible while still
showing the logic of the roles.  Calling every member a developer just
doesn't make sense.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Developer Status

[Bas Wijnen]

On Thu, Oct 23, 2008 at 05:40:32PM -0300, Felipe Sateler wrote:
  Basically, they need to pass the ID check, agree to the Social
  Contract/DFSG and have successfully answered a set of questions
  similar to the ones used in the current first PP step, to keep doing
  the same thing they have been doing all this time.
  
  No.  Current Debian Maintainers also need an ID check, agree to
  SC/DFSG/DMUP and be advocated.  The only thing that is added (and that
  was made clear by Joerg), is that they need to answer a very limited set
  of questions.
 
 I am talking about the DNDCs here. DNDCs have no priviledge whatsoever
 besides getting included in a list.

Yes, and possibly getting a @contributor.debian.org e-mail, appearantly.
So what does Debian want to do?  We want to show those people we
appreciate their work, and we want them to be able to tell others that
they do work for Debian.  We also want this to be worth something, so we
shouldn't add just anyone to the list, but only people who agree with
our philosophy.

In order to be able to say anything, we need e-mail most of the time,
and in order to identify someone as the person I'm talking about, we
need a signed key.  So the ID check is going to stay.  For the
philosophy thing, we need agreement with our foundational documents
(which isn't any problem, of course).  The need to be advocated seems
reasonable to me as well, to maintain the status of that list.  So
there's only answering the questions, and I think that was only the case
for DDC, not DNDC.

  Becoming a Debian Maintainer is supposed to be a light-weight version of
  the New Maintainer process.  It's not a I'll skip the New Maintainer
  process entirely-version.
 
 If the current Debian Maintainer process is failing for some reason, please
 elaborate. If it's not, then I don't see why adding more checks is useful.

I don't think it's failing, but I also don't see where the more checks
would be.  You're talking about the very limited TS questions?  Jörg
made it clear that this wouldn't be much trouble, and that people should
be able to finish the checks in a very short time.  You may be right
that there's no reason for them, and in that case it would be better to
remove them.  But it's also not a big issue IMO.

 But I think that for general upload rights the bar is way lower. As I
 said in another message, 1 year is enough to do a lot of work, but
 spending half of that year waiting is not useful, I think.

If a person needs to learn about Debian packaging at the start of the
year, then I don't think it's reasonable to expect much work on more
than a few packages, at least in the first 6 months.  And for a few
packages, there's no need to get full upload rights.  Just becoming a DC
is enough for that, and that needs no waiting.

  You seem to want to rush total outsiders into the most priviledged
  positions of the project.  Why would that be a good thing?  What is the
  problem of letting people work 6 months with slightly fewer rights?
 
 I don't want to rush people into privileged positions. I object arbitrary
 limits, specially when I think the limit will miss many important cases.

I don't see the many cases you are talking about.  One effect of this
proposal is that people should apply for DC when they are getting
started.  If people don't do that, but instead are active but not in any
keyring, then 6 months is a long time to wait before being able to apply
for DM.  It could be good to allow skipping of the delay for one month
per advocate, which means you need to get seven advocations (one to
start, plus one for each month) to start immediately with a DM
application instead of DC.  If people are really active, getting seven
advocations shouldn't be too hard.  If they aren't, then the waiting
isn't a bad thing.  That sounds like a good idea, actually.  Jörg, what
do you think about this?

  Of course there technically is a full and almost full rights membership.
  What I think he means to say, is that DNDMs should not be looked down
  upon, and that they do get everything they need from the project.
 
 That's why I said you might not intend that. If they are effectively
 almost-DDM, there is a large room for looking down.

Which is also why I prefer my naming scheme.  Almost all the time,
people will be talking about DMs then, so there's no reason to look
down; we won't even remember who is DDM and who is DNDM.

Of course giving DNDMs full upload rights solves the problem as well.
IMO that is acceptable, since a) those people are DM, so they must be
trustable and b) uploading is so open en checkable, that people who do
mess up can have their upload rights revoked.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for 

Re: Debian and non-free

[Bas Wijnen]

On Wed, Sep 17, 2008 at 10:38:21AM -0700, John H. Robinson, IV wrote:
 Michael Banck wrote:
  On Wed, Sep 17, 2008 at 08:24:52AM +0200, Martin Schulze wrote:
   
   Non-free is for GNU documentation.
  
  I think we should consider (post-lenny) splitting up non-free in a
  couple of sub-categories.  Personally, I'd prefer fsf-free, but
  non-free-docs would be just as good, besides non-free-firmware and
  non-free for the rest.
 
 I like this idea, but without mentioning FSF directly. More entities than
 just the FSF use the GNU FDL for licensing.

I would much prefer to mention the FSF directly, actually.  Not because
it's about their software (or documentation), but because it's about
their opinion about what is free.  So we get:

- main (dfsg-free)
- fsf-free (non-dfsg-free, but free according to fsf)
- non-free-firmware
- non-free (for all other classes)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: debian/copyright for files not part of the binary packages?

[Bas Wijnen]

On Sun, Jul 20, 2008 at 03:20:57PM +0200, Stefano Zacchiroli wrote:
 On Sat, Jul 19, 2008 at 04:20:48PM -0700, Steve Langasek wrote:
  I also disapprove of the ftp team enforcing such a requirement as part
  of binary NEW - it's not my problem that this is the only time they
  look for such problems in the archive, and it's not appropriate for
  the ftp team to couple my library transition to a completely
  orthogonal bug.
 
 I understand that can be pissing off that a pre-existing bug in the
 archive (according to FTP masters POV) causes a NEW reject, but *if* you
 agree with them that it is a bug, then it doesn't matter when it get
 recognized. Then, I concur that their power in rejecting the package
 instead of simply submitting the bug report is strong, but they are the
 ultimate responsible of what is in the archive after all.

The bug is currently in the archive.  If it is so severe that it mustn't
be, then they should remove the current package from the archive as
well.  They don't seem to want to do that.  To me, this means that it's
an orthogonal issue, for which they should use the BTS, just like anyone
else who finds a bug.

In particular, they are currently blocking a library transition, with
the reason that there is a bug in the new package which is also in the
old package.  So blocking the transition doesn't actually solve the bug.
I don't see how this block is reasonable.

 But still you miss my point or I explained it badly: copyright of source
 files can mix arbitrarily in binary files. As it would be foolish to ask
 FTP masters to check the whole build process to discover source-binary
 flow, a simple rule has been put in place: copyright/license of all
 source files should be declared in debian/copyright.

I find it reasonable to say in case of doubt, put the license in
debian/copyright.  But in many cases (such as not-packaged
documentation), there is no doubt at all.  The file is in the source
package, and it will not be in the binary package.  So I don't think
this is a very strong point.  Also, I think DDs should be trusted to
make this judgement.  If you don't trust DDs, but only ftpmasters, then
they should make all packages themselves.  I'm sure you agree that we
don't want to put such a burden on their shoulders. ;-)

I don't have a strong opinion on whether the copyright file should
document the copyright and license of non-shipped files.  I'm a big
proponent of the machine-readable format plus a clean all generated
files target in debian/rules.  The combination would make it possible
for a program to check that every source file in the tree would have a
license (and perhaps even that it is the correct license).

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: how to do an NMU

[Bas Wijnen]

On Sat, May 31, 2008 at 09:02:18PM +0200, Frans Pop wrote:
 On Saturday 31 May 2008, Luk Claes wrote:
  Ok, though I'd rather have a (strong) recommendation to prod
  maintainers (in a team or not), then to special case teams...
 
 Sure. For me it is not necessarily about teams, but more about active: 
 likely to respond and take care of urgent issues him/her/themselves when 
 prodded, thus making an NMU unnecessary.
 
 Basically I and several others have been asking to add something that 
 effectively (and more explicitly than in the current proposal) says:
 
Please consider before you NMU if just contacting the maintainer isn't
likely to more effective than doing an NMU.
 
In general it should be considered preferable that a maintainer
takes care of an issue himself and that he is given the chance to
review and correct your patch, because he can be expected to be more
aware of corner cases and complex interactions, things that an NMUer
might miss.

While I agree with this principle, I have one comment: IMO posting a
patch (with explanation of what it fixes and why, and that an NMU to
DELAYED has been uploaded) to the BTS is an appropriate way to notify
the maintainer.  There is no need to expect the upload to actually be
ACCEPTED.  In normal cases, either the maintainer uploads the fix (or a
different one) him/herself, or the NMU does reach unstable.  In the
slightly exceptional case, the NMUer is asked to remove it from the
queue.  Note that this should mostly happen if the maintainer failed to
document in the BTS why the bug is still open.

I find this important for fixing mass-filed-bugs.  They're all similar,
the solutions probably are as well, and it would be too much (IMO)
overhead to have to check who is maintaining the package.

This is only about bugs which have had the intent to NMU in the BTS
for some time before the upload hits unstable.  I explicitly do want to
allow (and not discourage) uploading to DELAYED at the same time as
reporting the bug in the BTS, even for active teams.  I don't see a
problem, because active teams should handle the bug before the delay
expires anyway.

I think the big difference between this view and that of Frans is
whether an upload to DELAYED should be considered an NMU.  IMO it should
not, it should only be seen as expressing the intent (which needs to be
done sufficiently long before).  (Since the DELAYED queue doesn't send
notifications, this must of course also be done.)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: how to do an NMU

[Bas Wijnen]

On Mon, Jun 02, 2008 at 11:01:00AM +0200, Frans Pop wrote:
 On Monday 02 June 2008, Bas Wijnen wrote:
  While I agree with this principle, I have one comment: IMO posting a
  patch (with explanation of what it fixes and why, and that an NMU to
  DELAYED has been uploaded) to the BTS is an appropriate way to notify
  the maintainer.
 
 Right. And this is where we fundamentally disagree.

I'm not so sure about that, after reading your last mail. :-)

  I find this important for fixing mass-filed-bugs.  They're all similar,
  the solutions probably are as well, and it would be too much (IMO)
  overhead to have to check who is maintaining the package.
 
 I have no real problem with what you suggest in _this_ use case, and the 
 changes that Lucas has made to the DEP do _not_ prevent doing this.

No, the DEP including those changes doesn't prevent it; but it does use
text which suggests that it's not the right thing to do.

 The only thing the changes are intended to do is to make the NMUer think 
 twice about doing a direct NMU without doing the normal thing of 
 submitting the patch in the BTS

Let's make it a bit more concrete; N is potential NMUer, M is
maintainer, t is time in days:

t=0: N reports a bug.
t=4: there was no response from M, N uploads NMU to DELAYED/7.
t=8: M uploads a better patch himself.

or

t=0: N reports a bug.
t=4: there was no response from M, N uploads NMU to DELAYED/7.
t=8: M tells N that he wants to fix this himself, but needs time, so the
 NMU should be cancelled (or he does it himself, I didn't hear any
 objection to making this possible).
t=?: M uploads his fix.

or

t=0: N reports a bug and uploads NMU to DELAYED/11
t=8: same as above.


What is the difference for the maintainer between these?  Not the time
required for M; in all cases, the most M needs to do to prevent the NMU
from happening is writing a mail to N (and the BTS).  The only
difference is what to say (please cancel the NMU or please do not
upload the NMU).

In other words, the difference is only on the NMUer's part.  If it is
useful in some cases to just upload to DELAYED and not wait for a
response from the maintainer (but react anyway if it comes, of course),
I don't see any reason to require justification for that.  It's only his
own problem, after all.

It's good to suggest (or even recommend) to check with the maintainer
before going through the trouble of preparing an NMU.  But if people
feel that preparing the NMU is easy, why stop them?  The suggested
procedure will inform the maintainer the usual way, and he has all the
time to say please wait in case that is needed.  If he doesn't even
have time to do that, then the package is indeed a good candidate for an
NMU IMO.

 and giving the maintainer a chance to respond without forcing his hand
 and forcing him to reorder his priorities by doing a simultaneous
 upload to DELAYED.

If there's no upload to DELAYED, he only needs to say he saw the bug,
and that he's working on it.  If there is an upload, he only needs to
say he'll work on the bug, and that the NMU should be cancelled.  No
reordering of priorities is required.

  This is only about bugs which have had the intent to NMU in the BTS
  for some time before the upload hits unstable.  I explicitly do want to
  allow (and not discourage) uploading to DELAYED at the same time as
  reporting the bug in the BTS, even for active teams.
 
 I do, and if you are not willing to compromise on this I doubt there is 
 ever going to be consensus on this DEP. Not for all cases, but I see no 
 reason why that should become the normal practice for *all* packages 
 and for all *bug* severities and for *all* types of bugs.

No, not normal practice indeed.  I agree with you that in many cases it
is better to just send a patch.  But I don't see a problem with
uploading to DELAYED (with sufficiently high delay), if the NMUer
prefers it.

 Consider again Debian Installer. D-I is native code. This means that every 
 upload is effectively a new upstream release. What you are proposing is 
 to let random people do upstream releases without first discussing their 
 changes with the upstream maintainer.

I am not suggesting that people should be doing uploads to unstable, I'm
only saying that they can send a patch to the BTS and DELAYED if they
want.  Given that the D-I team is active, it should be no problem to
have at least one person saying thanks, we'll solve it our own way.

 My second main objection was this [EMAIL PROTECTED]:
 ! The DEP should not be a licence to avoid entering into a discussion with
 ! the maintainer of a package, or to pre-empt him.
 
 From my PoV your standpoint is that you _do_ want to give developers that 
 licence and for me that is unacceptable.

No, I don't, I agree with you that this would be unacceptable.  If the
maintainer says no, then the NMUer should need the technical committee
to override that, nothing less.  I just want to have written down that
it is acceptable to use

Re: DEP1: how to do an NMU

[Bas Wijnen]

On Mon, Jun 02, 2008 at 01:12:43PM +0200, Frans Pop wrote:
 On Monday 02 June 2008, Bas Wijnen wrote:
  What is the difference for the maintainer between these?  Not the time
  required for M; in all cases, the most M needs to do to prevent the NMU
  from happening is writing a mail to N (and the BTS).  The only
  difference is what to say (please cancel the NMU or please do not
  upload the NMU).
 
 The difference is that now the maintainer is _forced_ to react before the 
 package reaches the end of the queue,

Where react is send a mail to the BTS.  If the maintainer can't
even do that, then with the current rules, the NMUer can upload to
DELAYED anyway.  Are you seriously saying that you want to require the
NMUer to not automate his waiting?  What if I send to the patch to the
BTS and upload to DELAYED/11, then I wait 4 days and then (unless there
was a reply) I tell you that the upload is now in DELAYED/7.  Would that
be better than saying immediately that it's in DELAYED/11?

 so basically you are forcing him to work on this particular issue
 while he may have other priorities. That is not right.

Sending a mail to the BTS isn't that much work, and it should be done by
a responsible maintainer anyway...

 You are also uploading a patch that the maintainer may never have had the 
 chance to review and comment on as the patch may not have been in the 
 original BR.

But I'm not uploading it to unstable!  I'm scheduling it for upload,
giving you all the time you need to look at it.  If there's even a
detail which needs to be looked into, I can simply remove it from the
queue.

  If there's no upload to DELAYED, he only needs to say he saw the bug,
  and that he's working on it.  If there is an upload, he only needs to
  say he'll work on the bug, and that the NMU should be cancelled.  No
  reordering of priorities is required.
 
 Which assumes that the NMUer is available to do so, which is not 
 guaranteed by the DEP.

The DEP is in no position to guarantee such things, but it does say:

The DELAYED queue should not be used to put additional pressure
on the maintainer. In particular, it's important that you are
available to cancel or delay the upload before the delay expires
(the maintainer cannot cancel the upload himself).

As I wrote before, I don't want to change this.

  No, not normal practice indeed.  I agree with you that in many cases it
  is better to just send a patch.  But I don't see a problem with
  uploading to DELAYED (with sufficiently high delay), if the NMUer
  prefers it.
 
 I do and will continue to do so. The NMUer should not use DELAYED just 
 because *he* prefers to work that way,

Suppose I like to automate this waiting, and will be available to cancel
the upload.  It is appearantly not acceptable for you if I use DELAYED
and tell you about it.  Is it acceptable if I don't tell, as I wrote
above?  You can check the queue, of course.  Would it be more acceptable
if I implement my own delayed queue and tell nobody about it?  Is it
acceptable if I put the delay in my PDA so it notifies me when it
expires, or do you feel strongly that I must remember it without any
help?

 but only he is convinced *after checking the policy recommendations
 for NMUs* that it is a suitable way to deal with that particular BR
 for that particular package.

There should be policies on how to communicate and when to upload to
unstable, not about which technical tools are acceptable to use in
following these policies.

  No, I don't, I agree with you that this would be unacceptable.
 
 Right, and that is where our opinions _do_ differ fundamentally.

You don't agree that I agree with you?

If this mail hasn't made you reconsider, please tell me what you think I
think, because I think I think something else. ;-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: how to do an NMU

[Bas Wijnen]

On Mon, Jun 02, 2008 at 02:07:57PM +0200, Frans Pop wrote:
 On Monday 02 June 2008, Bas Wijnen wrote:
No, I don't, I agree with you that this would be unacceptable.
  
   Right, and that is where our opinions _do_ differ fundamentally.
 
  You don't agree that I agree with you?
 
 OK, I misread that. Sorry.

No problem. :-)

 The fundamental thing we disagree on is that you think creating a patch 
 and doing an immediate upload to DELAYED is an acceptable workflow for 
 any kind of issue.

Yes.  Not recommended, but certainly acceptable.  With a long delay, of
course.

 I think that is unacceptable and I think I have made my arguments for
 that clear enough by now.

I still don't understand what the problem is that you have.  I'd like to
get this cleared up, otherwise we may continue to have
misunderstandings.

If I want to create a package, then I will do that.  What would you
recommend me to do?  Tell you about the problem and hide the package for
some time?

What is so special about the DELAYED queue that makes a package in there
different from a package on my local hard drive, waiting to be uploaded
in case the maintainer doesn't reply (or accepts it)?  What if I
schedule an at job to upload it?  Must I not tell you that the upload
will (if needed) be done by atd, and suggest that I will personally come
back to it?

To avoid more misunderstandings, I'm very much opposed to hiding patches
or information like I will make sure an upload happens at that moment
if you don't reply.

The delayed queue is a tool which makes it possible to make sure of
such a thing without manual intervention (unless it needs to be
cancelled).  You seem to want to forbid using this tool in some cases.
I am asking you what the purpose of such a restriction would be.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Bas Wijnen]

On Thu, May 29, 2008 at 05:47:45PM -0700, Richard Hecker wrote:
 I see the same weakness that Henrique listed above. Some people will
 prepare a NMU without even sending an email to the maintainer.

Posting the patch in the BTS does actually send mail to the maintainer.
And it's nicely in time, because with the DELAYED queue, the upload to
ftp-master doesn't happen before some days.

DELAYED is just a way to automate the wait a while, then upload to
ftp-master part.  This DEP makes this explicit.  A bug in the BTS is a
good way to contact a maintainter IMO.  Using the DELAYED queue has an
added benefit that it is completely clear that an NMU will be done, and
when.

 I still want to stress that we should strive to improve communication
 when we can.

Yes, communication is good.  We have several media for it, the two most
important ones being mailing lists and the BTS (IMO).  This DEP proposes
to use the BTS for communication about NMUs.  It was that way already
AFAIK, although some people seem to think private mail was needed as
well.  To avoid any confusion, we should make it explicit in any case.
If many people think private mail is needed before uploading to DELAYED,
please speak up and we'll require that.  To me, that would pretty much
disable all usability of DELAYED, but that may be just me...

 You did not find consensus to adopt your view back then, and I hope
 you will not use DEP1 to establish your preference now.

If we wanted to force ideas on people, we wouldn't have used a DEP.  The
whole system is explicitly about building consensus, so there's no risk
that people sneak things in.  At least that's the idea AIUI, we're still
in the testing phase, so if you feel that it does happen, please point
at it and yell. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)

[Bas Wijnen]

Hi,

On Fri, May 30, 2008 at 11:40:53AM +0200, Frans Pop wrote:
 On Friday 30 May 2008, Charles Plessy wrote:
  the DEP says:
   - must use BTS,
   - usage of DELAYED is recommended.
 
 I would like to see at least two cases where communication with the 
 maintainer is required *before* uploading (DELAYED or not)

I see delayed as a way to do wait some time and then upload.  That is,
uploading to DELAYED should not be considered uploading a package IMO.
It's simply a tool to not need to get back at it if things are going as
planned (either the package should be NMUed, or the maintainer uploads a
new version in time).

 by sending an intend to NMU (conform current policy basically):
 - packages that are clearly actively maintained (can be seen from changelog)
 - packages that are maintained by active teams

So I don't think any special consideration is needed here.  Of course,
if writing a NMU changelog entry is too much trouble for you, you're
free to upload just a patch.  But uploading an NMU patch to DELAYED and
the BTS at the same time is acceptable even if you don't expect the NMU
to actually reach the archive, IMO.

 There should normally be no need to NMU in such cases and just preparing a 
 good patch for the BTS should be sufficient.

Yes, but there's no harm in preparing an NMU anyway, so there's no need
to forbid it IMO.  I'd just let people decide what method they prefer.

 The intend to NMU could say I plan to do an NMU to DELAYED X in Y days; 
 please reply before then if you'd prefer to do the upload yourself.

What's wrong with uploading to DELAYED/X+Y ?

 Exceptions to this rule could be allowed for urgent cases, but the NMU'er 
 had better be prepared to defend himself if challenged about it (i.e. have 
 good reasons for not following the rule).

The approach of the DEP is to not make strict rules, but only
recommendations.  Not following them does indeed need a reason.

But in the situation you mention above, I don't think there's anything
wrong with actually preparing an NMU (except that you may be wasting
time, but that's your own problem).  So no reasons are needed for it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: Clarifying policies and workflows for Non Maintainer?Uploads (NMUs)

[Bas Wijnen]

On Fri, May 30, 2008 at 07:03:16PM +0900, Charles Plessy wrote:
 I think that when the mainainer is active, he has to be consulted if a
 NMU is planned. As a compromise with those who disagree, I propose that
 he should be given time to react.

I'm one of the people who disagrees, but actually I don't. ;-)  When
planning an NMU, you must notify the maintainer, and give him time to
react, and respond to the reaction.  That's basically the same thing as
consulting him IMO, except that no response leads to Ok.  I think
that is good, it's one of the reasons NMUs are possible at all.

  result in more cases where the NMUer would not give some time to the
  maintainer.
 
 Exactly, I propose that the maintainer can say no, thank you whithout
 it becoming a crisis.

Certainly.  If that wasn't clear, please propose a new wording for that
part of the DEP.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Bas Wijnen]

On Mon, May 26, 2008 at 11:56:12AM +0200, Cyril Brulebois wrote:
 On 26/05/2008, Charles Plessy wrote:
  It depends on how important are the VCS and package histories for the
  maintainer and Debian. In order to acknowledge the NMU, it would be
  necessary to revert the current work, apply the NMU patch, merge the
  reverted work and resolve the conflicts.
 
 It looks to me like the wording of the 3rd paragraph of 5.11.2 is a bit
 (too) strong: one must include the patch. It might be relaxed a bit so
 that the maintainer is still allowed to implement the changes the way
 s/he intends, rather than having to include the very patch sent to the
 BTS.

The proposal is to use the DELAYED queue as the default way to do an
NMU.  This means in particular that the code is already finished when
the mail about the NMU is sent to the BTS.  So there is no reason to
allow changes to the patch after this mail; if you need them, cancel the
NMU and upload an other one instead (sending the new patch to the BTS).

Also note that because of the do what you think is right, these are
only guidelines-approach, it may be acceptable to cancel an NMU and
upload a new one with a very short delay.  IMO you shouldn't do that in
most cases, but it can happen.  Especially if the new patch is almost
identical to the previous one.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Bas Wijnen]

On Sun, May 25, 2008 at 01:00:55PM +0200, Luk Claes wrote:
 Bas Wijnen wrote:
  === nmudiff improvements
 
 Can you please just file a bug against devscripts and leave this out of
 the DEP?

No, because:

  = the nmudiff patch is not controversial. Why include it in the DEP?
  
  * If the DEP isn't agreed upon, the patch has no reason to be
included in devscripts.
 
 It also has no reason to not be included AFAICS.

It has.  This DEP changes the default way to handle an NMU from
announce that you are going to do it, wait, do it to use the DELAYED
queue.  The new wording depends on the DELAYED queue being used.  If
the DEP is rejected, using this template doesn't make sense.

I agree that even then an improvement should be made, but it should be
different from what we propose here.

  * It gives the opportunity to discuss the formulation at the same
time as the rest of the DEP.
  * DEPs are supposed to allow changes in several parts of Debian at
the same time. That's a good test case :-) 
 
 Ok, though I didn't see much discussion about it...

We just started.  This is already the third e-mail about it in this
thread. ;-)

  = Is that really the best place to discuss stable, security and QA
  uploads, and binNMUs?
 
 Yes, though the versioning of security uploads will probably be used and
 decided by the Security Teams and the versioning of stable uploads will
 probably be used and decided by the Stable Release Team anyway... Though
 I won't oppose guidelines for the versioning.

They're only guidelines, and if those teams don't follow them, well,
what can we do? :-)

But there are technical reasons for using this scheme (sorting of
versions is currently not always right, this is fixed with the
proposal), so I'd highly recommend the teams to follow the guidelines.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Bas Wijnen]

On Tue, May 27, 2008 at 08:01:27PM +0200, Cyril Brulebois wrote:
 On 27/05/2008, Bas Wijnen wrote:
  The proposal is to use the DELAYED queue as the default way to do an
  NMU.  This means in particular that the code is already finished when
  the mail about the NMU is sent to the BTS.  So there is no reason to
  allow changes to the patch after this mail; if you need them, cancel
  the NMU and upload an other one instead (sending the new patch to the
  BTS).
 
 I'm talking about ACK'ing a previously-uploaded-and-accepted NMU in a
 future upload.

Oh, sorry, I didn't look up your reference and thought you were talking
about including the patch in the BTS.

 Quoting Charles: “In order to acknowledge the NMU, it would be necessary
 to revert the current work, apply the NMU patch, merge the reverted work
 and resolve the conflicts.”
 
 I think I wrote about the 3rd paragraph of 5.11.2, maybe I should have
 quoted it as well: “When a package has been NMUed, the maintainer should
 acknowledge it in the next upload. This makes clear that the changes
 were accepted in the maintainer's packaging, and that they aren't lost
 again. For this, you MUST first incorporate the changes into your
 packaging, by applying the patch that was sent. Make sure to include the
 NMU's changelog entry in your own changelog. This is important to allow
 the BTS version tracking to work.”
 
 [Emphasis on “must” added on purpose, that was meant to be my point.]

Right.  I agree that must is too strong there, but I'd fix it by adding
something like as far as you want to keep them.  You must indeed keep
the changelog entry, and it's good that this is emphasized IMO.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)

[Bas Wijnen]

On Sun, May 25, 2008 at 11:05:14AM +0200, Tollef Fog Heen wrote:
 * Bas Wijnen 
 
 | 5.11.1.2 Using the DELAYED/ queue
 
 [...]
 
 | The DELAYED queue should not be used to put additional pressure on the
 | maintainer. In particular, it's important that you are available to
 | cancel or delay the upload before the delay expires (the maintainer
 | cannot cancel the upload himself).
 
 Is there interest in changing this?  Currently, each of the N-day/
 directories are mode 1777, aka «tfheen and owner of file can remove
 file».  If there's interest in it, I'll be happy to make it so anybody
 can remove anybody elses uploads.

I think that would be better, indeed.

 Alternatively, I could have a script that understands dcut commands
 and only acts if it's signed by the owner of the package (maintainer
 or uploader).

Actually, anybody at all (DD only, that is) is better than owner only
IMO.  When it's about NMUs, we're in a situation where external help is
more than a theoretical possibility.  If some other external help wants
to fix a problem with an NMU which is still in the queue, this should be
possible IMO.  Of course all parties (maintainer and previous NMUer)
should be informed, but that need not be automatic.

If this is changed, we should write a paragraph about how and when to do
this in the DEP as well.

Thanks,
Bas

Ps: This e-mail expresses my personal opinion, and is not written with
my driver of this DEP hat on. :-)

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: legal question

[Bas Wijnen]

On Thu, Feb 28, 2008 at 05:29:30PM +0100, Marcos Mayorga wrote:
 Can I use the debian logotype to be little part of my logotype?
 I would like to expose this way my proudness of working with it.

On http://www.debian.org/logos/, it says:

This logo or a modified version may be used by anyone to refer
to the Debian project[...]

In other words, you are allowed to use it when referring to Debian.  If
your company is about Debian (for example, it provides support for
Debian system), then this may be allowed.  However, if this is only to
say I like that project, your own logo is not the proper place to show
this.  On the contrary, it could lead people to think that your company
is Debian-specific while it is not, or worse, people who know your
company before they get to know Debian may think Debian is a spin-off of
your company, or something.

In short, using the Debian logo in your own logo is probably not
allowed, and would lead to confusion for the users.

Only if your company is Debian-specific, which means that people using
your services will always already know Debian (because otherwise the
service is useless to them), then it can be allowed, but I would still
advise against it.  Instead, just use the Debian logo as it is next to
your own logo in appropriate places.  For example, on a website, you
will of course put the company logo.  You can add a Debian logo next to
it, with a line saying you like it.  On paper letters, for example, it
will probably be more useful to only have your company logo.

If I didn't convince you not to use the logo in your logo, then please
consult a lawyer before you actually do so, and note that I am not one.
Also, your question would have been more appropriate for
[EMAIL PROTECTED], so you should probably also ask there.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: RFC: Introducing Debian Enhancement Proposals (DEPs)

[Bas Wijnen]

On Thu, Feb 07, 2008 at 05:35:16PM +0200, Lars Wirzenius wrote:
 On to, 2008-02-07 at 14:40 +0100, Stefano Zacchiroli wrote:
  Overall, I think we are now in a consensus reached situation, we just
  need to implement the missing technicalities and then move on with DEP0
  status.
 
 I agree, more or less. Since DEP0 is a bit of a special case, I think
 that we should do at least a trial run by doing a DEP1 to see if the DEP
 process actually works or not. What would be a good improvement to
 Debian right now?

Lucas Nussbaum and I are working on a proposal for clarifying NMU
procedures.  We shall probably request a DEP number soon.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: violence - take 2

[Bas Wijnen]

On Mon, Feb 04, 2008 at 03:27:51PM +0100, Patrick Frank wrote:
 What you post on this list, Luk Claes as reply to my postings is not
 constructive in any way.

Neither is any of your postings.  Also, you seem to have completely
ignored what I wrote to you in private, which I see as proof that you
are indeed a genuine troll, and your only aim is to keep Debian people
busy.

Since requests to you are appearantly useless, I'll make a request to
the rest of this list.  Shall we all just stop sending *any* response at
all to him?  Remember, if there's no response, that doesn't make him
right, but it may make him stop (eventually).

I have no problem at all with private responses, but they seem to be a
waste of time.

 The same time you are begging listmasters to ban me from this list,

Did he tell you that in private?  Because I didn't see any such request.
Perhaps you were thinking of my private mail to you, because I did
indeed write that it would be a good idea.  However, due to technical
problems with you changing names all the time, I didn't actually make
any request to the list masters, but just asked you to go away.  As did
Frans.  But being a troll, you don't listen to that, of course.

On Mon, Feb 04, 2008 at 04:13:38PM +0100, Patrick Frank wrote:
 Frans Pop [EMAIL PROTECTED] wrote:
  Get lost, will you? Permanently please.
 
 It was transparently visible how you handled your disagreement
 with Sven Luther.

Frans was actually a very good example of someone who kept quite civil
most of the time.  His attitude was admirable.  Sure, he got angry
sometimes.  But most of the time he didn't, and that must have taken
quite an effort given Sven's never-ceasing attacks.

This is actually the reason I'm writing this e-mail to the list: Frans,
I'm proud of how you handled that situation.  It makes me be proud of
Debian that people like you are in it.  Thank you very much.

Thanks,
Bas Wijnen

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: RFC: Introducing Debian Enhancement Proposals (DEPs)

[Bas Wijnen]

On Fri, Jan 18, 2008 at 12:34:42PM +1000, Anthony Towns wrote:
 On Wed, Jan 16, 2008 at 12:18:30PM +0100, Adeodato Sim?? wrote:
  Currently, when having discussions about improvements to Debian, it is
  not always clear when consensus has been reached, and people willing to
  implement it may start too early, [...]
 
 Isn't it useful to have sample implementations before trying to decide
 whether an idea is good or not? PEPs often seem to have patches for the
 feature they're suggesting, before they're accepted.

If people want to do this, it's useful.  The problem that is described
is that people don't actually want to do this, because they don't know
if their solution will be used.  For such situations, it is useful to
have a way to see that there is a rough consensus.

Obviously this doesn't guarantee that the work is used, but it improves
chances, which may be enough to just go and do it.

  Secondly, we lack at the moment a central index in which to list such
  proposals, which would be useful to see at a glance what open fronts
  there are at a given moment in Debian, [...]
 
 bugs.debian.org/ gives us a central index of ways in which Debian should
 be improving, along with all of:

Not the sort of things that DEPs are proposed for IMO.  Or at least it
isn't used as such.  For example, the machine-parsable copyright thing
seems (to me) to be pretty much accepted as a Good Thing, but it's
unclear when it would be a good idea to start suggesting or even
mandating it in policy.

  and who is taking care of them
  and, additionally, to serve as a storage place for successfully
  completed proposals, documenting the outcome of the discussion and the
  details of the implementation.

Also, I disagree that the BTS is a usable storage place for completed
proposals.  Or do you suggest to keep a bug open for things which we
have consensus on?  It would of course be an option, but I like bugs to
be closed, personally.  And IME they are much harder to find when they
are, which makes the system less useful as an archive.

  Workflow
  
  A Debian enhancement can be pretty much any change to Debian,
  technical or otherwise. Examples of situations when the DEP process
  might be or might have been used include:
 
  * Introducing new debian/control fields (Homepage, Vcs-*).
  * Making debian/copyright be machine parseable.
  * Agreeing upon a meta-package name or virtual package name.
 
 These sorts of issues are already tracked with the BTS, for instance when
 they're dealt with by the tech-ctte or -policy.

Right.  The BTS is one place where these things can happen.  In other
cases, other places are used, for example wiki.debian.org, or mailing
lists.  The proposal is as non-invasive as possible and leaves all these
options open.  Implementors can just use whatever they want.  That's
good, because some people will not like the BTS as a medium for this
sort of thing.  The fact that it can do it is irrelevant.  If people
don't like it, they might hold off working on things.  I would prefer to
avoid that.

 Is it really a good idea to merge this is how we run our distribution and
 this is how we organise our project ?

IMO it's fine to use the same process for it (especially because with
this process, we can continue to do things the way we did them before),
but I agree that the actual archive might be split with a section for
each.

  The result of all this is:
1. an implementation of the enhancement and
 
 That's kind of implied by any process that results in changes happening...

Still quite important, because without it the proposal would be
worthless. ;-)

2. a document that can be referred to later on without having to dig
   up and read through large discussions.
 
 What's the benefit of this, as distinct from maintained documentation
 that's distributed with the feature?

Are you suggesting that each new feature must be implemented by one
person (or a small team with lots of communication), and they can then
present the idea including a full implementation with documentation?
That doesn't really sound like how things usually work in Debian.
Normally, IME, people have ideas, people talk about them, there may be
some implementations of solutions, which get changed, and maybe at some
point things are implemented somehow.  All this is fine, except that
during the process, you can't see where you are, and at the end, people
may forget to write proper documentation about it.  Both these
problems are solved by the proposal, without forcing much policy on the
implementors.

 In so far as a DEP is about tracking a feature request, the BTS seems the
 right way to handle it.

No, that would be _a_ right way.  The whole point of DEPs is to not
mandate such a thing.

* this period must be long enough that there is a consensus that the
  enhancement works (on the basis of implementation evaluation)
 
 Adding delays seems to contradict the previous notes about DEPs not
 changing who gets to 

Re: RFC: Introducing Debian Enhancement Proposals (DEPs)

[Bas Wijnen]

On Fri, Jan 18, 2008 at 07:33:41PM +1000, Anthony Towns wrote:
 On Fri, Jan 18, 2008 at 09:12:53AM +0100, Bas Wijnen wrote:
  If people want to do this, it's useful.  The problem that is described
  is that people don't actually want to do this, because they don't know
  if their solution will be used.  
 
 That seems a pretty bad rationale -- implementing your solution (demoing,
 prototyping, whatever) is a first step in convincing people your idea's
 good, not something you do after everyone agrees with you.

It depends on what the idea is.  How about the social committee thing.
AFAIK it's discussed here on -project, but I have no idea what the
current status is.  I think it's something like we want it, we don't
really know how exactly, we also don't know how to elect them.  If
there would be a central document where the current state with respect
to this is recorded, that would be nice.

Also, in case of a long discussion, the BTS isn't really that good a
tool.  The bug log would get enourmous, and people who want to know the
current state and are not interested in the history don't want to read
through the entire log.

That's the sort of thing that is solved here: there should be an url
where people can check how the current proposal is, with a link to the
place to discuss it.  That link can very well point to the BTS if the
drivers want it to.  But let's not force them to do that.  If they
prefer discussing on a mailing list, allow them to do that.  It's all
about let people do what they want, the way they want it, and if others
like it, let them use it.

  Obviously this doesn't guarantee that the work is used, but it improves
  chances, which may be enough to just go and do it.
 
 Sure, getting a second opinion before starting is useful; but you'd do
 that before a DEP anyway?

You'd probably do that a little bit before a DEP, but mostly during the
DRAFT phase, I suppose.  Such as in this case (DEP0), nobody has yet
written anything to deal out the numbers.  I proposed to do it, but I'll
wait to see if we're actually going to do anything like this.  If not,
I'd be wasting my time.

   bugs.debian.org/ gives us a central index of ways in which Debian should
   be improving, along with all of:
  Not the sort of things that DEPs are proposed for IMO.  Or at least it
  isn't used as such.  
 
 It certainly has been in the past.
 
 Reasons to use it again would be: it already exists, it integrates well
 with lots of other things we do in Debian.
 
 Reasons not to use it would be that it doesn't do something that's needed.

I'm not saying (and AFAICS DEP0 isn't either) that we _shouldn't_ use
the BTS.  I'm only saying we shouldn't _mandate_ it.  I like that
approach very much.  Things work pretty well now.  People do things the
way they like.  Some parts could be improved, in particular related to
tracking the current state of an issue and having a document when it's
final.  That's what DEP0 is adding.  And it does this elegantly, without
forcing a new (or old) system on people.

  For example, the machine-parsable copyright thing
  seems (to me) to be pretty much accepted as a Good Thing, but it's
  unclear when it would be a good idea to start suggesting or even
  mandating it in policy.
 
 Well, that's an issue with how -policy is working,

No, it isn't.  Changes in policy shouldn't be made unless there is
consensus that it's a good idea.  We're still at the state that we want
to know if there's consensus.  In this case, proposing a policy change
should not happen before the DEP has at least become CANDIDATE (assuming
that the drivers choose to use the DEP system for it).

 not an issue with the BTS.

No, there isn't an issue with the BTS, as you described it is very
capable of being a medium for discussing a topic.  If it's used for
that, it can even do most thing (if not all) that DEP0 wants to make
sure are always done.  But if someone wants to discuss on a wiki, or a
mailinglist, then that should be possible, too.

Remember that the drivers can choose to ignore the DEP system
completely.  If you want to propose something and use the BTS to track
it, nothing is stopping you.  The DEP system is only intended to provide
you with a way of organising things, not to force it on you.  Since DEPs
have no formal meaning (in that things which are in a DEP can't be used
to tell people what you do wrong, and you must change it, like a GR or
policy can), there's really nothing terrible happening.

  Also, I disagree that the BTS is a usable storage place for completed
  proposals.  [...]
 
 bugs.debian.org/10 is a much more reliable reference for a closed
 report than most wikis, or even mailing lists.

Yes, it's reliable, but not very usable. :-)  The DEP storage should
obviously also be reliable, and for that reason it's using the unique
numbers.  I'm not saying it's more reliable than the BTS.  It's as
reliable.  This is not the reason to use DEPs, it's just not a reason
not to. :-)

  And IME

Re: Re^4: ideas regarding a conflict management strategy

[Bas Wijnen]

Hi,

This is my first and only mail on this subject.

 Subject: Re: Re^4: ideas regarding a conflict management strategy

Why do you start new threads all the time?  It breaks mutt's threaded
view, and it makes sure that your message shows as a new thread.  This
also makes it impossible to ignore the rest of the thread without
specifying that you really want to ignore it with every message from
you.  The only reason I can see for doing this, is that you want to make
sure people don't ignore you, even if they want to.  If that is indeed
the intention, that makes you a spammer IMO.  And thereby even less
sympathetical.

On Fri, Jan 18, 2008 at 10:02:12AM +0100, Lars Versen wrote:
  Right - 20 pages of anything, from someone who doesn't appear to be
  contributing to the community which he insists should change to his
  standards, is not going to be particularly well-received.
 
 Steve Langasek, exactly that is a general misunderstanding of you and
 a few other Debian Developers.  I have three world-class operating
 system releases to my credit, and you dont is cause for respect and
 fame, but it does not justify the attitude, that anybody else has no
 right to voice his opinion, if he cant show up with similar credit.

I can't show similar credit, and Steve doesn't do that to me.  That's
because I do actually do things in Debian.  I wasn't release manager,
and I'm not a maintainer of important packages, but I am active in the
community, and do some things.  The only thing I've seen from you is
e-mails about how to change things.  

You are not listed as the maintainer of any package, I don't know you as
someone who is active in translations or ports or infrastructure.  In
short, I don't know you at all.  You seem to be a total outsider to the
project.  I fully agree with Steve: as an outsider, you should not
expect positive responses to a proposal to radically change the project.
(Although you didn't really do any proposal so far, you just mentioned
some things nobody contested, and complained about being mistreated.)

 Conciousness, awareness, understanding and practise of non-violent
 communication.

I'd like to add one: no useless communication.  Please don't post to a
list if you have nothing useful to say.

 A few smart people with a good understanding of social ethics made up
 the Debian Social Contract. And one of the main points of this Debian
 Social Contract is we will not hide problems and our priorities are
 our users. Thank you for keeping that in mind through all your
 actions.

You seem to read that as you guys promised to do anything any user
asks.  Guess what?  That's not what we think it means.

 What is the point of making software that does not discriminate other
 people, but the behaviour of several Debian Developers does?

Who is discriminating, on what grounds, and how is that unacceptable?
Do you mean Steve shouldn't be allowed to tell you that you're annoying,
because he doesn't tell others the same thing?  If so, get serious.

 Why do some people use that self confidence against small people like
 me, instead of trying to catch the message that I try to voice?

Because Debian is driven by a community.  People who do things tend to
be taken more seriously, especially when it is about large changes.

If you really want to help make Debian better, you should start by
getting involved.  Build packages, for example.  As long as you're not
willing to do actual work, don't expect people to welcome your advice
about changing Debian.

That's all I have to say about this.  If you want a reply from me,
please post off-list.  I shall not reply to anything which is (also)
sent to the list.  And certainly not if it's sent as a new thread.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: RFC: Introducing Debian Enhancement Proposals (DEPs)

[Bas Wijnen]

On Thu, Jan 17, 2008 at 09:18:22AM +0100, Stefano Zacchiroli wrote:
 In the current proposal d-project is only used as a global mutual
 exclusion tool to get the next available number in the DEP namespace, no
 other announcement purpose is intended for d-project.

 The underlying overall idea is that the DEP process should not change
 the way in which the discussions are carried on in Debian, but just give
 a tool to keep track of what is happening / has happened. So, the
 announcement device to be used is the one that the driver would have
 used if the DEP process did not exist at all. The less constraints added
 by DEPs, the better :-)

I think using the list only as a mutual exclusion tool is good, for the
reasons you mention.  However, for the mutual exclusion to work
smoothly, it would probably be better to mail through a proxy, as Sven
proposed.  I'm thinking of sending a mail there with the DEP header, but
with the version set to an invalid value (TO-BE-ASSIGNED for example).
Then the proxy will insert its next number in there and send the result
to the list, and to the submitter (the submitter will get it twice, but
the direct reply may be much faster, which is good for the I want to do
everything right now sort of people).  If the mail isn't a proper DEP
header, it should probably bounce (or be ignored if too much traffic is
generated, to avoid it being used for spam).

If people like the idea, I can write something to do this.

With the requirement that DEPs mention where the discussion will take
place, this can be the only mail about that DEP going to -project.

 If people find that such a bootstrap announcement is needed we can go
 for it, but given that an automatic publishing system would exists for
 the DEP, we can even subscribe d-d-a to a RSS feed of the DEP page or
 something like that, but maybe is too early for this.

Subscribing d-d-a to anything sounds like a very bad idea to me...

About my idea of splitting ACCEPTED into historical and current, this
may actually be what OBSOLETE was meant for.  I thought OBSOLETE was
only to be used for DEPs which have a new version after they got
ACCEPTED.  However, if OBSOLETE is also used for DEPS which are
implemented in policy, for example, then there is no reason to split the
ACCEPTED DEPs, I think.  The current ones are then simply all ACCEPTED
ones.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: RFC: Introducing Debian Enhancement Proposals (DEPs)

[Bas Wijnen]

Hi,

On Wed, Jan 16, 2008 at 12:18:30PM +0100, Adeodato Simó wrote:
 Lars Wirzenius, Stefano Zacchiroli and myself are trying to introduce
 the concept of Debian Enhancement Proposals,

Very good idea!

I have some minor comments:

 As the discussion progresses, the enhancement is assigned certain
 states, as explaned below.
s/explaned/explained/

Assuming that the number of DEPs will be significant, I think it would
be a good idea to separate ACCEPTED DEPs into two groups, namely
historical which nobody needs to read, because their text is included
in some authorative document (policy, devref, whatever) and current,
which may be useful to read because they aren't included anywhere (DEP0
will probably stay there, for example).

 If the drivers go missing in action, other people may step in and
 courteously take over the driving position.
People should also be allowed to help the drivers if they don't go MIA.
;-)  Well, only if the current drivers allow them to, of course.

I'd add a suggestion that during the discussion the URL of the DEP
should be mentioned all the time.  That means in every mailing list
post, in the topic of an IRC channel (or in a message at the start of
the discussion, if the channel topic is about much more than the DEP),
etc.  This should of course only be a suggestion, since the drivers
aren't the people who control this.

I agree with the comment that the initial announcement should mention
the forum which will initially be used for discussing the DEP.  Of
course this may change, and in practice several media may be used
simultaneously, but it's good to at least start at the same place. :-)

Finally, about the comments that the announcement should be made to
d-d-a.  I think it would be good to mention that this is possible, but
it shouldn't recommend it IMO.  The idea I get about DEPs is that they
aren't always important enough for d-d-a, and in general I'm very
reluctant to make it a rule to post announcements there, because it
should be a low-traffic mailinglist, and you never know how much traffic
such a rule would generate.  However, suggesting that it is an option
that the drivers should think about is a good idea IMO.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)

[Bas Wijnen]

On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote:
 On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote:
  Another thing we could do is alert sponsors about checking for lintian
  overrides when they review a package.
 
   or we could disallow the override of = E: errors in lintian, and make
 lintian reboot your computer, fill your gpg with /dev/random bits, and
 install windows over your Debian if you override such errors.

Interesting idea.  I'd prefer to use a bit softer approach, if only
because I wouldn't want to push our developers (DD or not) to non-free
software, even if they misbehave. ;-)

How about letting lintian report all messages always, with an extra note
for overrides?  Like this[0]:

I: Override installed for the following message:
I: W: pioneers binary: binary-without-manpage usr/games/pioneers-editor

With -i, the first line should expand to something like:

I: Override installed for the following message:
I: The maintainer installed an override for the following error.  This
I: means that lintian is wrong about this, and there is nothing wrong
I: with the package.

Or perhaps a little less maintainer-friendly, suggesting that the
override could be incorrect. :-)

AFAIK there are three solutions for handling a lintian message:
- If the package is indeed broken, fix it.  The most usual.
- If lintian is broken, report a bug and/or fix it and submit a patch.
  In the mean time, ignore the message.  Not so usual.
- If lintian is not right, but this is such a weird cornercase that it
  is not reasonable to expect that, install an override.  Very unusual.

This means that lintian overrides should be very rare.  And it is no
problem to get messages like above for them.

Thanks,
Bas

[0] Ok, this is not something that should be overridden, but I wanted to
use my own package, and I don't think I have any overrides installed
anywhere.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: linhdd concerns

[Bas Wijnen]

On Mon, Nov 26, 2007 at 11:38:06PM -0800, Steve Langasek wrote:
 On Mon, Nov 26, 2007 at 09:51:35PM +0100, Leo costela Antunes wrote:
  What information does linhdd need from fdisk?
  Fdisk seems to run just fine as a normal user on Debian. The issues
  seems to be that /dev/{s,h}d* are directly readable only by members of
  the group 'disk'.
  Perhaps instead of packaging this 'abs_fdisk', which AFAICT is just a
  read-only non-root fdisk, you could just create a setuid wrapper to
  the normal fdisk and use it from linhdd?
 
 No, that would be a security hole.  Even making it setgid disk would be a
 security hole, since the disk group has write access to all disk devices.

The idea of the wrapper would of course be that it would only allow read
access, so the write access is not a problem.

If I understand the case correctly, abs_fdisk is a modified read-only
setuid root version of fdisk, which is used by linhdd to get some info
which is also available to everyone under /proc.  Providing this info is
obviously not a security problem (as long as abs_fdisk is not buggy).
However, a read-only version of fdisk can likely get much more info
than just what is available in /proc.  The fact that linhdd doesn't use
that doesn't make it unavailable.  It seems to me that this approach
introduces security issues (allowing read access that shouldn't be
allowed, plus an extra setuid root (or setgid disk) binary which must
not be buggy) that should better be avoided.

Would it be very hard to write a script which does the same as abs_fdisk
(and can be used as a drop-in replacement), but gets its info from
/proc, and doesn't need elevated permissions?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Updated Debian Maintainers Keyring

[Bas Wijnen]

On Wed, Nov 21, 2007 at 11:36:04AM +0100, Pierre Habouzit wrote:
  In the future, it would be nice if these mails could also specify which
  packages the DMs are allowed to upload.
 
   OTOH this is a moving target, as the DM-keyring maintainers are not
 the ones dealing with that, but the sponsors.

DM is meant for people who are already uploading packages through
sponsors.  So at first the packages they'll be uploading will be (at
most) the ones they already are in the uploader list for.
DM-Upload-Allowed may of course not yet be set.

A list of packages with their name on it would be useful IMO.  This is
not to be mistaken for what they are allowed to upload now (assuming
they have DM status), and it's not what they may in the future be
allowed to upload (which is everything).

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

NM process, AMs, advocates, mentors and applicants

[Bas Wijnen]

On Tue, Nov 20, 2007 at 10:51:07AM +, MJ Ray wrote:
 In short, the above is a symptom of a misstructured NM process.

No it isn't, it's the inevitable result of dealing with people.  You
just can't put every test you want to do in strict rules, you need
people to look at it and see what was meant.

 Current NM tests the AM [...] way too much.

And thus this cannot be avoided.  There shouldn't be a problem with it
anyway, since every DD (and therefore every AM) should be able to pass
the NM process without problems.

Testing the AM is a side-effect, which is not the purpose of the tests,
but there is no problem with it.

 Reform NM: mentor-advocates should teach their applicants and help
 them to produce a file demonstrating that they possess all the
 required DD skills; the AM should then check for any gaps (temporarily
 rejecting if needed) and test the applicant, recording the test; then
 that portfolio and test results are passed to FD and on to DAM, in a
 verifiable, effective, timely and appropriate process.

I have an idea.  Let's split mentor-advocate and add the mentor function
to the AM.  You know what?  You seem to have described the current
process.  The file you're talking about is known as the private AM
report.

Which also means it has all the same problems (not that I agree that
it is a problem, but let's assume for a moment that it is): When doing
these tests, we're also testing the mentor-advocate, not only the
applicant.

The split of AM and mentor may be useful, but there doesn't seem to be
much need for it.  At least AFAICS the problem with NM is mostly at the
waiting for DAM to create account stage.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature