Re: Introductory mail
On Tue, Sep 30, 2008 at 10:27:13PM +0200, Martin Bähr wrote: On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote: Not really. I prefer to have the source packages be unpackged even on a machine which does not run Debian, using just plain old tar and patch. Thus I tend to ship the diff.gz as something that creates the set of bytes the package build was done from, and which is extracted easily without you having to have dpkg installed. I see the source package as something useful perhaps even in a non distro specific setting. indeed, they are. but exactly for working outside of debian it would be preferable to have the patches easely accessible seperately. i occasionally try to pick patches from other distributions when packaging for foresight because in the end we share most of the problems and patches for it. to work with a debian package i currently have to pull out the patch from the diff either by applying the diff to the source or by manually editing the diff file. from fedora i can just download the patch from fedoras cvs, in fact, if i don't need to edit the patch, then i can just directly refer to the cvs url in conary recipes, thus making it very obvious where the patch comes from: r.addPatch(http://cvs.fedoraproject.org/viewvc/rpms/cone/F-9/cone-gcc43.patch?revision=1.1;) Patches are easily accesible from within gitweb (using Vcs-Browser) when the package uses git-dch to generate the changelog. Git-dch allows to store the abbreviated commit id in the changelog so people can find patches easily by looking at the changelog first: libvirt (0.4.6-1) experimental; urgency=low * [e20d3d4] Imported Upstream version 0.4.6 * [0c840ab] disable numactl ... then using git-web: http://git.debian.org/?p=pkg-libvirt/libvirt.git;a=commitdiff_plain;h=0c840ab Cheers, -- Guido ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
patch series does not make VCS obsolete (was: Introductory mail)
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.01.0302 +0200]: Only if you like working with patch series, and prefer to lose all the information that the original VCS contained. I prefer to see the whole history, not just a snapshot, when I am joining a development effort. Manoj, please stop seeing things black and white. By providing a patch series in the source package, you are not losing all the information that the original VCS contained, as the original VCS will still be around and will serve up all the history to those who want it. All that's happening is that the changes between upstream and what is packaged for Debian aren't merged and dumped into one, gigantic, monolithic diff, from which it's not exactly easy to extract single features. Instead, separate features are kept in separate patches, and a series file tells anyone, not just quilt, in what order the patches should be applied. This - makes it a lot easier for everyone to extract features from the source package; - still allows people to create monolithic patches over the whole source package, because debian/rules patch will prepare the source tree accordingly, and the v3 quilt format will even make that unnecessary; - still allows you to keep using your treasured VCS - still allows everyone to inspect the history in your VCS, or use it instead of the source package. -- .''`. 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 it's practically impossible to look at a penguin and feel angry. 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
v3 Debian source package formats (was: Introductory mail)
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.01.0302 +0200]: This is a strawman, really. The options are not the giant big diff vs quilt (equally horrible, IMHO). The options are 3.0 (quilt) vs 3.0 (git). I would have gone for the 3.0 (git) format myself, except that it does not support submodules. It's also overkill and a bad idea due to its complexity, as Martin said. Dig through the threads linked from http://vcs-pkg.org to find all the other arguments against it, especially by Pierre, who probably knows more Git than you and I together. If I were asked about which source package format will become standard in Debian for squeeze or squeeze+1, I'd have to say v3 quilt, for *sure*. The git/bzr were nice ideas but are never going to make it, IMHO. -- .''`. 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 perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- antoine de saint-exupéry 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
Re: extracting patches from the ancestry graph
On Wed, Oct 01 2008, martin f krafft wrote: Assuming we have a number of feature branches, we may well have to resolve conflicts among them, so an integration branch seems like the right way forward. So unless we just build the package from the integration branch to produce a monolithic patch, your algorithm is something to focus on! I am still not convinced that it is possible to extract historic patches from the ancestry of a tag on the integration branch, but I'd love to be proven wrong! Unfortunately, I won't be able to look into this again before next week. Slightly off topic, but there are other reasons to have a real, published integration branch. People who do not use the 3.0 (quilt) source package format and dpkg, for instance, people browsing the repo, will not have the automagic conversion of the quilt series into code the package is built from. If the integration branch is published, even casual browsers of code can see what the package did. manoj -- A man is not complete until he is married -- then he is finished. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: extracting patches from the ancestry graph
Quoting Manoj Srivastava [EMAIL PROTECTED]: On Wed, Oct 01 2008, martin f krafft wrote: Assuming we have a number of feature branches, we may well have to resolve conflicts among them, so an integration branch seems like the right way forward. So unless we just build the package from the integration branch to produce a monolithic patch, your algorithm is something to focus on! I am still not convinced that it is possible to extract historic patches from the ancestry of a tag on the integration branch, but I'd love to be proven wrong! Unfortunately, I won't be able to look into this again before next week. Slightly off topic, but there are other reasons to have a real, published integration branch. People who do not use the 3.0 (quilt) source package format and dpkg, for instance, people browsing the repo, will not have the automagic conversion of the quilt series into code the package is built from. If the integration branch is published, even casual browsers of code can see what the package did. Publishing your integration branch is nice, but you have made too many naive assumptions here: 1) people do not need quilt nor dpkg to view and apply these patches 2) there is no guarantee that what you have in your publicly browsable integration branch is actually what buildd are fed with to produce the binary packages users use and are interested in changes done. 3) you are leaving non-internetworked users in the cold, but Debian operates in such places. ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: extracting patches from the ancestry graph
On Wed, Oct 01 2008, George Danchev wrote: Quoting Manoj Srivastava [EMAIL PROTECTED]: On Wed, Oct 01 2008, martin f krafft wrote: Assuming we have a number of feature branches, we may well have to resolve conflicts among them, so an integration branch seems like the right way forward. So unless we just build the package from the integration branch to produce a monolithic patch, your algorithm is something to focus on! I am still not convinced that it is possible to extract historic patches from the ancestry of a tag on the integration branch, but I'd love to be proven wrong! Unfortunately, I won't be able to look into this again before next week. Slightly off topic, but there are other reasons to have a real, published integration branch. People who do not use the 3.0 (quilt) source package format and dpkg, for instance, people browsing the repo, will not have the automagic conversion of the quilt series into code the package is built from. If the integration branch is published, even casual browsers of code can see what the package did. Publishing your integration branch is nice, but you have made too many naive assumptions here: 1) people do not need quilt nor dpkg to view and apply these patches 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. I do not think this is a naive assumption on my part. On the contrary. 2) there is no guarantee that what you have in your publicly browsable integration branch is actually what buildd are fed with to produce the binary packages users use and are interested in changes done. 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. 3) you are leaving non-internetworked users in the cold, but Debian operates in such places. 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. manoj -- Speer's 1st Law of Proofreading: The visibility of an error is inversely proportional to the number of times you have looked at it. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: v3 Debian source package formats
* Manoj Srivastava [EMAIL PROTECTED] [081001 20:46]: 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. But why aren't these patches going upstream? Upstream *is* the sharing point between distros. a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
