On Thursday 03 January 2013 18:04:53 Yang Tse wrote:
> >> 3) On core dumps, and fatal happenings which trace the source file
> >> name of where the problem has been triggered, it becomes much easier
> >> for not expert souls to figure out if it is a libcurl problem or not.
> >
> > I would be surprised if this will help anyone. If you're clever enough to
> > read a back trace of a core dump to get info from it, I'm sure you can
> > figure out which library the functions belong to.
>
> Final users of apps which use libraries built debug enabled don't need
> to have a clue about programming and much less about debugging, but if
> the app fails in a way the OS is capable of telling the source file
> where the thing has 'failed' it will help the app developer to figure
> out which 'component' has failed.

You still need to know which _binary_ files are involved. The source files
themselves can be statically linked, copy/pasted, etc. There can be multiple
instances of curl code on the system you are debugging on.

> For example, knowing that the
> problem is not in a 'curl_*' file would automatically discard libcurl
> as the culprit.

Nope, other libraries are free to use the same prefix. Moreover, the fact
that you have a backtrace without a single occurrence of 'curl_*' file does
not discard curl as the culprit anyway because the root cause of a crash
needs not to appear in the backtrace in general.

> > Further downsides with the renames:
> >
> > * Patches for older curl versions now suddenly don't apply anymore and
> > will give us (and others) much more work to apply. This will not only
> > affect a couple of patches that I have pending in the mailing list but
> > also in the bug tracker. There's also about a bazillion distros out there
> > with distro specific patches that suddenly get version-specific file name
> > changes (where the patches could otherwise apply to multiple versions).
>
> Adapting the patch should be as easy as modifying the lib/*.[ch] diffs
> name.

Still less easy than just applying a patch. We already need to work around
autotools breakages, system header clashes etc. when bisecting old sources
of curl.

> > * History tracking/git log is much harder and annoying with file renames.
> > So while it can be handled, things like the github's history breaks and
> > bisecting things will require more work.
>
> While true that git history tracking is a bit inconvinient on renames.
> The commits of these renames have been done in a way that history
> tracking should actually represent no problem. These commits which do
> the renames only rename the files, zero changes in such commits except
> for the file renaming. So why doesn't git pull the history of the
> original file into the renamed one? After all all the info is there
> for it to use.

From my point of view, splitting the rename to a separate commit only
complicates the maintenance since it breaks the basic assumption that
each snapshot is buildable.

> Additionally we have the multi-allways patch that is going into
> libcurl soonish. Trying to bisect across that patch will make little
> sense at all. libcurl internals will be definitively changed that if
> it has not already happened with the 'bundles connection cache'
> modification. Unless I misinterpreted you I thought libcurl 7.29.0 was
> going to be a no-return point. I may be wrong but i believe that it
> might carry some external functional behavior change in 'pingpong'
> based protocols (ftp, pop3, imap, smtp).
>
> So, if history was to be 'broken' at some point, now might be the best
> moment to do so.

Sure, but there must be a good _enough_ reason for breaking the history.

> ----------------------------------------
> @Kamil...
> ----------------------------------------
>
> On Thu, Jan 3, 2013, Kamil Dudka wrote:
> > We often backport upstream fixes for
> > ancient versions of (lib)curl, which are still supported in the
> > Enterprise Linux. I know this is our business, but the less time we
> > spent on backporting fixes the more time we have to help upstream.
>
> Please clarify if you oppose the renaming or not.

Sorry, if my response was unclear. I prefer NOT to do any major changes
that are not necessary. We have enough work with the never ending white-space
changes all over the code (although, in my opinion, curl sources are still
pretty stable compared to GNU projects, etc.).

Kamil

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-01-03