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
