I see Darrell wants to make many changes in libnyquist and other lib-src

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

I see Darrell wants to make many changes in libnyquist and other lib-src

Paul Licameli
This pertains to merge request 161 https://github.com/audacity/audacity/pull/161

for cross-compilation.

Generally we don't want our lib-src to diverge much from their origins, right?

But at least in the case of Nyquist Roger may take proposed changes upstream.

What should be done with this merge request?

PRL


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: I see Darrell wants to make many changes in libnyquist and other lib-src

James Crook
On 3/18/2017 7:42 PM, Paul Licameli wrote:

> This pertains to merge request 161
> https://github.com/audacity/audacity/pull/161
>
> for cross-compilation.
>
> Generally we don't want our lib-src to diverge much from their origins,
> right?
>
> But at least in the case of Nyquist Roger may take proposed changes
> upstream.
>
> What should be done with this merge request?

I think that needs to be decided by the release manager.

--James.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: I see Darrell wants to make many changes in libnyquist and other lib-src

Darrell Walisser
In reply to this post by Paul Licameli

On Sat, Mar 18, 2017 at 3:42 PM, Paul Licameli <[hidden email]> wrote:
This pertains to merge request 161 https://github.com/audacity/audacity/pull/161

for cross-compilation.

Generally we don't want our lib-src to diverge much from their origins, right?

But at least in the case of Nyquist Roger may take proposed changes upstream.

What should be done with this merge request?

PRL


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: I see Darrell wants to make many changes in libnyquist and other lib-src

Paul Licameli
I suggest a separate branch for those, and let Roger decide what to do.

PRL


On Sat, Mar 18, 2017 at 4:11 PM, Darrell Walisser <[hidden email]> wrote:

On Sat, Mar 18, 2017 at 3:42 PM, Paul Licameli <[hidden email]> wrote:
This pertains to merge request 161 https://github.com/audacity/audacity/pull/161

for cross-compilation.

Generally we don't want our lib-src to diverge much from their origins, right?

But at least in the case of Nyquist Roger may take proposed changes upstream.

What should be done with this merge request?

PRL


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: I see Darrell wants to make many changes in libnyquist and other lib-src

Darrell Walisser
In reply to this post by Darrell Walisser
I 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: I see Darrell wants to make many changes in libnyquist and other lib-src

Paul Licameli
These seem like good ideas, it would only generalize what we did with my patches for wxWidgets.

I have heard of the submodules feature of git, but have no experience using it.  Basically, one git repository can point at another, and include its files when populating its working tree.  Is that right?

PRL


On Sat, Mar 18, 2017 at 5:04 PM, Darrell Walisser <[hidden email]> wrote:
I 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: I see Darrell wants to make many changes in libnyquist and other lib-src

Darrell Walisser


On Sat, Mar 18, 2017 at 5:10 PM, Paul Licameli <[hidden email]> wrote:
These seem like good ideas, it would only generalize what we did with my patches for wxWidgets.

I have heard of the submodules feature of git, but have no experience using it.  Basically, one git repository can point at another, and include its files when populating its working tree.  Is that right?

​Yes, the repository stores a link/reference to another repository. They are not included by default when cloning. However, can be setup so that "git submodule init" will fetch each submodule (with the correct branch/commit etc).


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: I see Darrell wants to make many changes in libnyquist and other lib-src

Darrell Walisser
In reply to this post by Paul Licameli
New PR for Nyquist only.


On Sat, Mar 18, 2017 at 5:00 PM, Paul Licameli <[hidden email]> wrote:
I suggest a separate branch for those, and let Roger decide what to do.

On Sat, Mar 18, 2017 at 4:11 PM, Darrell Walisser <[hidden email]> wrote:

On Sat, Mar 18, 2017 at 3:42 PM, Paul Licameli <[hidden email]> wrote:
This pertains to merge request 161 
​​
https://github.com/audacity/audacity/pull/161

for cross-compilation.

Generally we don't want our lib-src to diverge much from their origins, right?

But at least in the case of Nyquist Roger may take proposed changes upstream.

What should be done with this merge request?

PRL


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: I see Darrell wants to make many changes in libnyquist and other lib-src

Darrell Walisser
I've checked the Nyquist upstream (https://sourceforge.net/projects/nyquist) and it does not include the libnyquist wrapper where most of the changes are.

Except for https://github.com/audacity/audacity/pull/187/commits/da1aef01dcdce15cfb1642e59e9c3c1712aaf054, there are no changes to Nyquist. And this patch is simply renaming files and making a new file specific to mingw builds.

If I also include a patch file for this commit, following what's been done with the other patch files in lib-src/ will that be sufficient to get this merged?

Thanks,
Darrell

On Sun, Mar 19, 2017 at 5:21 PM, Darrell Walisser <[hidden email]> wrote:
New PR for Nyquist only.


On Sat, Mar 18, 2017 at 5:00 PM, Paul Licameli <[hidden email]> wrote:
I suggest a separate branch for those, and let Roger decide what to do.

On Sat, Mar 18, 2017 at 4:11 PM, Darrell Walisser <[hidden email]> wrote:

On Sat, Mar 18, 2017 at 3:42 PM, Paul Licameli <[hidden email]> wrote:
This pertains to merge request 161 
​​
https://github.com/audacity/audacity/pull/161

for cross-compilation.

Generally we don't want our lib-src to diverge much from their origins, right?

But at least in the case of Nyquist Roger may take proposed changes upstream.

What should be done with this merge request?

PRL



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel