These seem like good ideas, it would only generalize what we did with my
patches for wxWidgets.
it. Basically, one git repository can point at another, and include its
files when populating its working tree. Is that right?
Post by Darrell WalisserI am spit-balling here, since I probably can't appreciate all the issues
of lib-src, but have we considered managing the libs as separate
repositories? We are already doing this for wxWidgets...and it seems like a
good idea. Mainly because it is not likely all patches will be accepted,
and either way you don't want that process to stall Audacity development.
What if for every external library ("thelib") that must be tracked
upstream, we do the following (as in wxWidgets fork)
- Setup audacity/thelib as a fork. If there is no github available to
fork, base from the appropriate release tarball, etc.
- Apply our patches into a new branch "audacity"
- Submit and track PR(s) via github. Otherwise post patches to mailing
lists, etc. Maybe track manually via wiki or bugzilla.
- In lib-src, nuke our copy of thelib and use git submodule feature to
link to the fork
- If it helps, add a shell script ("lib-src/bootstrap.sh") to refresh the
submodules and/or do any other management of the submodules
- Use tags or branches in the submodules to track which version shipped
with which releases of Audacity
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel