Re: [all candidates] discussions in -devel

2013-03-26 Thread Moray Allan

On 2013-03-19 17:00, Serafeim Zanikolas wrote:
Our usual approach of darwinism (whereby a single hacker's solution 
gets
gradually adopted) does not work here because any attempted solution 
(social,
technical or both) requires some kind of upfront policy change (and, 
for

technical measures, some kind of infra change).

How do you propose that we go about dealing with this issue, keeping 
in mind
that it's imposs^Wchallenging to get to consensus about non-technical 
and

potentially controversial policy (moderation) changes?


I've already made some comments related to this, see the previous
thread starting at
http://lists.debian.org/debian-vote/2013/03/msg00116.html

More generally on unproductive -devel threads:

I think problems usually arise from the style of a thread,
beyond just one or two loud people.  Enrico's Debian Community
Guidelines contain some good material related to your question, see
in particular 
http://people.debian.org/~enrico/dcg/ch02s05.html#comm-howto-longthreads


A few points that I think people too often forget:

- Make it clear why you're replying, and what course of action you are
advocating with respect to the overall problem under discussion.
While "me too" replies aren't generally useful, if you're replying at
all it's good to point out things that you agree with, not only state
disagreements.

- Try to separate discussion of goals from discussion about actions.
If you are replying to disagree, be clear if you are disagreeing about
the proposed goal or about the proposed actions to reach it.  If you
are starting a discussion, be aware that it may be easier to agree on
a set of goals first before discussing the best technical path to get
there.

- If you disagree with the proposed goal, be clear whether you want to
keep the status quo, or are advocating some other outcome.

- People should try to make their contributions to a thread build on
what has gone before, not just steer discussion towards a minor point.
If the bigger picture is being lost in a subthread, try to help things
by summarising what had been said so far, and the main points of
discussion, before offering your own view.

- Consider that not all readers will be as familiar with the issues as
you are.  Don't be patronising, but try to help anyone in this
position by stating things clearly.  Perhaps someone who disagrees
with you is just missing some important information.  Don't treat them
as malicious, but explain your own reasoning and see if it changes
their mind.  But remember that it might occasionally be you who is
missing important information.

- Realise that other people may assign different weights to the
arguments in favour of each option.  Perhaps they know the same facts
as you, but have different priorities from you -- if so, try to
understand why this is.

- If someone seems to be suggesting something stupid, consider the
possibility that you have interpreted the words they said in a
different way from the one they intended.  You should probably still
seek clarification and perhaps state your opposing point of view, but
avoid starting by attacking their apparent stupidity.

- Changing your mind in the course of a discussion, after hearing new
facts or new arguments, should be seen as a sign of wisdom, not a sign
of weakness.

--
Moray


--
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/d484ca770ec8fad8f91ec6d9b49fe...@www.morayallan.com



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

2013-03-26 Thread Moray Allan

On 2013-03-19 16:39, 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?


I don't think that having the facility to fetch or process non-free 
data makes software non-free.  It is normal for tools to be agnostic 
about the licensing of data they process, even in cases where it's 
almost certainly non-free.  For example, the licensing of DVB broadcast 
content is very unlikely to be free, but I don't think we should move 
all DVB programs to contrib.


However, I would agree that making our users dependent on non-free data 
sources is bad. This kind of problem isn't new: an old example is the 
track information used in CD ripping tools.  In that case community 
efforts created free alternatives that the tools could use instead.  As 
a general principle, we might want to discourage default installations 
of packages from automatically pulling in non-free data and thus 
encouraging users to become dependent on it.


--
Moray


--
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/6adceccb48e947c36d8a21ad4610e...@www.morayallan.com



Re: [all candidates] Removing or limiting DD rights?

2013-03-26 Thread gregor herrmann
On Mon, 25 Mar 2013 18:02:08 +0100, Lucas Nussbaum wrote:

> On 25/03/13 at 16:22 +, Steve McIntyre wrote:
> > Are we strict enough with our existing contributors? When we're trying
> > to work together as best we can to make the Universal Operating System
> > happen, what could/should we do with contributors who hinder our work?
> > Sometimes that hindrance is inadvertent, sometimes it seems
> > deliberate. At other times it looks like we have developers who are
> > just not paying attention to what they're doing or who just don't care
> > about the goals of the project.

Thanks for this question, which I would like to extend a bit.
Im my understanding you are pointing to unconstructive behaviour
related to technical work. What we also see (and discuss) every now
and then is behaviour that is socially questionable or clearly
unacceptable (from disrespect for peers to blatant abusive language).

I guess we all remember such examples, which have led to
demotivation, frustration, hurt feelings, and have driven
contributors away.

Lucas' reponse already shows an idea that might also be used for
these cases:
 
> One small thing that we could improve on is earlier official
> communication. For example, in case of seriously problematic behaviour
> that could eventually lead to censure or expulsion, official warnings
> could be issued to the DD, and Cced to -private@. In some cases, that
> could help the DD realize that s/he needs a behaviour change, and also
> limit the surprise effect if/when a final decision is taken.

What other ideas do you (plural, for all candidates, in case you see
the necessity to improve the handling of "social problems") see as
viable?

Examples that have come up in the past and might or might not be
helpful:
- Encourage everyone to chime in when they see potentially
  unacceptable behaviour? In public/private?
- Should we try to establish a Code of Conduct for project members?
  Cf. https://openhatch.org/wiki/Project_codes_of_conduct for
  examples.
  If yes, how would we do this, and how could we make sure it gets
  respected?
- Could the CoC for mailing lists
  (http://www.debian.org/MailingLists/#codeofconduct)
  be used as a starting point / be extended?
- Or Enrico's Debian Community Guidelines?
  http://people.debian.org/~enrico/dcg/index.html
- Another recurring topic is the Social Committee, cf. e.g.
  https://lwn.net/Articles/221077/ (or the ombudsman team mentioned
  in the article:
  https://lists.debian.org/debian-project/2007/01/msg00101.html )
  Would such a body make sense? With which powers?

Short summary: Does Debian need procedures for intervening in cases of
dysfunctional social behaviour and which?


Thanks to all of you for standing/running in this vote, and for
taking the time to answer all these questions!


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: Rod Stewart: Smile


signature.asc
Description: Digital signature


Re: [all candidates] on distribution-wide changes and scalability

2013-03-26 Thread Gergely Nagy
Stefano Zacchiroli  writes:

> Folklore goes that performing distribution-wide changes in Debian is
> hard and time-consuming, due to a couple of reasons: (1) the time needed
> to make a decision that affects the whole archive (this is related to
> our flat structure, which has many benefits, but surely not that of
> providing a clear decision structure for cross-cutting concerns), and
> (2) the time needed to deploy the needed technical changes in all
> affected packages.

It is, indeed hard and time consuming. I do not neccessarily see that as
a problem, but see below.

> This "inertia" folklore is surely supported by past history of the time
> it took us to deploy specific changes in large sets of packages.  But on
> the other hand, in the last 5 to 10 years we have massively improved our
> ability to decide and deploy large changes by the means of: (a) large
> maintenance teams who are able to decide on "their" packages and deploy
> changes using shared-access VCS, and (b) a more liberal use of NMUs than
> in the past.
>
> Questions for the candidates:
>
> - on the judgement spectrum between "there is no inertia in Debian and
>   that's good" and "there is a lot of inertia in Debian and that's bad",
>   where would you put yourself?

On both sides, of course, and sometimes somewhere inbetween. We've seen
cases where we had inertia, and turned out it was useful. We've seen
others where it turned out to be a bad thing. So it really depends on
the context.

> - if you don't think that we're at our best on this front, what do you
>   propose we change to improve?

(See below, but keep the above statement in mind.)

> As mere thought experiments, feel free to consider the following
> possible "changes" as part of your answers:
>
> - Debian should use the Technical Committee more proactively than we
>   presently do, to decide on "any technical matter where Developers'
>   jurisdictions overlap"; not only to solve conflicts (as we already
>   do), but also to *design* forthcoming changes in an authoritative
>   manner.  [ Many large FOSS projects out there have technical boards
>   that work that way. ]

Involving the tech-ctte earlier may be a good idea, but pushing the task
of designing forthcoming changes onto them, even if done in cooperation
with the other parties involved, is not something I'd push for. I see
the tech-ctte more as a decision making body, or a technical mediator,
than an entity that designs change.

Getting the tech-ctte involved more often, not only as a last resort can
have benefits, but then we need to make clear that we expect help, and
not neccessarily a solid decision.

(FWIW, Constitution 6.1.5 already grants the tech-ctte to offer advice,
we should exploit this power more often, and more pro-actively.)

> - Debian should decide to use a single VCS (say, Git), for all packages,
>   uniform repository structure and work-flow, and give by default
>   read/write access to all DDs. This would allow push-button changes to
>   all packages in the archive.  We often speak about "reducing package
>   ownership" during DPL campaigns, well, this is the ultimate step of
>   it.  [ Ditto: I know no other large FOSS project out there allowing
>   the extreme diversity in VCS, work-flow, and ACLs that we have in
>   Debian at present. ]

No. Most definitely no. There is *no* structure, nor workflow that fits
all packages and all packagers, trying to force one down our throat
would be counter productive. While this would certainly have advantages,
I find the costs too high:

 - Adapting to a single repository structure can be needlessly painful
   (esp. when you need to adapt the upstream structure too)
 - Settling on a single VCS is not going to happen, ever.
   - Sometimes it is more convenient / straightforward to use the same
 VCS upstream uses (which may or may not be git).
 (Especially when one is upstream)
   - Sometimes one is maintaining the same package for not only Debian,
 but derived distributions aswell, which use or prefer another
 VCS. Trying to force the hand of our downstreams this way is not
 productive, in my opinion.
 - There is no workflow that fits all scenarios. Trying to shoehorn
   everything into a simplified view is just going to hurt in the long
   run.
 - People are people, they're hard to change, and in a purely volunteer
   based project, that has a long history of giving pretty much free
   hand to the maintainers as long as they comply with policy and some
   amount of common sense, moving towards a more controlled environment
   by force is bound to cause quite an uproar.

 (I've worked with BSD ports/pkgsrc for quite a while, where there is a
 single VCS, a uniform repository structure, and pretty much one
 canonical workflow. It was horrible. So very inflexible, it was a pain
 to adapt things that weren't designed with that particular layout &
 workflow in mind.)

I'm all for encouraging putting packages under collab-maint or team
maintai

Re: Debian for third party (read: propietary) apps/vendors

2013-03-26 Thread Gergely Nagy
Lisandro Damián Nicanor Pérez Meyer  writes:

> There are third party vendors (read: propietary) that support the 
> installation 
> of their software in Debian, but mostly because selfish reasons: they need to 
> be present everywhere for their business model to work. A clear example of 
> this is Skype.

Most proprietary packages exist for the same reason: there's demand for
it, demand that can be turned back into money. Very few (if any at all)
proprietary vendors package up their software for distributions just to
be nice.

> Now there is a second class of apps/vendors which do not need to be ubiquitous
> for their business model to work. Most of the examples that come to my mind 
> are CAD-related: Synopsys [0], Cadence [1] and Mentor [2] are examples of 
> propietary vendors that give support for Linux but just on Red Hat and 
> sometimes, Suse. And they are a PITA to make them work on Debian. This makes 
> IT workers need to have RH/Suse/CentOS boxes even if the rest of them run 
> Debian.
[...]
> Now my question is: without going against the Social Contract, is there 
> anything Debian can/should do wrt this situation?

The difference between Debian, RedHat and SLES (SUSE Linux Enterprise
Server) is that there's commercial support behind the latter two,
there's a company where vendors can turn to if they need
support. There's no such entity behind Debian. There are companies that
do sell Debian support, but that's not quite the same.

This status quo means that vendors rarely invest into preparing Debian
packages, because only a very small percent of their users are running
Debian (due to their business requiring support contracts from the
vendor, which is much easier and straightforward to obtain in the
RHEL/SLES cases, for example), and investing into making proper Debian
packages is simply not worth it.

As such, there's nothing Debian can or should directly do.

On the other hand, we have downstream distros where the parent company
does provide similar support guarantees that RHEL and SLES do. If third
party vendors start creating packages for these distributions, that may
very well make it easier to run said software on Debian too (like how
the RPMs are often run on CentOS instead of RHEL). This would help
Debian users who, for some reason, need to run said proprietary
software.

But even then, I would not wish Debian to go to great lengths to
accomodate non-free software. We should not make it unnecessarily hard,
either, but that's about it. If vendors don't provide Debian packages,
there's nothing we - as a project - can or should do to change
that. We're not the users that matter for the vendor, we're a target
platform, and it's not the platform that matters, but whether there's
enough users to make the effort of supporting the platform worth it.

(It's not like it's hard to make debian packages. It most definitely is
not. It isn't particularly hard to support Debian stable, either [my
employer provides packages for one of our propriertary tools for Debian
Sarge(!) too, it's not terribly hard].)

-- 
|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/878v5a899d@galadriel.madhouse-project.org



Re: [all candidates] delegation

2013-03-26 Thread Gergely Nagy
Thomas Goirand  writes:

> One of the key role of the DPL is to delegate.
>
> What are your intention in this regard? Do you think that the current
> teams and roles are well filled? Or would you like to change some of the
> people currently holding a position? Why (not) changing anything?

I believe that the current delegations are well deserved, if elected, I
wish to reaffirm people currently holding a position (unless they wish
to step down, of course).

On the other hand, most of our teams are lacking manpower, which is
something I would like to improve. To remedy the situation, I'd need to
learn a bit more about the various teams than I was able to while
peeking in from the outside. I'd like to think that we have quite a bit
of manpower to spare, we just need to aim them at the right team. Or if
that fails, improve our recruitment to make joining the teams lacking
manpower most more appealing, and more rewarding. In some cases, likely
more visible, and better defined too.

I also plan to delegate more tasks, to make the DPL job sustainable in
the long run. These would include representational tasks just aswell as
organising things on behalf of the DPL, and so on and so forth. I see
Zack's DPL helpers initiative as a step in this direction, and I'd like
to take it a little further.

-- 
|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/87d2um8f49@galadriel.madhouse-project.org



Re: [all candidates] Removing or limiting DD rights?

2013-03-26 Thread Gergely Nagy
Steve McIntyre  writes:

> Are we strict enough with our existing contributors? When we're trying
> to work together as best we can to make the Universal Operating System
> happen, what could/should we do with contributors who hinder our work?

I do not believe we're strict enough, not in general. On the other hand,
I'm not a big fan neither of overruling DDs, nor of limiting them. I'll
explain below.

> Sometimes that hindrance is inadvertent, sometimes it seems
> deliberate. At other times it looks like we have developers who are
> just not paying attention to what they're doing or who just don't care
> about the goals of the project. Occasionally we see direct action to
> censure or even expel DDs, but these are only ever in the most blatant
> of cases. By the time that happens, large amounts of damage may be
> done to the project: delayed releases, lost users, loss of motivation
> for other contributors.
>
> I'm wondering: is this something that you think is a real problem, and
> if so what do you think we could do about it?

The worst case (when it comes to expelling or severely limiting a DD) is
fairly rare, and I certainly hope it will stay that way (and we really
should not let things get that far). However, causing damage (due to
negligence and/or lack of attention) is far more common, and is a real
problem, one we should be dealing with much, much better.

The salvaging effort was/is something that gave me great hopes, because
it approached the problem from a less personal angle. The less personal
an effort is, the more successful it can be in this case, as far as I
see. Telling people they're harming the project is a lot different than
telling them that a particular package needs more love, and then going
ahead to aggressively hug said package to give it more love. I think the
salvaging idea is something that we should push forward with,
aggressively. While this is not a solution to every problem, it would
help in quite a lot of cases. How well this works, also depends on the
people involved, so great care must be taken to avoid as many bruises as
possible. (But not at the expense of dropping it alltogether and doing
nothing! Better some bruises and a handshake months or years later than
silently holding grudges forever.)

But alas, salvaging will not solve everything, and in some cases, it is
likely not an option either. In those cases, we should not be afraid of
overruling the maintainer, and if need be, forcibly transfer the package
to someone else. Yes, this would also have consequences we'd rather
avoid, there would be bruises, but if there's no better option, when all
other kinds of negotiations failed, then I see no better option.

Negotiation is something we should perhaps be practicing more, and
earlier.

In short, we have the procedures to completely revoke or severely limit
DD powers, but this is a power we should exercise rarely. Instead, we
should work towards discovering problems much earlier, and work more
aggressively towards resolving them, before more harm's done. Among our
tools to help with this quest, we have salvaging, and once a problem's
discovered, earlier negotiation attempts, possibly involving the DPL as
a mediator.

-- 
|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/87hajy8g4s@galadriel.madhouse-project.org