patch series or not? [Was: Re: Introductory mail]

[Stéphane Glondu]

Manoj Srivastava wrote:
>         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. 

I agree.

> 
>> 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? :). 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?

> [...] 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.

>         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?

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.

-- 
Stéphane

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20081001/08cb743b/attachment.pgp