Introductory mail

[Manoj Srivastava]

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 <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C