extracting patches from the ancestry graph

[George Danchev]

On Wednesday 01 October 2008 17:54:24 Manoj Srivastava wrote:
--cut--
> > 1) people do not need quilt nor dpkg to view and apply these patches
>
>         I find it easier reading code than reading patches upon patches
>  upon patches that modify code I can read. If there are dependent
>  patches, keeping all the previous changes in your head as you look at
>  yet another patch modofying the same file .. well, good luck.

If you really read these that way, then you are really unlucky.

>         I do not think this is a naive assumption on my part. On the
>  contrary.

... and of course clearly identified patches are already published at:
http://patch-tracking.debian.net and in case you forgot these patches are also 
distibuted by cd/dvd images and official ftp archive.

> > 2) there is no guarantee that what you have in your publicly browsable
> >    integration branch is actually what buildd are fed with to produce
> >    the binary packages users use and are interested in changes done.
>
>         You can easily check the integration branch in the repo versus
>  the unpackahed sources (applying the giant diff.gz).  This is not
>  really an argument that gells with me. Heck, I don't know if what is in
>  Linus' release branch is what is in the tarball, but I don't thinkit
>  bothers me a lot.

Yes, I know it is easier for you to ingore the issue, but I don't find such an 
ostrich policy a sound solution, but I find git+topgit+quilt much better in 
that case.

> > 3) you are leaving non-internetworked users in the cold, but Debian
> > operates in such places.
>
>         Hey, with the 3.0 (git+) format, we can bring these people
>  in. But in this day and ag, the arguments for distributed VCS's and
>  distributed development trump catering to the connectivity challenged.

Oh, please quit explaining things we already know. I didn't write that in the 
light of 3.0 (git) format, but in the light of your current packaging. OTOH, 
3.0 (git) won't help users much when your divergencies from the upstream have 
been deeply hidden in the VCS history, and we have already seen such a 
failure. 

-- 
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>