v3 Debian source package formats

[Manoj Srivastava]

On Wed, Oct 01 2008, George Danchev wrote:

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

	Err. What I was sayingthat going out of the way to provide quilt
 series for vaporware helpers is a bad use of my energy. That does not
 help you; it does not prove in any way that people can not just use
 git.

        Sorry about that.

        Care to back up your statements o your own now?

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

        In what way am I missing important details?  Work flows are
 supposed to be simple, but simplistic?  What aspect of my work flows is
 simplistic? 

        Can you back up your ad hominem accusations here, or is it just
 vitriol and rhetoric?

        Yes, I do want to make my work-flow as streamlined as possible,
 so I can spend more time with the new policy process, and the docbook
 conversion. I don't want to shortchange the users of my packages, so
 the less time spent in the mundane details of packaging the better.

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

        Hmm, yes. I do not see VCS agnosticism via quilt as a a great
 solution.  Indeed, software development  right now does require
 knowledge of software tools, and VCS' are one of the tools. I think any
 serious software professional does need to have the common ones (git,
 svn, cvs, bzr, and hg) in their tool chest.

        Emacs has a gret package called dvc - that provides a consistent
 front end to all the VCS'  I mentioned above. You use the same commands
 irrespective of your actual VCS. Perhaps some front ends like that can
 be written (they are feasible, since one is already in place).


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

        I was hoping that a solution for cross distro patch sharing is
 going to work for more than toy patches. If not, this whole effort is a
 colossal waste of time.

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

        None of _what_? ALl i mentioned in the paragraph above is how
 quilt works. If you are saying quilt sucks, I agree.

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

        You really worry about the fact that when a developer tags
 somethings as rel-3.23-1 they are lying about what actually went into
 the package? Really?

        Man, this is one of the least serious things to be concerned
 about in collaborative development. Espescially since you can checkout
 the branch, unpack the sources, and _compare_, if you had to.

        a simple diff -qBbwr between the two directories can be done as
 a check. This is not a worthwhile issue in my eyes. So yes, I am
 ignoring this as a silly worry. Since it is so easy to check.

        

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

        Well, You look at the public branches to see the divergence. and
 if you think my repo does not match the sources (which is a trust
 issue, I suppose),  You'll have ot do whatever you need to, since
 obviously you do not believe my tagging.

        Frankly, none of the things you are saying make a compelling
 argument for quilt.  madduck makes a better case.

        manoj
-- 
Everyone hates me because I'm paranoid.
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C