v3 Debian source package formats

[Manoj Srivastava]

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. Also, there is a
 tradeoff: the hoops actual workers have to jump through in order to
 make things _possibly_ easier for vaporware potential contributors.

        Hmm.

>>         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.

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.

> ... 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.
>
>>         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.

        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.

        Oh, sorry for not having drunk the quilt cool-aid.

        manoj
-- 
"We live, in a very kooky time." Herb Blashtfalt
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C