[tor-talk] Debian bureaucracy [was: Tails Mac support [Was: Training Journalists in Istanbul]]

[adrelanos <adrelanos@xxxxxxxxxx>]

Maxim Kammerer:
> On Fri, Feb 22, 2013 at 6:58 PM, intrigeri <intrigeri@xxxxxxxx> wrote:
>> The remaining part of the problem will be solved by adding UEFI
>> support [3] to Tails. We're currently making plans with Debian Live
>> upstream so that this support is added there, and benefits all Debian
>> Live systems.
>>
>> [3] https://tails.boum.org/todo/UEFI/
> 
> Don't you already regret basing Tails off a binary distro like Debian?
> I mean, updating TODO lists once in a while and making “plans” sounds
> fun and all, but not only are you completely dependent on an upstream
> distro's features implementation cycle — you are missing the
> opportunity to learn new things while implementing those features
> yourself. I mean, Liberté was the first Linux distro to ship with a
> UEFI Secure Boot-based trusted boot chain — do you think you will ever
> be able to say something of the sort about Tails? Open Source
> development is supposed to be exciting, not this… bureaucracy.
> 

As maintainer of Whonix, I also like this join this discussion. First of
all, don't get this wrong. I still believe Debian was and still is the
best choice from all possibilities.

I must say, I am sometimes also disappointed by Debian bureaucracy.

Two examples...

1) Tor Browser

It can't make it's way into Debian due to "no code duplication policy".
I couldn't agree less. This "no code duplication" may have been useful
when when disk space was expensive 20 years ago or so. By blocking this
due to politics, they increasing workload in a lot projects based on
Debian. (#1 Tails specific Tor Browser patches, #2 Whonix Tor Browser
download, #3 torbrowser-launcher)

The answer for such cases is "merge your patches upstream" - yes, but if
upstream isn't interested? Creating the patches in a way, that they
won't duplicate code, is like "10 times" more effort - and might break
if upstream changes something. Creating the patches is something the Tor
Project with full time employees managed, but creating them in a way
that upstream accepts them in a "if this mode"-approach is much more
difficult. And their review process takes so long, that it can never be
done. With this "no code duplication policy", Tor Browser, no matter how
many users it will have, will never find it's way into Debian. (Unless,
Mozilla somehow just starts to care.)

2) The MATE Desktop

GNOME developers failed to make their users happy when they changed from
GNOME 2 to GNOME 3. Many people prefer GNOME 2. Others created the MATE
Desktop. It's a fine fork of GNOME 2. They where willing to offer Debian
packages, actually they offer them in their own repository already. They
just got them into a state, that many people like it.

They didn't make their way into Debian, also because of the "no code
duplication policy".

There are other applications, which didn't make into Debian repository,
because of that policy...

In conclusion...

I think the correct question to ask isn't "does it duplicate code?", but
"won't it break something?", "is it well maintained?", "is upstream
generally ready? (not too many bugs)".

Having a policy is a fine thing. But after some time it should be
re-checked if the original reasons for that policy still apply and if
that policy is still worth to be enforced or if it does more damage than
anything else.

Sometimes it's better to start fresh. For example, Ubuntu started fresh
and attracted more users than Debian. Or Chrome started fresh and
attracted more users than Firefox. That goes for may projects. When they
start, they are great, but overtime their own policy slows them down.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk