also sprach Manoj Srivastava <[EMAIL PROTECTED]> [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. <[EMAIL PROTECTED]> 2. cf. <[EMAIL PROTECTED]> 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. <[EMAIL PROTECTED]> on debian-devel 6. <[EMAIL PROTECTED]> -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : 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
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss