Re: [Tails-dev] Tracking derivatives delta: explanations, hi…

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: debian-derivatives
CC: tails-dev
Subject: Re: [Tails-dev] Tracking derivatives delta: explanations, history [Was: Sponsoring a Tails hackfest?]
Hi,

Paul Wise wrote (11 Jul 2014 02:58:20 GMT) :
> On Fri, Jul 11, 2014 at 4:50 AM, intrigeri wrote:
> An update on that:


> The new hardware is setup and DSA have installed the necessary tools.


The Tails sources.{new,patches} still seem outdated. Is some part of
the system not back up yet?

>> a. Enable anyone to easily find potential action items; that is:
>>    make it easy to filter what should be ignored ("legit" delta) and
>>    what should be improved.


> My idea here was to add that to the new tracker.d.o interface and
> associate it with the person who logged in, since what people want to
> see might be different.


Looks good to me.

>> b. Visualize the evolution of a given derivative's delta with Debian
>>    => detect if the situation is improving or getting out of control
>>    => derivatives developers can be happy and proud, or react
>>    promptly; Debian contributors can evaluate how a given derivative
>>    is "nice" to Debian.


> Should be easy to add rrdtool graphs or the like. If we want something
> more advanced than that, a database would probably be required.


IMO rrdtool graphs should be good enough.

>> 1. Have explanations about the delta in each case


> That information should be in debian/changelog, which would be in the delta.


I could agree on this principle, but in practice, I doubt derivative
developers explain in debian/changelog what part of their delta should
be ignored ("legit" delta) and what should be improved. DEP-3's
"Forwarded" field, when applicable, seems more adequate. Also,
debian/changelog is not machine-readable, is meant to document
incremental changes, and does not provide an aggregated view of the
current state of things.

Looking at Tails current delta, as documented [1] a few months ago:

  * Tails-specific packages: the information that should be easy to
    retrieve (ideally, in a machine-readable way) is "these packages
    are too specific to go into Debian (not mentioning the release
    cycle mismatch)". Even if we did add this information to
    debian/changelog, it would be quickly buried below dozens of other
    entries, and hard to find. Same for packages that are not really
    Tails-specific, but that can probably never be uploaded to Debian
    for legal reasons; same for packages that were removed for Debian
    (for good reasons) but are still needed in Tails.


  * modified packages: in general, ideally the relevant information
    should live in per-patch DEP-3 headers. Adding it to
    debian/changelog would duplicate information, in a way that's not
    easy to retrieve.


  * backports that would be a huge pain to properly maintain in
    wheezy-backports: could be documented in debian/changelog.


=> I'm unconvinced that documenting this kind of things in
debian/changelog's would help much. Not saying that our initial idea
is the best possible one, though :) Thoughts, other ideas?

[1] https://lists.debian.org/debian-project/2014/05/msg00036.html

>>    Ideally, for 3.0 (quilt) packages, compare-source-package-list
>>    could look into debian/patches for derivatives-specific patches,
>>    and retrieve information from DEP-3 headers.


> That sounds like an interesting complement to diffs of debian/changelog.


OK, created https://labs.riseup.net/code/issues/7608. Is there
a meta-package or something to track such tasks in the Debian BTS?
Alternatively, should I just add these ideas to
https://wiki.debian.org/Derivatives/Integration#Ideas ? I've also
found a list of FIXME's on top of the compare-source-package-list
script, so I'm a bit confused.

>> 2. Generate graphs displaying the evolution of a derivative's delta
>>
>>    This requires storing history of at least sources.{new,patches},
>>    and having some code that generates graphs out of it. Presumably,
>>    once specified properly, this could be a great task for someone
>>    learning programming.


> sources.{new,patches} already store both current and historical data.


Great!

In order to be able to graph things, it seems to me that one also need
to know the date/time when a given version of a {new,modified} package
was last seen in the derivative's APT repo. Would you happily take
a patch against compare-source-package-list, that stores this
information in sources.{new,patches}?

> BTW: I plan to have a DebConf14 BoF about the derivatives
> patch-generation stuff.


Awesome. I'll be there.

Cheers,
--
intrigeri