I like the mpf-<descriptive> pattern, but there are other "feature generators" we can have besides the ones from mystt; so, I might 'namespace' it like 'mpf-mystt-*' (mpf-mystt-feature-gen, etc)
Our most-flexible pattern is that the mpf-* package is the code needed to connect the analytic to MPF rather than having to be the underlying analytic code itself. (An example would be mpf-opencv; that package would depend on some opencv package, it wou'd statically bind in a copy of opencv. This has some nice license-management features, and helps to decouple the MPF code from GPL or proprietary code.) So I would expect to have mpf-mystt-feature-gen actually depend on some other package that isn't in MPF itself, and might not be Appscio-local.
Hence, once question here is where that code lives - is the MySTT group going to leave code on our servers, or are they hosting a repository we can pull from when they make changes?
(Some days I wish we had adopted git ...)
Sounds like you are suggesting:
mpf-mystt-feature-ge
mpf-mystt-spnsp
Those names sound good
Those names sound good (although I don't know what "gmm" stands for).
Would it be easiest for me to make the name changes and check it in so you can grab it from version control, or would it be easier for you to bring your code up-to-date with the new names and send me new tarballs?
Names and source control
We should start using source control. As I said in another post, we have a mild preference for using a standalone site (e.g. mystt.org), but we're happy to use whatever system you want. For now, why don't you create packages using the new names in your own system and I'll grab them (I assume I'll need a separate account).
Oh, and "gmm" stands for Gaussian Mixture Model, the machine learning method we're using in the speech/non-speech detector. There are more accurate methods, but the gmm approach is very fast and reasonably robust.
Adam
RE: Names and source control
Adam,
We talked over the options for hosting the MySTT components today, and the conclusion was that we think it would be better for you to host everything, since that's your preference anyway. The ideal for us would be that you check in the MySTT code to SVN on a standalone site (mystt.org or whatever) and also provide a tarball that we (and third parties) can pull to build and run the latest version of MySTT, including any updates to the Rasta libraries or other dependencies.
As an "extra credit" item, we (and most likely other users of MySTT) would find an RPM package for MySTT, hosted in a standalone MySTT RPM repository, very useful.
Does this sound reasonable to you ?
Thanks,
Gareth
RE: Names and source control
Sounds good. We'll likely grab mystt.org and mystt.icsi.berkeley.edu and host from a machine at ICSI.
Adam
Names and SourceControl
Hi,
I just asked our sysadmin to reserve openasr.org, openasr.com (which was just released), and mystt.org. (mystt.com is not free and probably won't be in the near future). We will host everything internally on mystt.icsi.berkeley.edu and let these domains forward.
Regarding the source code, I think I prefer going with Sourceforge rathern than hosting ourselves. The reason for this is that it would make it easier to add external committers.
Tar-ball is fine. The problem with RPMs is that nobody here has experience on how to build them. The same is true for autotools.
Gerald