the quality of Debian's diff.gz
Sorry for the new thread, but I didn't receive yet certain messages from
mentors list (I still can't figure out why), which I saw in the web archive
and I found interestig to reply to. If you feel the need to send me a
edifying message please do it on private ;-)
On Sunday 01 June 2008, Manoj Srivastava wrote:
> > True. This is cool and helpful for the DD point of view while working
> > with their $VCS, but might leave users of diff.gz with one single
> > jumbo diff which modifies several upstream files. Please note that
> > these users (which might happen to be the upstream developers of your
> > package) might not even have your $VCS of choice installed or
>
> Upstream developers of my packages get hand crafted submit
> branch patch sets sent to their preferred mode of incorporation; their
> BTS or their mailing lists.
This's fine, however does not address well the rest of the interested peer
reviewers.
> Anything less is not good practice; we should be sending our
> divergence upstream.
Very good, but please make these easily visible/readable to the rest via
diff.gz
> > devscripts package to use debcheckout, they might be pure $UNIX users
> > relying on patch, diff and a simple text editor. So, will you
> > generate at some point a series logically separeted quilt patches and
> > store them in debian/patches/ in the final diff.gz which is the
> > canonical way of Debian to distibute changes.
>
> This can only work if the topic branches are non-overlapping;
> and that might cover a lot of cases, but not all.
>
> I am not so sure it is indeed a canonical way of doing things in
> Debian. If it is, which canon do you follow?
The above sentence of mine says: "diff.gz which is the canonical way of Debian
to distibute changes.". A normative document stipulates: "debianisation diff
is a unified context diff (diff -u) giving the changes which are required to
turn the original source into the Debian source.". The mere request is to
make your debianisation diff a good citizen, which should be able to create
the logically separated changes to the upstream code clearly identified and
documented diff files. Then, the rest of the world can just get that diff.gz
from myriad of media *at their will* and try it against whatever orig.tar.gz
or local SCM working copy they have.
> > There should be ways to use both, since you depreciate your diff.gz
> > and it turns to be a useless scratch of bits. Then, again why have
> > diff.gz at all when it is not credible enough ?
>
> Credible \Cred"i*ble\ (kr[e^]d"[i^]*b'l), a. [L. credibilis, fr.
> credere. See {Creed}.]
> Capable of being credited or believed; worthy of belief;
> entitled to confidence; trustworthy.
>
> I find the diff.gz as credible as anything else. Why would it be
> less trustworthy?
It is less trustworthy since it applies in a combined fashion multiple changes
to the upstream tree, which leaves the bad impression of that whoever created
it doesn't have a clear idea of what he was doing.
> In any case, as development proceeds, tools change. patch and
> diff were great, once upon a time, just like programming in raw
> Hex was still in vogue when I started programming.
>
> >> I do have a emacs package you can look at for details, if you wish:
> >> http://git.debian.org/git/users/srivasta/debian/vm.git
> >
> > Using a modern SCM is wonderful, but please, get back to the ground,
>
> I don't think that using modern SCM's is crazy (if not being on
> the ground has the connotations I think it has).
Oh, that is the wrong road, believe me. I don't claim that using SCM is crazy,
almost everyone uses some, me included. I claim however that *ab*using a
modern SCM might degrade the quality of the end product you finally
distribute officially, i.e diff.gz in that case. The difference is slight,
but crucial. A notable example of well done end product is the one comming
from pkg-glibc, you would love to read their clearly identified changes as
supplied by their diff.gz.
> > and think of the possible use cases with what Debian has officially
> > released, and if that is what warns a certain level of
> > unification. There are users (let's say within restricted areas) who
> > can't access random DD repos at will, but rely solely on diff.gz
> > supplied by released source CD/DVD media. Please note that development
> > history of changes is not of any help here, but what exactly has been
> > applied (as logically separated changes) to a particular upstream
> > version being released.
>
> People who want to actually follow development would need some
> net access -- or, with the 3.0 (git) format, have their topic branches
> on their DVD. Realistically speaking, do you have any numbers on such
> users who must rely on DVD's and can't get someone to burn a DVD for
> them?
Do you suggest cloning every pkg repo out there and burning that to DVD, then
rush over to the company's restricted area passing various identification
checks ? It doesn't scale well in my opinion. Realistically speaking there
are certain entities (consider some government agencies, but also some
companies) who might happen to use Debian in areas where public networks are
not allowed, because they are supposed to obey certain policies. And I doubt
there is an easy way to gain any hard numbers about such users, since most
probably they will pretend they do not exist ;-)
> There is a tradeoff. There is correctness of the package , which
> is eased by using topic branches (at least, for me), which trumps the
> use cases you are talking about. Now, in cases where the branches do
> not overlap, there can be a simple conversion to a stacked patch
> format; and I'll have no objection to using a tool that can do the
> conversion (at the expense of source package size bloat).
It sounds pretty fair to me to trade some size for more readability.
On Sunday 01 June 2008, Ben Finney wrote:
> George Danchev <danchev@spnet.net> writes:
> > Using a modern SCM is wonderful, but please, get back to the ground,
> > and think of the possible use cases with what Debian has officially
> > released, and if that is what warns a certain level of unification.
> > There are users (let's say within restricted areas) who can't access
> > random DD repos at will, but rely solely on diff.gz supplied by
> > released source CD/DVD media.
>
> It sounds like you are strongly motivated to contribute to a tool that
> will allow developers that track changes in their VCS to automatically
> generate the 'debian/patches/' directory that you are so interested in
> seeing.
Consider "you" as the rest of the world, even non-debian users, since they
might want to grab something from these diff.gz, and not to fight with the
great number of VCS in use for debian packaging if they bother to find the
repos at all.
> Stronger motivated than, say, the motivation felt by the VCS-using
> developer themselves, who already has a workflow that functions fine.
The point is not about VCS-using developers themselves, obviously their
workflow is fine for them, it is about the ability of the rest of the world
to follow their workflow. Obviously Debian doesn't release yet various
pkg-repos.
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: