Re: [all candidates] Return to the desert island (cont.)

[Thomas Goirand]

On 03/21/2013 02:02 PM, Thomas Goirand wrote:
> On 03/21/2013 11:52 AM, Michael Gilbert wrote:
>> I think the outcome of moving a package that falls in the "requires
>> external stuff" from main to contrib would rarely qualify as silly.
>>
>> Take for example the twitter perl packages.  The API is changing (of
>> course that is something outside of Debian's control,).  As a
>> consequence, those packages are now up for removal from testing (since
>> they're going to be broken for an entire stable release):
>> http://bugs.debian.org/703257
>>
>> If instead those packages were in contrib, which is of course
>> considered not supported, if/when those external interfaces break,
>> then at least the user knew upfront that they were taking a risk that
>> their unsupported software may someday break.  Part of the nuance is
>> living up to user expectations.
> 
> Would you put something like Pidgin in contrib? And to make sure you
> wont dismiss my point and answer that it has support for XMPP wich is an
> open protocol: and what if it had only support for the non-free
> protocols, like only MSN, AIM, Yahoo and such, and zero support for the
> open protocols like IRC and XMPP?

I withdraw this, pidgin-facebookchat is a better example... :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514aa3a4.3080...@debian.org

Re: [all candidates] Return to the desert island (cont.)

[Thomas Goirand]

On 03/21/2013 11:52 AM, Michael Gilbert wrote:
> I think the outcome of moving a package that falls in the "requires
> external stuff" from main to contrib would rarely qualify as silly.
> 
> Take for example the twitter perl packages.  The API is changing (of
> course that is something outside of Debian's control,).  As a
> consequence, those packages are now up for removal from testing (since
> they're going to be broken for an entire stable release):
> http://bugs.debian.org/703257
> 
> If instead those packages were in contrib, which is of course
> considered not supported, if/when those external interfaces break,
> then at least the user knew upfront that they were taking a risk that
> their unsupported software may someday break.  Part of the nuance is
> living up to user expectations.

Would you put something like Pidgin in contrib? And to make sure you
wont dismiss my point and answer that it has support for XMPP wich is an
open protocol: and what if it had only support for the non-free
protocols, like only MSN, AIM, Yahoo and such, and zero support for the
open protocols like IRC and XMPP?

Thomas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514aa292.2030...@debian.org

Re: [all candidates] Return to the desert island (cont.)

[Charles Plessy]

Hi all,

I propose that either the discussion is reshaped to be more interactive with
the candidates, or it is moved to another channel where a broader participation
is expected.

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130321035944.ga20...@falafel.plessy.net

Re: [all candidates] Return to the desert island (cont.)

[Michael Gilbert]

On Wed, Mar 20, 2013 at 10:35 AM, Russ Allbery  wrote:
> Bart Martens  writes:
>> On Tue, Mar 19, 2013 at 05:09:00PM -0700, Russ Allbery wrote:
>
>>> note that free software interfaces to proprietary cloud platforms are
>>> frequently used to manipulate the data in those platforms including
>>> pull data *out* of those platforms.  It would be quite ironic if we
>>> refused to include in the distribution the tools required to pull one's
>>> data out of non-free platforms.
>
>> An interface to facebook or to twitter or to the internet movie database
>> or to websites with stock quotes may be freely redistributed but
>> "requires software outside of the distribution to function".  Why do we
>> make exceptions depending on how "ironic" things are ?
>
> Because, similar to how all evil plans for taking over the world should be
> run past a fifth grader first, all grand principles of ideology should be
> checked for whether their actual outcomes are silly.

I think the outcome of moving a package that falls in the "requires
external stuff" from main to contrib would rarely qualify as silly.

Take for example the twitter perl packages.  The API is changing (of
course that is something outside of Debian's control,).  As a
consequence, those packages are now up for removal from testing (since
they're going to be broken for an entire stable release):
http://bugs.debian.org/703257

If instead those packages were in contrib, which is of course
considered not supported, if/when those external interfaces break,
then at least the user knew upfront that they were taking a risk that
their unsupported software may someday break.  Part of the nuance is
living up to user expectations.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mpg5d8_dbrmrttrc8p7awvqkm8kwa0nwrn5agqh_bk...@mail.gmail.com

Re: [all candidates] how to choose Jessie init system

[Moray Allan]

On 2013-03-18 15:55, Stefano Zacchiroli wrote:

How do we make an inherently archive-wide technical decision when
multiple, possibly equally valid solutions do exist?

(I think the latter part, the existence of alternatives, is 
particularly

important here, as we have well-established approaches for other
cases. For instance, when one of the alternative is clearly superior, 
we

usually apply some sort of "Debian's Darwinism": we wait for it to be
popular enough, we make it increasingly more mandatory in Policy or 
the

Release Team pick it as release goal, we do NMUs, etc.)


1. Communication before decision-making

Problems in making decisions often come from the early stages of the 
relevant discussions.  For example, this can happen if the early 
discussion didn't include all the stakeholders, so that some feel 
excluded, or because it launches straight into nitpicking of alternative 
proposals before they are fully-formed.  In any discussion that starts 
by people directly arguing what the conclusion should be, few of them 
will back away from their publicly stated positions later on, even if 
facts emerge that would have otherwise led them to a different 
conclusion.


Openness

In Debian, people can't be *forced* to involve themselves in a 
discussion where they're a stakeholder, but it helps to make sure it is 
on the right list, that it's not buried in the middle of an unrelated 
thread, and that relevant people are pinged if they don't speak of their 
own accord.  When someone wants to move a specific topic forward, it's 
often better to explicitly call for opinions and ideas before announcing 
their own proposal -- and, of course, they should try to be genuinely 
open to ideas from others.  Or already at this stage they can recruit 
someone neutral (which could sometimes mean the DPL) to do this and 
coordinate the discussion process.


Communication

Nitpicking is natural in online asynchronous discussions, but we can 
still try to avoid this taking over the discussion.  It can help if 
people actively discourage comparing alternative proposed options with 
each other at all in the initial phases of discussion, and instead 
encourage people to help improve the content and form of each proposal 
separately.  It is better if each proposal is first challenged in 
isolation, to see if it covers the necessary details, has a sufficiently 
good transition plan, etc., before discussion moves to comparing the 
proposed options with each other.


Once there is, for example, a wiki page describing each proposal that 
e.g. includes enough detail and has a good transition plan, people can 
constructively move to comparing the alternatives, hopefully keeping 
questions of technical superiority separate from debating the actual 
form of the proposals.  But still, rather than free form discussion, it 
may be better to compile in the wiki lists of arguments for and against 
each proposal.  And the intention should be to make the descriptions 
better, rather than to win an argument -- people should try to list the 
disadvantages of their own proposals, and the advantages of others'.


Transparency

When there is reasonable agreement on a set of alternative proposals, 
and on arguments for and against each, there can still be significant 
disagreement on how to weight the different factors and reach a final 
decision.  But any decision reached at this point is likely to be much 
more informed than one made through a discussion where people publicly 
took sides and argued loudly for their preferred option from the start.



2. Decision-making for system-wide choices

Firstly, in this kind of debate I don't think the DPL should argue for 
or against specific solutions, but should seek to push discussions 
forward neutrally, trying to make them progress usefully towards 
positive conclusions.


For any technical decision, it's certainly not the Debian way to choose 
a new tool merely because its features sound promising or because people 
are arguing loudly about how some options might or might not work.  Even 
for something where only one choice will be implemented widely, I would 
expect to see a test implementation of each proposed option before one 
is chosen.  In some cases this will be in packages in the main archive; 
in other cases it may require a forked copy of some packages.  (Better 
PPA-type infrastructure, and more standardised VCS workflows, could help 
here.)


Often, there will be a clear consensus winner by the time that working 
implementations are ready, at least among the major technical 
stakeholders.  In many cases the release team can push progress on a 
transition, or the d-i team can decide to switch new installations to a 
new default.  In these kinds of cases the DPL and others may be able to 
help discussion along, but shouldn't seek to take ownership of it.


In a few cases, there will be no consensus winner, for example where 
technical and non-technical preferences clash.  Or we may

Re: [all candidates] Return to the desert island (cont.)

[Russ Allbery]

Bart Martens  writes:
> On Wed, Mar 20, 2013 at 07:35:19AM -0700, Russ Allbery wrote:
>> Bart Martens  writes:
>>> On Tue, Mar 19, 2013 at 05:09:00PM -0700, Russ Allbery wrote:

 note that free software interfaces to proprietary cloud platforms are
 frequently used to manipulate the data in those platforms including
 pull data *out* of those platforms.  It would be quite ironic if we
 refused to include in the distribution the tools required to pull
 one's data out of non-free platforms.

>>> An interface to facebook or to twitter or to the internet movie
>>> database or to websites with stock quotes may be freely redistributed
>>> but "requires software outside of the distribution to function".  Why
>>> do we make exceptions depending on how "ironic" things are ?

>> Because, similar to how all evil plans for taking over the world should
>> be run past a fifth grader first, all grand principles of ideology
>> should be checked for whether their actual outcomes are silly.

> Which is why I'm open to change debian-policy or move packages from main
> to contrib depending on what's the least silly.

Good point.  :)  Sorry, I was being too snarky.  Although changing the
wording is, I think, a bit more complicated; I commented in a different
part of the thread.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjxxepre@windlord.stanford.edu

Re: [all candidates] Return to the desert island (cont.)

[Russ Allbery]

Jérémy Bobbio  writes:

> I'll need to come up with other tools to think about the danger about
> freedom I perceive from the “cloud”…

For the record, I think most of us are on the same page about the danger.
I certainly agree with your concern; I'm just not sure that the
organization of the Debian archive is an effective way to try to address
that danger.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874ng5g4d5@windlord.stanford.edu

Re: [all candidates] Return to the desert island (cont.)

[Russ Allbery]

Bart Martens  writes:
> On Wed, Mar 20, 2013 at 09:27:58AM +0100, Wouter Verhelst wrote:

>> You can use pidgin-facebookchat to talk to a non-free service; but
>> whatever you do, the result will *never* be that you end up with a
>> system which has some non-DFSG-free software installed. As such, I
>> don't think it's necessary that you not be able to reach this on a
>> system that only has "main" enabled.

That's my interpretation as well.

> OK, you seem to draw the line where non-free is installed or not on the
> local system.  That makes somewhat sense to me.  But then the part
> "which require software outside of the distribution to either build or
> function" in debian-policy should be replaced by something like "which
> causes software outside of the distribution to be installed on the local
> system".

I don't consider Policy canonical for this wording.  If we're going to
make a change to Policy, I would prefer to remove Policy's attempted
elaboration and just copy the language verbatim from the Social Contract.
It's the Social Contract that is canonical, and I think any updates should
be done via updates to the Social Contract.  I'm very uncomfortable with
attempting to deal with something this politically sensitive via the
Policy process.

contrib software satisfies the DFSG, so the relevant portion of the Social
Contract is point #1:

We provide the guidelines that we use to determine if a work is "free"
in the document entitled "The Debian Free Software Guidelines".  We
promise that the Debian system and all its components will be free
according to these guidelines.  We will support people who create or
use both free and non-free works on Debian.  We will never make the
system require the use of a non-free component.

The debate is therefore over what "require the use of" means.  I think one
can make an argument that an installer package that automatically
downloads and installs non-free software does "require the use of" that
non-free software, although it's sort of a weird definition of "use"
(since it doesn't actually require that you USE the Flash plugin; it's
just sitting on your disk).  I think that argument gets weaker and weaker
for software that interfaces with external services; in that case, not
only is the "require the use of" part debatable, so is the "component"
part.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878v5hg4gr@windlord.stanford.edu

Re: All candidates: Development and technical issues and challenges

[gregor herrmann]

On Wed, 20 Mar 2013 01:15:58 -0400, Michael Gilbert wrote:

> Even the suggestion of a testing removal can evoke negative feelings
> for those affected (sometimes from those on the sidelines too).  A
> recent example:
> http://bugs.debian.org/703258

There seems to be a misunderstanding; at least my surprise was not
caused by the proposal to remove the package from testing (actually,
I mentioned this as the most probably option in my first mail in the
original bug report), but by the fact that I wouldn't have known
about the removal bug without the later CC by Jonathan.
 
> Do you have any thoughts on addressing the social aspect of this
> approach?

In this case, "X-Debbugs-Cc: $original_bug|$maintainer_address" would
have been enough :)


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Jimi Hendrix: Message To Love


signature.asc
Description: Digital signature

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Wed, Mar 20, 2013 at 07:35:19AM -0700, Russ Allbery wrote:
> Bart Martens  writes:
> > On Tue, Mar 19, 2013 at 05:09:00PM -0700, Russ Allbery wrote:
> 
> >> note that free software interfaces to proprietary cloud platforms are
> >> frequently used to manipulate the data in those platforms including
> >> pull data *out* of those platforms.  It would be quite ironic if we
> >> refused to include in the distribution the tools required to pull one's
> >> data out of non-free platforms.
> 
> > An interface to facebook or to twitter or to the internet movie database
> > or to websites with stock quotes may be freely redistributed but
> > "requires software outside of the distribution to function".  Why do we
> > make exceptions depending on how "ironic" things are ?
> 
> Because, similar to how all evil plans for taking over the world should be
> run past a fifth grader first, all grand principles of ideology should be
> checked for whether their actual outcomes are silly.

Which is why I'm open to change debian-policy or move packages from main to
contrib depending on what's the least silly.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130320180025.gf28...@master.debian.org

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Wed, Mar 20, 2013 at 09:27:58AM +0100, Wouter Verhelst wrote:
> You can use flashplugin-nonfree to download a piece of software that has
> a nonfree license, which is then installed on your system; the result is
> that you now have a system which has some non-DFSG-free software
> installed. To be able to reach this situation on a system that only has
> "main" enabled would be utterly wrong.
> 
> You can use pidgin-facebookchat to talk to a non-free service; but
> whatever you do, the result will *never* be that you end up with a
> system which has some non-DFSG-free software installed. As such, I don't
> think it's necessary that you not be able to reach this on a system that
> only has "main" enabled.

OK, you seem to draw the line where non-free is installed or not on the local
system.  That makes somewhat sense to me.  But then the part "which require
software outside of the distribution to either build or function" in
debian-policy should be replaced by something like "which causes software
outside of the distribution to be installed on the local system".

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130320175556.ge28...@master.debian.org

Re: [all candidates] Return to the desert island (cont.)

[Russ Allbery]

Bart Martens  writes:
> On Tue, Mar 19, 2013 at 05:09:00PM -0700, Russ Allbery wrote:

>> note that free software interfaces to proprietary cloud platforms are
>> frequently used to manipulate the data in those platforms including
>> pull data *out* of those platforms.  It would be quite ironic if we
>> refused to include in the distribution the tools required to pull one's
>> data out of non-free platforms.

> An interface to facebook or to twitter or to the internet movie database
> or to websites with stock quotes may be freely redistributed but
> "requires software outside of the distribution to function".  Why do we
> make exceptions depending on how "ironic" things are ?

Because, similar to how all evil plans for taking over the world should be
run past a fifth grader first, all grand principles of ideology should be
checked for whether their actual outcomes are silly.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vc8mqguw@windlord.stanford.edu

Re: All candidates: Development and technical issues and challenges

[Lucas Nussbaum]

On 20/03/13 at 01:15 -0400, Michael Gilbert wrote:
> On Tue, Mar 19, 2013 at 3:14 AM, Lucas Nussbaum wrote:
> >> Maybe we could discriminate on the package's priorities. For example,
> >> about a third of the 49 packages *really* blocking the release (not
> >> waiting for a transition) are from "extra"[2]. Only 5 bugs affect
> >> required, important or standard packages. We could focus on those and
> >> tell the "extra packages" to hurry up or be shipped with packages that
> >> will need to be fixed in a point release... or simply removed.
> >
> > That's something I already commented on in
> > https://lists.debian.org/debian-vote/2013/03/msg00020.html:
> >
> >Another possible area of improvement is the focusing on the more
> >important RC bugs. One way to achieve that would be to remove as many
> >leaf/not-so-popular packages as possible at the start of the freeze.
> >If they get fixed, they could get back in.
> 
> Even the suggestion of a testing removal can evoke negative feelings
> for those affected (sometimes from those on the sidelines too).  A
> recent example:
> http://bugs.debian.org/703258
> 
> Do you have any thoughts on addressing the social aspect of this
> approach?  In actuality, a testing removal is really not a big deal
> since the package can come right back once the RC bug is fixed.  Even
> so, some see removals as a kind of judgement on themselves as
> maintainer.  What can be said or done to qualm the fear and anxiety?

It is the release team's role to decide what's inside testing, and I
think that it's important to respect that.

However, I can understand that reaction:
> I also really dislike your recent habit of making discussions hard to
> follow by opening new bugs. Please keep things in one place so everyone
> can follow along.
(even if the tone is very wrong)

Maybe we should generalize the use of the BTS' "affects" feature so that
such bugs are properly "linked" to the original package?

Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130320110103.ga29...@xanadu.blop.info

Re: [to all candidates] Free Software challenges and Debian role

[Lucas Nussbaum]

(I still hadn't replied to that question -- I'll do that by following-up
on Moray's reply since I agree with most of it)

On 12/03/13 at 17:11 +0300, Moray Allan wrote:
> [...]
> 
> - End-users are moving to web applications/"the cloud".  Few of the
> most heavily used ones are free software.  Even if they are,
> centralised web applications remove users' ability to modify
> software to their own needs unless they duplicate a large amount of
> infrastructure.  And in many cases cloud services reduce users'
> control even over their data itself, not just over the platform.  We
> used to have trouble with the network effect of e.g. Microsoft
> Office file formats, but free-of-charge web applications can be even
> worse for free software, since objectors need to argue an
> ideological point to say why they want information in another way,
> rather than only explain that they haven't bought that piece of
> software or that it won't work on their OS.
> 
> - Server users are also migrating to "the cloud".  In many cases
> this means that their services move to sit on a non-free platform,
> and it often reduces ease of modification even in free parts of the
> platform.

Note that in that case, the cloud is also a great opportunity for us,
since most IaaS clouds users use them with free software. So the Cloud
tends to reinforce the position of libre operating systems for server
OS.

Which brings me to another challenge that was not mentioned by Moray:
the increased "commoditization" of software. Increasingly, free software
becomes one of the building blocks of locked-in or proprietary software
sets.  That applies to e.g. Android or to public Clouds, where most of
the infrastructure is based on free software, but where the final user
has no awareness of that.

Lucas


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130320084302.ga22...@xanadu.blop.info

Re: [to all candidates] Accessible software in Debian

[Gergely Nagy]

Hi!

Mario Lang  writes:

> I'd like to know your opinion on this.  Are people with disabilities
> something that we want to support, or is it just luck if "they" get a
> working system.  As a Free Software community, should we make sure that
> the digital divide is not going to increase, or is accessibility just
> margin topic which we as a community do not really care about?

Accessibility is more important than most people realise, yet, it is
also a very hard thing to get right when one has a hard time imagining
how accessibility features would be/are used by the people they were
designed for. My experience is that until you *had* to use a system this
way, you'll just be poking around trying to accidentally get something
right.

So the lack of manpower in the field hurts even more than the lack of it
elsewhere.

> If you think we should make sure to provide maximum accessibility to our
> users, do you have any idea what to do to ensure that?

I'm not sure we can ensure anything - not within the scope of a
volunteer project. What we can do, however, is making damned sure that
accessibility is cared about. I believe many people would like to
support accessibility in their projects much better than they do now,
but without enough manpower, it's not going to happen soon. They need
people who understand accessibility, who can test the software, or tell
whether an idea is useless from an accessibility point of view or not.

We need better communication, and more people motivated to help. I do
have a couple of ideas how we could attempt to motivate - but we must
keep in mind, that in the end, we do not want accessibility to be a
Debian-only development, we want to take the task upstream. (If it
originates from Debian, if we 'lend' our human resources to upstream,
that's great, but whatever we come up with, has to go upstream.)

> Do you have any ideas what we could do to raise awareness of
> accessibility issues, and maybe motivate developers who are currently
> not into accessibiility work in any way, to start caring about various
> issues around accessibility for people with disabilities.

I do have a couple, yes, but I don't want to sound extremely stupid, and
would rather consult with someone who understands accessibility first,
before I write down the ideas.

Nevertheless, the basic driving force behind my ideas is positioning
accessibility as an area where work is in high demand, is very
rewarding, and can be learned. How? Meet with people. Tell people. Show
people. For example, an accessibility workshop at DebConf would be a
reasonable way to gather feedback from package maintainers, users within
our developer community, and we could proceed from there.

Furthermore, we have a thing called "Invisible Exhibition" here in
Hungary, an exhibition of sorts, where the goal is to have a blind guide
guide the visitors through the exhibition, in complete darkness,
teaching them to rely on touch, hearing and smelling, and discover the
world of the blind, first hand. They're shown and taught situations,
simple things like paying for a cup of coffee at a restaurant. It is a
very popular exhibition, and I think it's an amazingly useful one too.

We could adapt a similar idea, and have sessions at the Debian booth in
various conferences, teaching visitors how people with accessibilities
use computer systems (and Debian in particular). I've seen blind people
work with computers, and I was astonished: they used it more effectively
than I did. That was kind of a revelation, to be honest: why would
*they* be disabled, when it is I, who is inefficient? Finding oneself in
a similar situation is a real eye opener.

We should open more eyes. We have a fair number of people within the
project who could help us with that, if elected DPL, I'd do my best to
support them in doing so, even if, to open our eyes, we'd need to close
them shut first.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d2uu9zed@galadriel.madhouse-project.org

Re: To all candidates: which way out of the project ?

[Gergely Nagy]

Charles Plessy  writes:

> In Debian, we stay member until we die or quit (or very exceptionally, are
> expelled).  The consequence is that it is hard to evaluate how much active
> members we have.  It may also create more crispations about giving membership.
>
> We often discussed about how to become a member, but more rarely about the
> other side of it. I would be interested to read your opinion, especially on 
> the
> implications that the current practice, or possible changes, have for the
> project as a whole.

Inactive members can also be caught red-handed by way of the MIA team,
as Cyril and Lucas mentioned already.

I belive we do not need any more exits than what we already have:

 * People can gracefully retire completely
 * People can opt to become Emeritus
 * People can leave the project by natural means
 * People can be expelled
 * People can become inactive and spotted via MIA, and dealt with
   according to the MIA policies.

That's plenty of ways already, pretty much all bases covered. We should,
perhaps, be a bit more aggressive with MIA checks at times, but that
does not really need any big sweeping changes within the project.

Right now, uncaught inactive members are not much of a burden, except
for having an active account, with all of its security and other
implications.

Do you see a particular problem, or shortcoming, perhaps, that you'd
like to see solved?

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3p2a0uj@galadriel.madhouse-project.org

Re: [all candidates] Return to the desert island (cont.)

[Jérémy Bobbio]

Steve Langasek:
> On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote:
> > 3. One test I've been taught to use to reason about free software is the
> >Desert Island test [2] which starts by:
>
> >  Imagine a castaway on a desert island with a solar-powered
> >  computer.
>
> >   Obviously, software that are only frontends to unreproducible “cloud”
> >   services do not pass the desert island test.
>
> This is a mischaracterization of the "Desert Island test" as it was
> formulated on debian-legal.  The Desert Island test is about whether a user
> can *comply with the license* of the software on a desert island when they
> have no contact with the outside world.

Thanks for the correcting my runaway thoughts. :)

I'll need to come up with other tools to think about the danger
about freedom I perceive from the “cloud”…

-- 
Jérémy Bobbio.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: [all candidates] Return to the desert island (cont.)

[Wouter Verhelst]

Hi Bart,

On 20-03-13 07:47, Bart Martens wrote:
> On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote:
>> Dear candidates, do you think that libechonest [3] should be called free
>> software? As it requires software outside of the distribution to
>> function, do you think it should be moved to contrib? What about
>> s3cmd [4] then?
>> [3] 
>> [4] 
> 
> Good question.  See also for example bug 681659.  I don't know why
> pidgin-facebookchat would belong in section main while flashplugin-nonfree
> would belong section contrib.

You can use flashplugin-nonfree to download a piece of software that has
a nonfree license, which is then installed on your system; the result is
that you now have a system which has some non-DFSG-free software
installed. To be able to reach this situation on a system that only has
"main" enabled would be utterly wrong.

You can use pidgin-facebookchat to talk to a non-free service; but
whatever you do, the result will *never* be that you end up with a
system which has some non-DFSG-free software installed. As such, I don't
think it's necessary that you not be able to reach this on a system that
only has "main" enabled.

-- 
Copyshops should do vouchers. So that next time some bureaucracy
requires you to mail a form in triplicate, you can mail it just once,
add a voucher, and save on postage.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5149730e.80...@uter.be

Re: [all candidates] Advertising testing and security support

[Thijs Kinkhorst]

On Tue, March 19, 2013 23:52, Jérémy Bobbio wrote:
> Do you have ideas on how to attract more volunteers to the dull, hard,
> and sometimes boring tasks of taking care of security issues in Debian?

Perhaps it would be useful if we tried not to scare people away with
mischaracterizations that the work would be "dull", "hard" or "boring", or
even all those at the same time.


Thijs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/66898070506be3c77db51de77c85237f.squir...@aphrodite.kinkhorst.nl

Re: [all candidates] Return to the desert island (cont.)

[Wouter Verhelst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 20-03-13 00:46, Steve Langasek wrote:
> On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote:
>> 3. One test I've been taught to use to reason about free software
>> is the Desert Island test [2] which starts by:
> 
>> Imagine a castaway on a desert island with a solar-powered 
>> computer.
> 
>> Obviously, software that are only frontends to unreproducible
>> “cloud” services do not pass the desert island test.
> 
> This is a mischaracterization of the "Desert Island test" as it
> was formulated on debian-legal.  The Desert Island test is about
> whether a user can *comply with the license* of the software on a
> desert island when they have no contact with the outside world.
> That the software may not be *useful* to them on a desert island is
> a separate question, and applies to many sorts of software, not
> just those used for connecting to particular services over the
> Internet.

To make this easier to understand, I find it's useful to remember that
while the "Desert Island" test is a useful tool in making a quick
determination of the DFSG-freeness of a piece of software, it is not
part of the DFSG and therefore is not authoritative in deciding
whether software is free. Only the DFSG is.

A piece of software that fails the "Desert Island" test usually fails
a combination of DFSG1 (free redistribution) and DFSG3 (derived
works): if you need to talk to the original author and/or request
permission to use and/or modify the software, there is no free
redistribution and there isn't really a right to make derived works.
Depending on the actual terms of the license, it *may* also fail DFSG2
(source code), which explicitly states "...must allow distribution in
source code as well as compiled form", which again may be problematic
if permission needs to be requested.

If a piece of software appears to fail the "Desert Island" test but
does not fail any of those parts of the DFSG, then it probably didn't
fail the "Desert Island" test to begin with.

(and no, before someone falls in that trap, software that fails the
"Desert Island" test does *not* fail DFSG5 (no discrimination against
persons or groups) or DFSG6 (no discrimination against fields of
endeavour) -- these are completely different beasts)

Programs or libraries that only exist as a frontend to a cloud service
do not fail any of the terms of the DFSG as far as I can see, and
therefore should not be moved out of main.

- -- 
Copyshops should do vouchers. So that next time some bureaucracy
requires you to mail a form in triplicate, you can mail it just once,
add a voucher, and save on postage.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJRSWQTAAoJEMKUD5Ub3wqdTRQP/0GkU1kQ8Umo5UzxrSygGAQV
/qkRzXcG0Yrd1k/tvMKjdCQ0hzarcpNcVcDNt0hqfdg2UNiPIYU8Se0mzyVSlMYy
tli2z3/rDf0xmZ4MoxuBoxy1qCoeZu6s1GM7wJq26Hz3fzr5/+DKG76S8MyhF0H+
PH1yIrHH0cFaYkmFQB4wqLtZXszs1SBy6qICWeuBaOdBK1cofpUoJv7GGq3pGLa0
CnCTTkgM/AIv9venSfkcvExJSYE+zvmNU2/VVCHd+4V2BrHpkiNsTLES7vqq2zH5
ovwx77/4mLR+vlvqHphPZsqVnpTcUhwthsaTRFdl3EX1QNU8wRTmZ/rhz9k5U58G
fdp03/wJv1lyXQVuhJ4ke8oSgv4Cj3T+zKWq0iXVO21PVOJnmmf8g5LnF82kSzhL
JxKw4cqZf89S2Nk/RZwUm5fLCKYBDD9laGyg7UEIX8Y/Tt3BEqqGgqkpO9uhjK/G
1l372WFpNII9bbZeZcwSiLWVZLvGtAl4sKkCWwUURTItYSGi7EQ9G0h7D9fAagWc
Mg8swmzUslw/eIkWwVWVGzSRDzU+3QJiP/oD7Hem5ZQLSPhV0sZK2CmUaEqh6D91
+Dy4BNPsfarePWB6FVrspsVnFlLmf9346XAzny5iTsJKMPubSo60lfmsxLmZnNZC
kxQ68V/TEtkedMabJZ+8
=d+Lk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51496413.7060...@uter.be

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Tue, Mar 19, 2013 at 05:09:00PM -0700, Russ Allbery wrote:
> note that free software interfaces to proprietary cloud platforms
> are frequently used to manipulate the data in those platforms including
> pull data *out* of those platforms.  It would be quite ironic if we
> refused to include in the distribution the tools required to pull one's
> data out of non-free platforms.

An interface to facebook or to twitter or to the internet movie database or to
websites with stock quotes may be freely redistributed but "requires software
outside of the distribution to function".  Why do we make exceptions depending
on how "ironic" things are ?

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130320071549.gc23...@master.debian.org

Re: [all candidates] Return to the desert island (cont.)

[Andrei POPESCU]

On Mi, 20 mar 13, 06:47:32, Bart Martens wrote:
> 
> Good question.  See also for example bug 681659.  I don't know why
> pidgin-facebookchat would belong in section main while flashplugin-nonfree
> would belong section contrib.  Both packages contain software that can freely
> be redistributed but require software outside of the distribution to function.
> Where to draw the line ?

Not sure flashplugin-nonfree is a good example here, since it is only a 
downloader for non-free software (the plugin itself).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Tue, Mar 19, 2013 at 04:46:42PM -0700, Steve Langasek wrote:
> On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote:
> > 3. One test I've been taught to use to reason about free software is the
> >Desert Island test [2] which starts by:
> 
> >  Imagine a castaway on a desert island with a solar-powered
> >  computer.
> 
> >   Obviously, software that are only frontends to unreproducible “cloud”
> >   services do not pass the desert island test.
> 
> This is a mischaracterization of the "Desert Island test" as it was
> formulated on debian-legal.  The Desert Island test is about whether a user
> can *comply with the license* of the software on a desert island when they
> have no contact with the outside world.  That the software may not be
> *useful* to them on a desert island is a separate question, and applies to
> many sorts of software, not just those used for connecting to particular
> services over the Internet.

I'm missing the point on what Steve wrote above.  We could debate on what one
understands under the "Desert Island test".  What really matters is that the
phrase "require software outside of the distribution to either build or
function" (Debian Policy 2.2.2) clearly applies to software that is not
"*useful*" without that other "software outside of the distribution".

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130320070149.gb23...@master.debian.org