the goal of vcs-pkg (was: v3 Debian source package formats)

[martin f krafft]

also sprach Manoj Srivastava <srivasta at acm.org> [2008.10.02.0236 +0200]:
>         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).

Yes, I'd say this is one of the goals of vcs-pkg: to create
a VCS-agnostic tool that supports cross-distro packaging workflows.

To do that, we first need to establish what's in a workflow. Manoj's
workflow seems fundamentally different, but it's not:

  - his debian/common/ is basically just like debhelper or cdbs
  - his debian/ is a submodule, while it seems most common these
    days to maintain debian/ as a subdirectory in a branch. Both of
    these approaches surely have advantages and disadvantages, and
    maybe Manoj could start a table on the wiki allowing us to
    compare the two approaches[0].

    When I said yesterday that having submodules isolates
    maintainers[1], I was referring to the benefits of having
    a common ancestry to all debian/ directories in all your
    packages. However, assuming I take over a package from Manoj,
    that ancestry doesn't really matter to me anymore, I just
    basically create a fork.

So I think we need to compare submodules to branches for
storing/tracking debian/, and otherwise just assume they are the
same for the rest of this discussion.

If we can do this, then let's look at what is actually happening.
I can see people using/toying with two approaches[2]:

  1. a. track package and topics in VCS,
     b. merge changed branches into an integration branch,
     c. tag,
     d. build.
  2. a. track package and topics in VCS,
     b. merge changed branches into an integration branch,
     c. export patches into a quilt series,
     d. store patches in build branch
     e. tag,
     f. build

This is surely simplified[3], but do you see the point? We are
basically talking about the same thing. More specifically: given
a VCS repo with topic branches, it's trivial to cater to both.

Manoj (and others) vehemently oppose to a patch series[4] and prefer
a monolithic diff.gz, and I think that's because of either of two
reasons, or both:

  1. they don't want extra work to obtain the patch series,
  2. they don't see the benefit of source packages based on a patch
     series.

I hope TopGit (and similar tools), and especially the vcs-pkg
packaging tool we'll hopefully develop at the end of all this, will
make (1) a non-issue. Let's assume that it won't be much work to
create this patch series, and I think I am not too idealistic in
saying this.

Wrt (2), I think efforts like patch-tracking.debian.net (aka.
patches.debian.net btw., and also patches.ubuntu.com[5]) and the v3
source package format speak for a patch series and against
a monolithic diff, *especially* because the patch series can always
be squashed into a monolithic diff, but not vice versa.

Sure, quilt does not allow you to test only topics A and
F together[6], but neither does a monolithic diff.

I think one of the core issues is that Manoj likes the fact that
creating the source tree right now can be done with a single tar
+ a single patch invocation, and I like that too, mainly because
I've been doing it for 12 years. patch is a *standard*. I agree that
quilt might already be too complex to ever make it into the ranks of
those tools, but as I said before, we don't actually need quilt:
it's just a series of patches, so instead of your single patch
invocation, it's now a for loop.

Given the benefits of splitting a monolithic diff into patches, I'd
say that in 12 years, we're likely going ot have forgotten that we
ever had anything else than debian/patches/*.

So I guess what I am trying to say is: let's move forward. Let's

- figure out how to extract historic packages from VCS using tools
  like TopGit,
- figure out how we can unify workflows using submodules and
  branches, ideally with a qualitative comparison of the two,
- figure out the actual steps of packaging, with the goal to
  automate them in a flexible manner.



0. on a side note, I seem to have come across a little snarky
   yesterday, and at least Manoj thinks I despise submodules. That's
   not true. I don't know enough about the implications of using
   them for Debian yet, so I have reservations. However, I think
   that submodules or not is only a minor facet of the whole
   discussion (which is what I am trying to argue in the above, and
   I was simply getting annoyed by how the discussion only focused
   on this stuff...
1. <20081001093353.GC31092 at piper.oerlikon.madduck.net>
2. cf. <20080930205430.GA5744 at piper.oerlikon.madduck.net>
3. in the context of my topgit workflow: the integration branch in
   (b) is called stage-* and is short-lived, which may or may not be
   a good idea; I didn't think too much about it yet.
4. I purposely call it a patch series, not a quilt series: it's just
   patches, I don't need quilt to process them, although it's a lot
   easier with quilt.
5. cf. <20080517120743.GS7654 at vuntz.net> on debian-devel
6. <87r670t6z3.fsf at anzu.internal.golden-gryphon.com>

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"literature always anticipates life.
 it does not copy it, but moulds it to its purpose.
 the nineteenth century, as we know it,
 is largely an invention of balzac."
                                                        -- oscar wilde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20081002/c2c74fa3/attachment.pgp