patch series or not?

[Manoj Srivastava]

On Wed, Oct 01 2008, Stéphane Glondu wrote:

> Manoj Srivastava wrote:

>>> I find it quite unenviable to adopt a package
>>> for which the source package is just one giant .diff.gz, because it
>>> means either learning potentially elaborate tools to extract the
>>> individual patches, or manual splitting... For this, the new source
>>> format based on quilt seems just great.
>> 
>>         This is a strawman, really. [...]
>
> You really think so?
>
> Just to be curious, imagine I am working with a workflow of my own, and
> a VCS of my own (I mean, something you don't already know... does that
> exist? :).

        Sure. Never used bitkeeper or perforce or any other non-free
 software. (rcs, cvs, subversion, arch, bazaar, bzr, mercurial, darcs,
 git are all I know).

> I am maintaining several packages you are interested in, and
> I (and nobody else) don't want anymore. For some reason (e.g. an
> accident), I cannot help you either. Will you really learn my VCS and
> understand my workflow to get the history? If yes, just say so, and the
> discussion will be closed for me. If no, would you have preferred that I
> had made releases with giant .diff.gz touching upstream files, or rather
> with patch series?

        I'd learn your VCS (and have, in the past, this is why I know
 bzr and mercurial). Failing that (if you used a non-free VCS), I would
 prefer the separated patches -- but I could also live with taking the
 big diff.gz apart. In the latter case, I would learn more about the
 changes and do an security audit better, I suspect, so it is not that
 much of a drawback.

        Would need to do a security audit of your changes anyway.

>> [...] 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.
>
> IMHO, git is far too complex to be a source format (meaning: forcing
> everyone to have to deal with). Besides, the raw format is too complex
> to deal with using simple shell scripts (not using git). On the
> contrary, the quilt format just needs tar and patch. This seems more
> suitable for something which is meant to last forever.

        git is free software, so the requirement to install git is not
 an argument. If you can learn how to use quilt, and you can figure out
 how to build my packages, and you are capable of providing the
 stewardship for my package, you will not have a problem picking up
 git.

        Just like all code does not have to be written in visual basic
 to allow people to take over,  using svn/git/hg is not prohibited,
 IMHO.  I do not often cater to the lowest common denominator. I would
 be using windows, if I were so inclined, and this discussion would be
 moot. 


>>         The quilt format is the least preferred, for me, since it loses
>>  all the history. Given that, I am not going to go out of my way to
>>  support it. If topgit makes it simple, perhaps.
>
> It loses history, sure. But (hopefully) not the semantics of patches.
> Moreover, the patches can be documented themselves. Do you do
> long-standing development on your patches?

        Some of my feature branches in make and vm are 11 years long
 now, and have been preserved through CVS, arch, and now git.

> Quoting another mail from you:
>>         Not really. All my upstream like to have a single topic patches
>>  series rebased to their latest release --  and very few of them are
>>  using modern VCS's yet. So, yes, it is fed back upstream, but not
>>  directly into the upstream VCS where I have no commit rights anyway. 
>> 
>>         The patches are submitted by whatever mechanism  the upstream
>>  wants them to be submitted.
>
> At least, if you are able to do this, this is kind of fine.

        git has lots of facilities to convert a (feature) branch into a
 series of emails.

        manoj
-- 
Peter's Placebo: An ounce of image is worth a pound of
performance. Laurance J. Peter
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C