the goal of vcs-pkg

[Manoj Srivastava]

On Thu, Oct 02 2008, martin f krafft wrote:

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

        Now suppose you have your _own_ heirarchy of debian
 directories.  You can just change the submodule location, which is only
 referred to in the build branch, and continue with ever other feature
 branch inherited straight from me.

        Indeed, you can develop in parrallel with me, getting all the
 feeds, and yet have the comfort of your own  build system using
 debhelper as opposed crazy manoj build system.

        Making the packaging, which changes from developer to developer
 (cdbs, debhelper, debhelper7, yada, custom) allows for _easier_
 exchanges, since only the submodule location changes.

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

        If I thought a serialized patch series had sufficient benefits, I
 would do the work.


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

        I would prefer ./debian//topics, where I have one patch series
 per topic, which all applies to upstream, and then people can try any
 feature they want, one at a time, or all the features at once, by using
 the integratiopn branch. The patches for each independent feature can
 still be put pu on a wen site.

        The argument is not features-as-patches that I disagree with, it
 is serialization that I have a basic misgivings about.


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

        The debian/topic patches do. As does the public git repo.

        The argument is not to defend the giant diff.gz. It sucks as a
 development base. At best, the diff.gz gives you the integration
 branch, but most development is done in pure topic branches.

        The debian/topic patches give you a pure topic topic branches,
 and the diff.gz give you the integration branch, which is a snapshot of
 my development system.

        I prefer this to serialized patches.

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

        Well, I can see using the diff.gz to get the integration branch,
 and use the debian/topic for feature branches. I do not see much value
 in building the integration branch on the fly from serialized feature
 branches.

        I think providing the integration branch, and each pure feature
 branch via patches, is strictly superior to just providing serialized
 (impure) feature branches and generating the integration or build
 branch on the fly.

        The topic branches allow people to start with the orig.tar.gz
 and apply each feature branch individually to test it out, and be ahead
 of hte game in trying out a minor subset of features.

        It makes it easier for downstream or upstream to cherry pick one
 feature, which is harder when you order and serialize the patches.

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

        I would like to see your thoughts on non-serialized topic
 branches, which can be used to understand where the diff.gz/integration
 branch came from.

        I would also like to stress while I do not like serialization, I
 am not actually opposed to providing patch sets in the sources to allow
 people to replicate the development environment --- which is better
 done, UMHO, with pure feature patches and an integration branch patch
 (the dsiff.gz).

        manoj
-- 
COBOL: Completely Over and Beyond reason Or Logic.
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C