[Sparkle] Merging our changes back in

[Andy Matuschak]

Hey, Uli! That'd be awesome! Here's my general order of preference for  
patch submissions:

1. Make a bzr branch and nominate it for merging (see http://andymatuschak.org/articles/2008/06/01/a-guide-to-contributing-to-sparkle/ 
  for details). This provides tracking, robust merging, and includes  
your commit logs in the official revision history.

2. Send me a .patch. It'll often take me a while to get around to  
merging it in, since there always seem to be conflicts this way.

3. Send me your source tree. The problem with this is that I always  
put off merging these in as long as possible since they're a big  
hassle, which makes them a bigger hassle when I actually do the  
merging, since everything's changed. I'd appreciate it if we could  
avoid submissions this way.

Given that your stuff is before the Great Refactoring, you should  
probably send me a patch against the codebase at the revision you were  
working off of, so I can see what you changed.

Thanks!

- Andy Matuschak

On Jul 15, 2008, at 5:54 AM, Uli Kusterer wrote:

> Andy,
>
> we did oodles of little bugfixes and other changes to Sparkle, but  
> to the old, last released version. I'm not sure I'll find the time  
> to actually merge them all into the new Sparkle soon (been meaning  
> to do that for half a year now), so I was wondering if you want the  
> modified version anyway? How would one best submit those changes  
> after The Great Refactoring Of 2008 ? Do you want a patch against  
> the old version? Or just our changed code and you'll diff it against  
> a copy of the old code with your favorite tool yourself?
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
>
>
>
>
>
> _______________________________________________
> Sparkle mailing list
> Sparkle at lists.andymatuschak.org
> http://lists.andymatuschak.org/listinfo.cgi/sparkle-andymatuschak.org