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.
