[Ltrace-devel] ltrace still being maintained?

[Zach Welch]

On 10/05/2010 06:10 PM, Joe Damato wrote:
> On Tue, Oct 5, 2010 at 10:16 AM, Zach Welch <zwelch at codesourcery.com> wrote:
...
>> To this end, is there a public git tree that contains all of the changes
>> that should go into the next release? It would save a new maintainer a
>> lot of time to have these in one place, and it would have saved me time
>> to have used that instead of trying to work with the "stable" git tree.
> 
> Sure. I have a tree on github: http://github.com/ice799/ltrace

That will be an acceptable place to publish interim trees, but I had
been vaguely hoping that someone had been tracking the existing changes.
I guess that everyone assumed that the maintainer would be doing it.

I hope that we are able to pull the changes into the master repository
to make a release, but we can cross that bridge once we get to it.

> My libdl changes are on a feature branch called libdl. I can start to
> merge people's patches and then merge my branch in last since the
> changes are pretty extensive. I suppose the best way to do this would
> be to crawl through the mailing list pulling down the patches people
> have submit over the last year?

I had started to do this, but it is not easy to do from the archives when
the patches were attached rather than in-line. If you have a local
mailbox with all of the list traffic, then you may be able to import the
patches directly using 'git am'.

Otherwise, one must remember to preserve authorship, date, and other
metadata correctly. As a result of this, I cc'd the list with my ping to
Arnaud Patard to see if he has a public Git repository for pulling his
patches. That would be my preferred approach for importing his series.

Likewise, Marc Kleine-Budde's tree contains patches that add full
support for autotools, which I am also in favor of merging:
   git://git.pengutronix.de/git/mkl/ltrace.git
Or, to view:

http://git.pengutronix.de/?p=mkl/ltrace.git;a=shortlog;h=refs/heads/dev/autotools

> I'll have time later this week/weekend to start merging in some
> patches I've seen floating around. I'll make a list and we can try to
> coordinate to make sure they are all getting in.

Hopefully, other folks lurking on the list will remind us of specific
patches that need to be merged. We shouldn't count on ourselves to find
them all. When an upstream trickles off, distributions can begin to
absorb the flow of patches directly. Thus, pushing out a new release
may provide incentive to those contributors, and their changes will
start to be pushed into the reborn upstream.

-- 
Zach Welch
CodeSourcery
zwelch at codesourcery.com
(650) 331-3385 x743