v3 Debian source package formats

[George Danchev]

On Wednesday 01 October 2008 22:07:12 Manoj Srivastava wrote:
> On Wed, Oct 01 2008, George Danchev wrote:
> > On Wednesday 01 October 2008 15:13:45 Manoj Srivastava wrote:
> >> On Wed, Oct 01 2008, martin f krafft wrote:
> >> > also sprach Manoj Srivastava <srivasta at acm.org> [2008.10.01.0302
> >> > +0200]:
> >>
> >>         *Shrug*. If the 3.0 (git) format is untenable, then I suppose
> >>  I'll just let dpkg muddle through. I am not _that_ interested in making
> >>  it easier for vaporware helpers to possibly contribute that I'll be
> >>  willing to take a huge hit on my productivity.
> >
> > I guess you are still missing the point and at the end your production
> > might be useless to your users/reviewers/contributors, no matter how
> > productive *you* have been.
>
>         I am not sure where your data is that potential contributors
>  will not be able to get the information from the DVCS. 

That is your data, not mine; some lines above you wrote: "I am not _that_ 
interested in making it easier for vaporware helpers to possibly 
contribute..."

>  Also, there is a 
>  tradeoff: the hoops actual workers have to jump through in order to
>  make things _possibly_ easier for vaporware potential contributors.

Again, you are only interested to do what is easier for you. In fact, I really 
find your workflow quite simplistic and ignoring to various important 
details.

> >>         The bottom line still remains making it easier for me to package
> >>  software for my distribution cleanly, efficiently, and without
> >>  having to jump through too many hoops.
> >
> > It is much more efficient to invest some efforts at your side and make
> > divergencies from upstream clearly identified, than everybody else to
> > spend time on his own to investigate your divergencies from upstream
> > and doing that *your way*.
>
>         Its not like I am using a super secret manoj only mechanism to
>  hide the changes -- git and gitweb make the changes easy to discover.

You are completely ignoring VCS-agnostic nuance. Not a factor for me.

> On Wed, Oct 01 2008, George Danchev wrote:
> >>         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 think that serialized patches makke features harder to
>  understand, and would prefer actually each feature separately in an
>  independent patch series; so people can try each feature out without
>  trying them all.

This might be you, but not the rest of the world. Also, people are hardly 
trying to develop large and nifty features in their debian/patches/ 
seriously. These are for tracking divergencies, not accepted upstream X.Y for 
any reason.

> > ... 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.
>
>         Nice, but hardly very relevant to the point.
>
>         Because reading feature N quilt patches  is harder, since it does
>  not apply directly to upstream, but to upstream + N -1 patches, which
>  is tricky. Unless you have non serialized independent topic patches,
>  that all apply to upstream, reading all but the first patch is harder.

Sorry, but non of them is a superior method wrt perspicuity.

> >>         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.
>
>         Oy vey. Reading about a specific feature with serialized patches
>  is not easy. Selecting Feature A and Feacure F and looking to see how
>  they interact without anything else is not easy.
>
>
>         Quilt sucks there.
>
>         But you prefer to ignore that, and instead accuse me of hiding
>  my head in the sand. But that's irony for you.

Again not on topic, the context is point 2, which you are ignoring: 
http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2008-October/000378.html

>         I have also considered ./debian/topics; with one patchset per
>  topic, so people can study the divergence, but ship the integration
>  branch, making it easy for people to look at each feature by itself, or
>  look at them all.
>
> >>         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.
>
>         Seen a failure in my packages? or some other red herring? Why
>  are the divergences hidden if they are in a separate feature branch? It
>  is easy to look at how each topic branch diverges from upstream --
>  that is why they are ca;;ed topic branches.

I personally do not want to look at your diff.gz files released with lenny in 
order to find your divergencies from upstream tar, and I really hope I won't 
need to inspect your *public* branches and compare them to the source 
packages released.

Finally, I won't reply to joined messages resulting in complete mess wrt 
contexts involved. Your approach is well known, but doesn't scale well for 
the rest, but you.

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