On Fri, 4 Jan 2013, Yang Tse wrote:

First: thanks a lot for your calm and sensible approach to this Yang.

> If the above mentioned two workarounds are not enough to overcome so called
> 'breakage of history across renames' it is not libcurl's fault, It is simply
> git's and github's idiosyncrasy, lack of features or design limitations, you
> choose. In any case we would be accepting that, intentional or not,
> limitations on current version control system (git) or relative tools
> (Github, gitk and others) restricts project development, organization and
> freedom on what the project can do and what not.

We use tools for version control. These tools have limits and drawbacks. We
need to live with these limits as good as possible. Pretending that they don't
exist will not help us. When we used CVS we basically *never* renamed because
of CVS' complete lack of support for it. When we changed to git we got a lot
of more features and support but some things are still hard or tricky, and
file renaming are one of those things that will remain hard to get really
smooth in *all* version control systems so I think it is still a good idea to
only rename when really necessary. At least these days we don't lose history
in renames.

> For libcurl public versions there should be no need to be doing that kind of
> cherry-pick backporting, we grant backwards compatibility, although I
> understand that once in a while there exists the possibility that some 'lets
> call it distro' might want to release a downstream interim release with some
> specific bug fix.
>
> Can someone, please, point out distros which do this kind of libcurl interim
> releases?

This is a fairly common practise among many distributions. I see it all the
time, and it isn't really "interim releases" in their view but instead bug
fixes to an existing release. Distros release [curl version]-[distro num],
where [distro num] will get increased for every new release they do of the
same upstream version. Mostly I see them do that with bug fixes, and
especially if the bug report originates from within their own bug trackers -
and often the actual fix is even provided or worked on by people from that
distro. And of course distros tend to maintain a number of different versions
at once.

The sort of patches I also see a lot of that I had in mind originally are
those that more special purpose distributions do. Things that they think their
users should have but aren't done in ways that they think are suitable for us
in the curl project. They then make a patch for their own build/source that
can remain lingering in their build system for a very long time. We've seen
this in several embedded focused distros but we've also seen it done by
FreeBSD and others.

All this said: I don't think we need to bend over backwards to help
distributions do funny patching. But I think we should keep this downstream
infrastructure in mind so that we don't upset or cause unnecessary grief to
them as they actually help users use our project.

> So please, either way express yourselves again. I don't want to goof it
> twice in a row.

I've re-read the arguments and I've really given this some extra thoughts
since I last spoke up. I am in favour of pushing the revertion commit.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html