Re: Idea: rsync-based source format
On 14045 March 1977, Ian Jackson wrote:
> What I don't understand is what aspect or qualities or view of the
> proposed source package you are trying to examine at this stage. Or
> maybe, I don't understand your workflow.
We mostly care about seeing "all that we end up distributing", as that
is what counts for us. Sometimes it is sure important to also see what a
developer deletes (say, to see they really rebuild that binary in the
source by rm-ing it in the clean target), but the initial check is "look
at all files and see if you can find license trouble", independent from
what ends up in the .debs.
> Is this your primary ftpmaster review process, then ? Ie, you would
> look into the .orig tarballs individually with mc, and then into the
> debian tarball, and (presumably), read the diffs in debian/patches ?
Yep. Not everyone uses mc, but most of us do. It's simply the fastest
and easiest tool.
>> Sure can do a dpkg-source -x and look, but thats much more time
>> consuming.
> Do you mean it takes computer time to process the file into
> dpkg-source output, or that it takes human time to request that the
> computer produce a dpkg-source -x view ?
Computer-time is taken no matter what, mc in the background unpacks to a
tmpdir. Computer-time doesn't count.
Manually unpacking/preparing the tree to look at, so the human-time,
that counts.
>> Also, if that starts deleting files around, you still have to
>> manually look into the tarballs, one by one, as then not the end result,
>> but what we distribute in the tarballs is interesting in NEW.
> Yes.
> Is there any scope for dak to produce additional reports or
> information about packages in NEW, alongside the actual .dsc et al,
> for ftpmaster review ?
It already does that, see dak/examine_package.py (that also produces the
html versions that people can see on our site). Extending that is sure
an option.
> Reviewing a binary file diff in mc is never going to be easy, but I
> expect that binary file diffs are going to be quite rare. Less rare
> will be file deletions, but it ought to be easy to provide a list of
> them.
Sure, binary diffs are interesting, but a notice that there is one is
ok. File deletions, additions and modifications should be showable in
some useful format.
Also maybe an option of "now get me the source tree unpacked and my tmux
mc moved into that" (see "def usage" in process_new.py) would also be
nice, thinking of it.
--
bye, Joerg
Don’t worry. Being eaten by a crocodile is just like going to sleep… in
a giant blender.
Reply to: