Hi Enrico!

On Sun, 2014-01-19 at 14:56:27 +0100, Enrico Zini wrote:
> On Sun, Jan 19, 2014 at 12:04:17PM +0000, Ian Jackson wrote:
> > My reasons are quite different to yours: to summarise, it seems to me
> > that the init system decision involves political questions as well as
> > technical ones.
> 
> I would gladly vote an option that says: "technically, we trust what the
> TC says; politically, we are concerned about some of our upstreams'
> choices". A technical endorsement need not also be a political one.

I don't agree these can be detangled, many reasons for such decision
do have basis on non-technical questions (see my reply to Ian). So
the other questions will keep being implicitly there even if it's
supposedly just a “technical endorsement”.

> I would like to keep the technical and political issues as distinct as
> possible, though. I am not interested in spending time evaluating each
> option to form a technical opinion on what the best choice would be, and
> I'm extremely happy that the TC are doing that for me.
>
> I do have personal opinions on some of the upstreams' choices, but I
> believe that they should not get in the way of a technical decision.

To be frank, something I'd actually be very satisfied with, would
be if the TC would have been requested or would decide to issue a
set of non-binding informative documents, or a single or a set of
non-binding recommendations for a default init system, to be used
by people to decide, or to be added as additional explicit option(s)
in the GR deferring to those recommendations.

In fact, I think having a group of individuals (self-elected or not)
on a workgroup doing focused research on difficult issues concerning
project wide direction and presenting their findings and conclusions
for consideration before the project in a non-binding form, would be
excellent; and could help those who are undecided, don't have the time
or energy to expend getting informed, or would like to defer completely
their decision to that workgroup, for example.

But as it stands I think I'm a bit conflicted here, on one hand the
whole point of the GR is because I don't agree the TC should be
_deciding_ on this, the project should, but on the other I acknowledge
there's people that for whatever reason want to defer to the TC.

So, because that's obviously the will of a part of the project, and
because an amendment to the GR would be proposed most probably anyway,
I guess I should just add an option deferring to the TC. Although
ideally I think the scenario presented above would satisfy everyone,
if the GR is going to be held anyway.

> A constructive thing that we may do as a project to address the
> political side of the matter, is to add to our technical decision a list
> of things that we wish our upstreams would do to make all our lives
> easier in the future.

Honestly, I don't see how that would get us anywhere. We already have
<https://wiki.debian.org/UpstreamGuide>. Adding something like this to
a binding ruling affecting Debian, targeted at upstreams, seems a bit
arrogant to me, because upstreams that have a strong opinion that might
diverge from our ruling will unlikely change their mind. I think this
is best left to the one-to-one relationships our maintainers already
have with upstream, at their discretion. We always have the option of
forking, or not packaging upstream software if we so strongly disagree.

Thanks,
Guillem


-- 
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/20140120040409.ga13...@gaara.hadrons.org

Reply via email to