Comment 1 by jteh on 2012-11-22 06:35
I was just thinking about this and realised there's a problem I didn't consider before.

What if the mainUnstableDeps branch doesn't change but the dependencies (espeak or liblouis) get updated? We base our version numbers on the branch revno, so the script will assume it has nothing to do. Even if I tweak it to detect that liblouis and espeak were updated, users still won't know about the new update because it'll have the same version number, also causing confusion. I guess the only solution is to include the espeak and liblouis revno in the version (e.g. mainUnstableDeps-5614+espeak294+liblouis836), but that is really hard to integrate into nvda_autobuild. Ug.

Comment 2 by leonarddr on 2013-09-17 11:59
You might want to reconsider this, now the source control system has been changed to GIT. You could, for example, create git submodules which are clones of the corresponding svn repositories. For example this article gives info on how to accomplish such things.

Comment 3 by jteh on 2013-09-17 12:55
liblouis is already a Git submodule. With submodules, you still have to update the main repository each time you want to update the submodule to a new commit. So, having an automatically updating unstable deps branch is still pretty ugly.

We haven't moved to a submodule for eSpeak yet because eSpeak svn has often been out of sync with the actual source code released and it doesn't include any tags. Also, svn doesn't include the compiled phoneme data. Compiling it requires us to build espeakedit, which in turn would make us depend on the C++ wxWidgets. That's not a dependency I'm willing to introduce just for this.

CC @feerrenrut @jcsteh:

It seems that it is the plan to move next to Espeak-NG master on a regular basis. Should we still consider this additional snapshots? Would people ever use them?

In light of #6733 I would say that yes, people would use this. However, table changes in liblouis require some manual work. So I'm not sure about the maintenance burden.

I forgot about this issue. :) We decided to have NVDA next update to eSpeak master on a semi-regular (but not automated) basis. We could probably do the same for liblouis. People who wanted to test specific tables in liblouis master would need to file an issue to do this, but we'd only consider this if there were a commitment to test the table and fix any problems.

Is this issue then resolved and ready to close, or do you first want to document the procedure to request a snapshot (AKA next)?

@LeonarddeR @jcsteh @dkager I do not believe a resolution was made for this issue from #2696 (comment)

With liblouis we have to watch out for API changes that happen on master. While it is usually just opcode changes, e.g. when the big UEB update was going on, it could also be that the Python wrapper changes and breaks the snapshot builds.

So if the process remains manual then who does it and when?

Is this actually not working when pushing try builds? Actually the try builds could fetch unstable branches of eSpeak and Liblouis. Or am I wrong?

I think we can close this issue. There aren't any current plans to create automatic builds with the HEAD of espeak or liblouis repositories.