Hi Steve,
Steve Langasek wrote (04 May 2014 08:27:44 GMT) :
> But since it's a derivative rather than a pure blend, how do we know
> that in /this/ case, the work at the sprint is going to
> benefit Debian?
With my Debian developer hat on, I thank you very much for asking this
key question.
Actually, nothing guarantees that *any* sponsored sprint is going to
benefit Debian. The people organizing a sprint state "we'll work on
$blah", we make sure that $blah would benefit Debian, and then we
trust them to do what they committed to, and finally we check their
report and are happy that so much good work was done :)
In the case at hand, all what Tails can say is "we're going to work on
Tails". I agree there is definitely an important stretch from this
statement, to trusting it will benefit Debian... at least for anyone
not familiar of the Tails project's track record withing Debian, and
the challenges it faces.
I'll try, with my Tails developer hat on, to provide some insight that
might help addressing this trust matter. I think there are three
aspects to this question.
First, we (Tails contributors) are doing as much as we reasonably can
directly within Debian for ethical reasons. We simply think it's the
right thing to do. But I agree that all this good will is not a good
enough reason to trust that a Tails hackfest + summit will
benefit Debian.
Second, as well-informed people have mentioned a few times in this
thread already, our track record on this topic is pretty good. A Tails
hackfest + summit will benefit Debian because our past work has very
often been done in a way that did, and I see no reason why this time
would be an exception.
Third, this is not only a matter of being nice, willing to give back,
and loving Debian (hint: we are * 3). It's also a simple matter of
necessity for the Tails project. Even if we could financially afford
hiring a dozen new skilled contributors (hint: we cannot) to create
and maintain a large delta (and then, optionally, boast about the
added value our product provides compared to Debian), our current
project (organizational, social) structure would not handle it.
I don't think we can reasonably change this structure radically any
time soon, and we have no plans to even try. So, we *have to* not only
work close to Debian, but simply, many times, *within* Debian.
I believe the two last points should be enough to trust that a Tails
hackfest + summit will benefit Debian in some way.
> The website has a very admirable statement about minimizing the
> delta with Debian, but is the size of this delta published and
> tracked anywhere?
Not really. Taking the upcoming 1.1 release as a basis, our delta is
made of:
1. Six packages for Tails-specific software (liveusb-creator,
tails-greeter, tails-iuk, tails-perl5lib, tails-persistence-setup
and whisperback).
2. Three packages that are not really Tails-specific, but that can
probably never be uploaded to Debian for legal reasons.
3. Four modified packages:
- dbus-python: we should definitely report a bug upstream about why
and how we patch it, and how. That's a failure on our side.
- iceweasel: we add the Tor Browser's patchset. Previous attempts
to work within Debian to have this packaged have failed.
- tor: backport of 2 or 3 upstream patches that are important for
us; will disappear once upstream 0.2.4.22 is out.
- vidalia: we patch it to hide some parts of the UI that are
useless, or harmful, in the context of Tails. Our attempt at
finding someone to add configuration settings to do the same
failed (we found someone, signed a contract, and then they
disappeared). This piece of software has no active upstream
anymore, which does not help.
4. One package (torbutton) that was removed from Debian for good
reasons (needs a browser with Tor Browser's patchset applied), but
is definitely needed in Tails.
5. Six backports that would be a huge pain to properly maintain in
wheezy-backports, as discussed with the Debian Haskell team:
haskell-cmdargs, haskell-data-pprint, haskell-hledger,
haskell-hledger-lib, haskell-pretty-show, and haskell-tabular.
6. Our (quite large) live-build configuration tree, that includes
mainly configuration files and scripts to modify the system.
Some bits of it could be upstream'd relatively easily if there is
demand. But the major bits (e.g. torified DNS resolution) are
basically impossible to add to a general purpose distribution like
Debian, in any way that would be useful and not dangerous, because
it is very hard to guarantee anything when the system administrator
can install any combination among 30k packages, that may suddenly
start breaking what our stuff achieves, and we want to avoid
providing wrong feelings of security.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85bnv8l3fl....@boum.org
