Discussion:
Procedures for updating lib-src; Henric Jungheim's work
(too old to reply)
Paul Licameli
2017-06-29 15:55:15 UTC
Permalink
What, if anything, is the discipline we should observe in updating lib-src
directories, if we don't use git submodules? This is pertinent to Henric's
proposals, which touch lib-src, and also the upgrade of expat, which I
still mean to do, but lately reverted because I thought I had been hasty
and did not follow good procedure.

For instance, in the case of expat, I see in git history that other things
were done to our copy of it, since last update. But I overwrote all
without considering whether I was supposed to replicate the changes that
were applied.

Should there be a procedure (as there is, for customized wxWidgets builds,
of putting .patch files into our git repository) for re-applying certain
patches to copied lib-src source trees? (And should we request such from
Henric?) Or simply a convention of putting a text file somewhere
describing the procedure for reapplying changes, if that is simple?

Was this procecure defined in writing already somewhere and am I just
inexcusably ignorant of it?

PRL
James Crook
2017-06-29 16:27:32 UTC
Permalink
Post by Paul Licameli
What, if anything, is the discipline we should observe in updating lib-src
directories, if we don't use git submodules? This is pertinent to Henric's
proposals, which touch lib-src, and also the upgrade of expat, which I
still mean to do, but lately reverted because I thought I had been hasty
and did not follow good procedure.
For instance, in the case of expat, I see in git history that other things
were done to our copy of it, since last update. But I overwrote all
without considering whether I was supposed to replicate the changes that
were applied.
Should there be a procedure (as there is, for customized wxWidgets builds,
of putting .patch files into our git repository) for re-applying certain
patches to copied lib-src source trees? (And should we request such from
Henric?) Or simply a convention of putting a text file somewhere
describing the procedure for reapplying changes, if that is simple?
Was this procecure defined in writing already somewhere and am I just
inexcusably ignorant of it?
Nope, I don't think so. We are simply gradually getting better (=more
systematic) at tracking our own changes.

https://github.com/audacity/audacity/blob/master/lib-src/audacity-patches.txt

says there were no patches to expat. What changes did you find/spot?
Post by Paul Licameli
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Cliff Scott
2017-06-29 16:36:46 UTC
Permalink
Just wondering if I missed the email or if it is a secret as to what the release plan is for 2.2.0. I know a while back Paul said he would have a plan in 24 hours, but I never saw what the plan was so maybe it is available only for certain people. If so that's ok, but it would be nice to know.

Cliff
Peter Sampson
2017-06-29 16:49:30 UTC
Permalink
See this page in the Wiki:
http://wiki.audacityteam.org/wiki/Next_Release#Timeline

Peter
Post by Cliff Scott
Just wondering if I missed the email or if it is a secret as to what the
release plan is for 2.2.0. I know a while back Paul said he would have a
plan in 24 hours, but I never saw what the plan was so maybe it is
available only for certain people. If so that's ok, but it would be nice to
know.
Cliff
------------------------------------------------------------
------------------
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
Cliff Scott
2017-06-29 18:04:12 UTC
Permalink
Thanks Peter.

Cliff
http://wiki.audacityteam.org/wiki/Next_Release#Timeline <http://wiki.audacityteam.org/wiki/Next_Release#Timeline>
Peter
Just wondering if I missed the email or if it is a secret as to what the release plan is for 2.2.0. I know a while back Paul said he would have a plan in 24 hours, but I never saw what the plan was so maybe it is available only for certain people. If so that's ok, but it would be nice to know.
Cliff
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel <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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Paul Licameli
2017-07-06 02:31:12 UTC
Permalink
Yes, about those dates.

With some regret, your humble release manager for this release is calling
for ten days' delay of the feature freeze.

The page has been updated.

PRL
Post by Cliff Scott
Thanks Peter.
Cliff
http://wiki.audacityteam.org/wiki/Next_Release#Timeline
Peter
Post by Cliff Scott
Just wondering if I missed the email or if it is a secret as to what the
release plan is for 2.2.0. I know a while back Paul said he would have a
plan in 24 hours, but I never saw what the plan was so maybe it is
available only for certain people. If so that's ok, but it would be nice to
know.
Cliff
------------------------------------------------------------
------------------
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
------------------------------------------------------------
------------------
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
------------------------------------------------------------
------------------
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
David Bailes
2017-07-10 07:45:24 UTC
Permalink
Post by Paul Licameli
Yes, about those dates.
With some regret, your humble release manager for this release is calling
for ten days' delay of the feature freeze.
Given that we are close to a new release, I could understand a delay to
allow for more bug fixing, but it appears that the delay is so that you can
add more features, which of course may include more bugs.

David.
Post by Paul Licameli
The page has been updated.
PRL
Post by Cliff Scott
Thanks Peter.
Cliff
On Jun 29, 2017, at 11:49 AM, Peter Sampson <
http://wiki.audacityteam.org/wiki/Next_Release#Timeline
Peter
Post by Cliff Scott
Just wondering if I missed the email or if it is a secret as to what the
release plan is for 2.2.0. I know a while back Paul said he would have a
plan in 24 hours, but I never saw what the plan was so maybe it is
available only for certain people. If so that's ok, but it would be nice to
know.
Cliff
------------------------------------------------------------
------------------
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
------------------------------------------------------------
------------------
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
------------------------------------------------------------
------------------
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
------------------------------------------------------------
------------------
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
Paul Licameli
2017-06-29 16:40:10 UTC
Permalink
Post by Paul Licameli
What, if anything, is the discipline we should observe in updating lib-src
directories, if we don't use git submodules? This is pertinent to Henric's
proposals, which touch lib-src, and also the upgrade of expat, which I
still mean to do, but lately reverted because I thought I had been hasty
and did not follow good procedure.
For instance, in the case of expat, I see in git history that other things
were done to our copy of it, since last update. But I overwrote all
without considering whether I was supposed to replicate the changes that
were applied.
Should there be a procedure (as there is, for customized wxWidgets builds,
of putting .patch files into our git repository) for re-applying certain
patches to copied lib-src source trees? (And should we request such from
Henric?) Or simply a convention of putting a text file somewhere
describing the procedure for reapplying changes, if that is simple?
Was this procecure defined in writing already somewhere and am I just
inexcusably ignorant of it?
Nope, I don't think so. We are simply gradually getting better (=more
systematic) at tracking our own changes.
https://github.com/audacity/audacity/blob/master/lib-src/
audacity-patches.txt
says there were no patches to expat. What changes did you find/spot?
If I do
gitk lib-src/expat

I see changes, not in source code, but chanign configurations, and I don't
understand them or know whether they are important to replicate.

There is also normalization of line endings by Benjamin, apparently part of
a big sweep, and probably unimportant.

If I do
gik lib-src

I see many, many things, and perhaps there are cautions we should observe
but did not.

But some lib-src directories are really totally ours, like mod*, and some,
like nyquist and perhaps portaudio, we have more influence on upstream.

PRL
Post by Paul Licameli
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
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
Henric Jungheim
2017-06-29 19:22:18 UTC
Permalink
I apologise for repeating myself, but if one has local
changes, then one has a fork. What tools that are being
uesd to help track such changes is a separate question.
Given how loaded such discussions can easily become, I'll
point out that "git" provides a tool that helps manage such
things.

For building wxWidgets for use with my x64 fork, I started
by modifying the files in win/wxWidgets_additions/,
unzipping the relevant wxWidgets src files, and copying the
files over. One could then do a diff between these files
and 3.0.2 and compare that by hand to the diffs between
those files and 3.1 (the first release that supported
VS2015). It works. It is painful, but it works.
Eventually, I gave up and started working on a clone of the
official wxWidgets repo, keeping my changes first in a
stash, then I found that I could just keep my changes as an
"add"ed set of changes (without doing a commit). This got
more complicated when I tried switching to wxWidgets 3.0.3.
Finally, I gave up and just forked wxWidgets, checked in the
changes, and let to tools do their job. Much, MUCH easier.
Since the x64 fork links to the static, LTCG wxWidgets
libraries, they really should be built together. It seemed
reasonable to record the exact version of the wxWidgets
source (including local changes) used for the Audacity build
in the Audacity repo and so the x64 fork got a wxWidgets
submodule.

I'm not saying that any of the Audacity lib-src stuff should
be converted to submodules (or to use subtree or subrepo or
what-not), but I would say that if there are any local
changes at all, one should seriously consider having them
live in an SCM repo somwhere--even if that means every once
in a while copying the files that fork over the files in the
Audacity repo (i.e., hand merging). Rebasing local changes
on top of an external repo's changes is much easier and
error prone with "git rebase" than by typing "diff", making
changes in vi, and running "diff" again. Creating a pull
request from a fork to feed the changes upstream is a lot
easier when one has such a thing.

I suppose one could write a tool to automatically generate
the wxWidgets_additions folder from two branches... Given
how git is, well "git", I wouldn't be surprised if there is
already something like a "git make-cp-fork -o <output dir>
<from branch> <to branch>" tool.
Post by Paul Licameli
What, if anything, is the discipline we should observe in updating lib-src
directories, if we don't use git submodules? This is pertinent to Henric's
proposals, which touch lib-src, and also the upgrade of expat, which I
still mean to do, but lately reverted because I thought I had been hasty
and did not follow good procedure.
For instance, in the case of expat, I see in git history that other things
were done to our copy of it, since last update. But I overwrote all
without considering whether I was supposed to replicate the changes that
were applied.
Should there be a procedure (as there is, for customized wxWidgets builds,
of putting .patch files into our git repository) for re-applying certain
patches to copied lib-src source trees? (And should we request such from
Henric?) Or simply a convention of putting a text file somewhere
describing the procedure for reapplying changes, if that is simple?
Was this procecure defined in writing already somewhere and am I just
inexcusably ignorant of it?
Nope, I don't think so. We are simply gradually getting better (=more
systematic) at tracking our own changes.
[2]https://github.com/audacity/audacity/blob/master/lib-src/
audacity-patches.txt
says there were no patches to expat. What changes did you find/spot?
If I do
gitk lib-src/expat
I see changes, not in source code, but chanign configurations, and I
don't understand them or know whether they are important to replicate.
There is also normalization of line endings by Benjamin, apparently
part of a big sweep, and probably unimportant.
If I do
gik lib-src
I see many, many things, and perhaps there are cautions we should
observe but did not.
But some lib-src directories are really totally ours, like mod*, and
some, like nyquist and perhaps portaudio, we have more influence on
upstream.
PRL
Â
PRL
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! [3]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[5]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! [6]http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
2. https://github.com/audacity/audacity/blob/master/lib-src/audacity-patches.txt
3. http://sdm.link/slashdot
5. https://lists.sourceforge.net/lists/listinfo/audacity-devel
6. http://sdm.link/slashdot
8. 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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...