[Audacity-devel] Policy on lib-src files?

[James Crook]

Of our nine open pull requests, 6 are stalled mainly because of lib-src
changes.

The underlying problem is that we don't record our changes to libs we
use very well, and we aren't communicating about changes up tream. This
is particularly so for wxWidgets.

Since we now are using Git, we could make a branch for each library and
record changes in that branch, and then merge that branch into master.
At the moment we instead work hard to avoid making any changes to the
libraries at all.


Should we be more relaxed about making changes in lib-src in Git? Who
has ideas about how to do things so that:

- lib-src changes don't hold up PRs.
- We know what changes have been made in each lib
- If we miss something 'at the time' and don't record it, we spot it later.
- Users who choose to use upstream versions of libs are alerted to
potential issues.
- We are using the 'same' version on all platforms, not different
patches for different platforms.
- We are 'lightfooted' on changes, putting new functionality in our own
code in preference to in the lib.
- Upstream know about the changes.
- We know when upstream have 'better' fixes.
- We can apply changes we have made in the past relatively easily when
we upgrade libs to new versions.

It seems to me there is a lot of work in making this work. Without it
we seem to need to treat some good PRs as
'experimental/for-the-adventurous', with the risk that those PRs will go
out of date quite quickly.

How should we proceed?

--James.

------------------------------------------------------------------------------

[Paul Licameli]

As I recall I made a small change in lib-src with James' approval to
address a bug involving "malicious" data files. What was done with that?

We have duplications of the third party libraries in our git source tree.
Perhaps the thing to do is figure out git's sub-modules, so that instead of
duplication, our repository can include other repositories by reference.
No, this won't be simple, but it might address some of the problems on that
list.

PRL

Post by James Crook
Of our nine open pull requests, 6 are stalled mainly because of lib-src
changes.
The underlying problem is that we don't record our changes to libs we
use very well, and we aren't communicating about changes up tream. This
is particularly so for wxWidgets.
Since we now are using Git, we could make a branch for each library and
record changes in that branch, and then merge that branch into master.
At the moment we instead work hard to avoid making any changes to the
libraries at all.
Should we be more relaxed about making changes in lib-src in Git? Who
- lib-src changes don't hold up PRs.
- We know what changes have been made in each lib
- If we miss something 'at the time' and don't record it, we spot it later.
- Users who choose to use upstream versions of libs are alerted to
potential issues.
- We are using the 'same' version on all platforms, not different
patches for different platforms.
- We are 'lightfooted' on changes, putting new functionality in our own
code in preference to in the lib.
- Upstream know about the changes.
- We know when upstream have 'better' fixes.
- We can apply changes we have made in the past relatively easily when
we upgrade libs to new versions.
It seems to me there is a lot of work in making this work. Without it
we seem to need to treat some good PRs as
'experimental/for-the-adventurous', with the risk that those PRs will go
out of date quite quickly.
How should we proceed?
--James.
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Post by Paul Licameli
As I recall I made a small change in lib-src with James' approval to
address a bug involving "malicious" data files. What was done with that?
We have duplications of the third party libraries in our git source tree.
Perhaps the thing to do is figure out git's sub-modules, so that instead of
duplication, our repository can include other repositories by reference.
No, this won't be simple, but it might address some of the problems on that
list.
PRL

sub-modules seem to be a can of worms. I'd sooner avoid them if we can.
I think we are better off being disciplined about changes to lib-src.
Maybe there are scripts we can run that will tell us what files have
been changed in lib-src.

--James.

Post by Paul Licameli

Post by James Crook
Of our nine open pull requests, 6 are stalled mainly because of lib-src
changes.
The underlying problem is that we don't record our changes to libs we
use very well, and we aren't communicating about changes up tream. This
is particularly so for wxWidgets.
Since we now are using Git, we could make a branch for each library and
record changes in that branch, and then merge that branch into master.
At the moment we instead work hard to avoid making any changes to the
libraries at all.
Should we be more relaxed about making changes in lib-src in Git? Who
- lib-src changes don't hold up PRs.
- We know what changes have been made in each lib
- If we miss something 'at the time' and don't record it, we spot it later.
- Users who choose to use upstream versions of libs are alerted to
potential issues.
- We are using the 'same' version on all platforms, not different
patches for different platforms.
- We are 'lightfooted' on changes, putting new functionality in our own
code in preference to in the lib.
- Upstream know about the changes.
- We know when upstream have 'better' fixes.
- We can apply changes we have made in the past relatively easily when
we upgrade libs to new versions.
It seems to me there is a lot of work in making this work. Without it
we seem to need to treat some good PRs as
'experimental/for-the-adventurous', with the risk that those PRs will go
out of date quite quickly.
How should we proceed?
--James.
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Steve the Fiddle]

Many libraries that we use we do not include for Linux, and even for
those that we do include Audacity will often use system libraries
rather than our version. Getting fixes upstream asap would appear to
be the best option.

Steve

Post by Paul Licameli
As I recall I made a small change in lib-src with James' approval to
address a bug involving "malicious" data files. What was done with that?
We have duplications of the third party libraries in our git source tree.
Perhaps the thing to do is figure out git's sub-modules, so that instead of
duplication, our repository can include other repositories by reference.
No, this won't be simple, but it might address some of the problems on that
list.
PRL
sub-modules seem to be a can of worms. I'd sooner avoid them if we can.
I think we are better off being disciplined about changes to lib-src. Maybe
there are scripts we can run that will tell us what files have been changed
in lib-src.
--James.
Of our nine open pull requests, 6 are stalled mainly because of lib-src
changes.
The underlying problem is that we don't record our changes to libs we
use very well, and we aren't communicating about changes up tream. This
is particularly so for wxWidgets.
Since we now are using Git, we could make a branch for each library and
record changes in that branch, and then merge that branch into master.
At the moment we instead work hard to avoid making any changes to the
libraries at all.
Should we be more relaxed about making changes in lib-src in Git? Who
- lib-src changes don't hold up PRs.
- We know what changes have been made in each lib
- If we miss something 'at the time' and don't record it, we spot it later.
- Users who choose to use upstream versions of libs are alerted to
potential issues.
- We are using the 'same' version on all platforms, not different
patches for different platforms.
- We are 'lightfooted' on changes, putting new functionality in our own
code in preference to in the lib.
- Upstream know about the changes.
- We know when upstream have 'better' fixes.
- We can apply changes we have made in the past relatively easily when
we upgrade libs to new versions.
It seems to me there is a lot of work in making this work. Without it
we seem to need to treat some good PRs as
'experimental/for-the-adventurous', with the risk that those PRs will go
out of date quite quickly.
How should we proceed?
--James.
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------

[Richard Ash]

Post by Steve the Fiddle

Post by James Crook
Maybe there are scripts we can run that will tell us what
files have been changed in lib-src.

I think the concept we need is "vendor branches", or at least that is
what Subversion called it. The obsolete instructions I wrote for
updating libraries worked this way, and it's supposed to make it easy
to track what changes on top of upstream we have.

On Tue, 13 Sep 2016 15:41:39 +0100

Post by Steve the Fiddle
Many libraries that we use we do not include for Linux, and even for
those that we do include Audacity will often use system libraries
rather than our version. Getting fixes upstream asap would appear to
be the best option.

Absolutely, although some upstream release cycles are even slower than
ours, and we can often produce more test coverage by putting something
into a nightly than upstream can. So I'm relaxed about putting changes
into Audacity's git, provided that they are actively on their way
upstream at the same time.

This is probably one area where "drive-by" contributions will be
particularly problematic. Whilst I used to encourage people to submit
upstream when I was actively working on the library stack, I don't
think more than about half ever did, the rest I ended up submitting to
several upstreams myself (with some success, generally). It isn't hard,
but often does mean subscribing to mailing lists etc.

Richard

------------------------------------------------------------------------------

[Vaughan Johnson]

thx, Richard! Great info. -- V

Post by Richard Ash

Post by Steve the Fiddle

Post by James Crook
Maybe there are scripts we can run that will tell us what
files have been changed in lib-src.

I think the concept we need is "vendor branches", or at least that is
what Subversion called it. The obsolete instructions I wrote for
updating libraries worked this way, and it's supposed to make it easy
to track what changes on top of upstream we have.
On Tue, 13 Sep 2016 15:41:39 +0100

Post by Steve the Fiddle
Many libraries that we use we do not include for Linux, and even for
those that we do include Audacity will often use system libraries
rather than our version. Getting fixes upstream asap would appear to
be the best option.

Absolutely, although some upstream release cycles are even slower than
ours, and we can often produce more test coverage by putting something
into a nightly than upstream can. So I'm relaxed about putting changes
into Audacity's git, provided that they are actively on their way
upstream at the same time.
This is probably one area where "drive-by" contributions will be
particularly problematic. Whilst I used to encourage people to submit
upstream when I was actively working on the library stack, I don't
think more than about half ever did, the rest I ended up submitting to
several upstreams myself (with some success, generally). It isn't hard,
but often does mean subscribing to mailing lists etc.
Richard
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel