Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Call for moderation and mediation: debian-live vs. debian-live-ng

On Mon, 09 Nov 2015 18:40:29 -0800
Russ Allbery <rra@xxxxxxxxxx> wrote:

> This is a very difficult situation because many of the reasons why
> Daniel's relationship with the project have not been good are
> long-standing issues that the project addressed in various ways, in
> some cases years ago.  The relationship here has been troubled for
> quite some time, but the various people involved have (I think with
> mostly thoughtful restraint) have not repeatedly raised them.
> Therefore, a lot of people who saw that thread have no idea the full
> history of what's going on here and say things like that Daniel was
> attacked for no reason.  Which, whatever one might think about the
> past issues, is not correct.
> I'm very proud of a lot of people for not jumping into that thread and
> defending themselves and arguing with the characterizations presented
> there.  This is quite a significant improvement over the way I think
> this would have played out even five years ago, and while it's very
> hard to stand aside and see angry things being said without full
> context, I think that's been wise.

It's led to a rather one-sided set of public reactions - from those who
are unaware of the context and/or in a panic about the consequences for
them of Daniel's reaction.
> The main question here is how much we want to raise a bunch of old
> tensions in order to make a public statement in response here.  I'm a
> bit dubious that it's going to do much good, and whether an extended
> public discussion of who is right and who is wrong will actually
> accomplish anything.

Some feedback / positive input in public and from someone of
long-standing in the project to say that a lot of the angst is lacking
this context could be helpful. It's not easy to write a response which
would do that without causing immediate demands for full disclosure and
another round of picking over the bones of past disagreements. Some
time may need to elapse.
> I think the chances of a reconciliation between Daniel and the
> project are very remote for a lot of reasons, and this resigniation
> (of sorts) is something I'm actually surprised didn't happen some
> years ago.  So in that sense I don't think there will be a successful
> mediation.  The question is whether there's enough to be gained by a
> public report to be worth the extended public discussion, which is
> likely to be rather acrimonious.

What alarmed me more was that Daniel (apparently) has sufficient
control over the infrastructure of the live support that he can
threaten to completely disable it in a timeframe of his choosing. It is
this which has caused the largest reaction from users of debian-live.
The actual arrival of code to replace live-build was the trigger. Some
level of reaction from Daniel was expected but there was no expectation
that the debian-live project itself was at risk. Indeed, we expressly
used live-boot and live-config in the wrapper code because those
bits work.

By having this situation where someone at odds with the project was
left in (sole?) control of the infrastructure of debian-live - probably
because his access to Debian infrastructure was curtailed - it left the
users of debian-live exposed.

It may be worth considering that before the project accedes to making
the output of a team a part of the "official" release, the
infrastructure of that team needs to be under the control of teams
within Debian. More so when the leader of such a team already has a
fragile relationship with the project as a whole. Yes, accepting the
work in an official capacity can be a large step towards repairing the
relationship, it can also put users at a disproportionate risk and put
developers in a position where it is all but impossible to make
necessary changes. In effect, the ability to make such contributions
official presumes the existence of a mediator and gatekeeper who
ensures that the project and the users are equally protected. It is
this person (DD) who would then have access to the Debian
infrastructure on behalf of the team and be responsible for the
processes which have been so contentious with Daniel - coordination of
dates for releases, prevention of last minute changes to the builds,
urgent but coordinated bug fixes and the timely addition of new support
as required by other parts of the project.

The vmdebootstrap support for live images is, correctly, experimental
at the moment but live-build remains in Debian and can continue to be
used whilst the live-wrapper images go through more testing. (Yay, we
actually have a test suite for live images this way too.)

> My personal feeling is to thank Daniel for all of his hard work over
> the years for the probject and wish him luck with all of his future
> endeavors and just leave it at that.  We'll take a fair bit of bad
> publicity for a while from people not aware of the history, and then
> it will blow over.

I'm happy with Iain's choice of new name for the support but I should
have thought about it more when it was considered (briefly) within the
sprint at the minidebconf. I'm very grateful for Iain's contribution
and I fully support his work on replacing the code of live-build in
the creation of official live images for Debian.

I was not expecting Daniel to react in a way that seems expressly
designed to cause maximum panic in the users of debian-live nor for him
to have the (assumed?) ability to threaten the future of the
debian-live project. I was also expecting that someone within
debian-live would either be able to speak up or take over or attempt to
mediate, despite Daniel's reaction.

It also didn't help that I've been (& still am) off sick since shortly
after my own talk at the minidebconf and Steve has been catching
up on sleep after organising the minidebconf, leaving a rather thin
response from the debian-cd team.


Neil Williams

Attachment: pgpRBtgHQXd_V.pgp
Description: OpenPGP digital signature

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index