On Tue, Sep 30 2008, Stefano Zacchiroli wrote: > On Mon, Sep 29, 2008 at 03:42:46PM -0500, Manoj Srivastava wrote:
>> c) Therefore, we need to additionally store the patch series generated >> from git branches into yet another git branch (presumably not one >> the patch series are generated from). >> >> Me, I hate c, and I think this is not something I am going to be >> doing, even if that schema is popular. > > In my vision, the patch series is just an interface for who, beside > the usual maintainer, have to interact with the package without having > to know the gory details of the user VCS or its branch layout. It is > not something to be used routinely: if I care enough about a package I > can take the time to learn the details of its maintenance. If I just > want to make a quick bugfix I don't. > Hence, I see no need of versioning the patch series. Having just the > last series, most likely in the Debian source package, would be > enough. Hmm. That would mean generating it in the clean target, I suppose. I can live with that. > I hope you agree that clean .diff.gz (i.e., only touching debian/) + > debian/patches/ has to be preferred over the status quo. 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. > The problem with the advent of DVCS, when they are used naively, is > that we will be back at the mess of .diff.gz, losing > debian/patches/. That is the problem we need to address. I've never had debian/patches/, and have not yet drunk the cool-aid, so for me it is not a regression. I think it is better to ship the sources that will be used to build from, from the view point of the casual contributor. No requirement to know how the patch serialization system works. Since I use my integration/build branch to build/test software before running dpkg-buildpackage on it, my work-flow does not include always re-applying patch series before testing. Ineed, I tend to hack away at code till it works, and then apply the changes to the branches they go into, splitting the changes as needed. Thank god for Emacs. > Finally, nobody talked about "ongoing development", I'm thinking at > hit-and-run patches and NMU. I want those contributors to be able to > contribute as easily as possible, and I do think that patch series > would help them. Hit and run patches and NMU's workbetter by just looking at the end result, and not mucking with topic branches and quilt series and redoing quilt patches. So a plain old diff.gz that gives the casual contributor the sources that were used to build the package from, and can be modified in place, makes most sense. >> I'm OK with releasing a patch series; but will not take patches >> to the patch series as contributions. Patches to patches are just >> silly, in my opinion. > > Agreed. In that scenario IMO the contribution can either be an extra > patch that apply somewhere in a patch series or a new version of an > old patch. No matter which of the 2, being able for the contributor to > distinguish the previously used patches is a plus. manoj -- "Though a program be but three lines long, someday it will have to be maintained." -- The Tao of Programming 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