ACLEW vs SRVK DiViMe repositories

[riebling]

I'm wondering what the policy is on making changes to these, and where people should assume the best-working version should come from. For example, I've fixed bugs, and those are in the SRVK version, which we've been treating as the 'Development' version. But people might clone the ACLEW version, thinking that it is the most stable, when in fact it is missing the latest bugfixes.

This also applies to documentation: the README has internal links that point to hard-coded URLs for the ACLEW/DiViMe repository. Should they stay that way, and we assume general users get their system from this location, and only developers use SRVK versions?

And lastly, a big difference: we were told we cannot distribute LDC tools, and so removed the SRVK repository's copy of the LDC tool, and removed mentions of it from the documentation README. This was a 'wait for formal permission' situation. If that hasn't changed, just wanting to note that ACLEW repository for DiViMe still mentions and contains LDC content.

[riebling]

More 'gotchas': the ACLEW DiViMe pulls several tools from my personal repositories, and shouldn't. The ACLEW Vagrantfile installs tools we don't use, and have removed (LIUM diarization, Festival/FestVOX)

[alecristia]

To add to that, it had been suggested to us that we should have a versioning system, explaining to users which are stable versions and their features. Versioning would also allow replication.

Re hardcoded urls, that is probably bad form.

LDC tools are still not available.

I don't think it's so bad to be pulling from your own repo, is it? Unless this obscures who is the author of the tool...

[riebling]

we have copies of the tools' repos under SRVK/DiViMe - would rather the URLs to clone them do not contain "riebling" in the Vagrant provisioning script. They were only meant to be temporary to get code out of folders and into repository form.

I think there's a way to fix the hard URLs in the README to refer to the README itself, rather than full HTTP URLs.

[fmetze]

I think it is most natural to have a “development” and “main” branch in the same repository. Then by default people would get the stable main branch, but they could also get the more experimental features.

I think it is fine to pull from “riebling” content, as long as it does not simply obfuscate who the original author is, but these repositories could also be in SRVK. The important point is that by using a repository, we can version them, and make sure that even if we make changes down the road, an earlier version can be installed and referenced. To this point, we should see if we can easily print versioning information for each included repository into a log file.

On Aug 15, 2018, at 12:09 PM, riebling notifications@github.com wrote:

we have copies of the tools' repos under SRVK/DiViMe - would rather the URLs to clone them do not contain "riebling" in the Vagrant provisioning script. They were only meant to be temporary to get code out of folders and into repository form.

I think there's a way to fix the hard URLs in the README to refer to the README itself, rather than full HTTP URLs.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/srvk/DiViMe/issues/18#issuecomment-413227854, or mute the thread https://github.com/notifications/unsubscribe-auth/AEnA8ShjhL8n3YowELmuY6xxGnN4EPUdks5uRDmQgaJpZM4V-NsZ.

[jukaradayi]

Hi,

Are there any updates on wether we should keep the aclew/DiViMe repository ? If we decide to keep it as stable (vs srvk/DiViMe = dev), I made a pull request on it to catch the latest bugfix and make it a "stable" version. Otherwise, we could indeed have a dev and main branch on srvk/DiViMe, but does that mean we should also do this for each of the tools ? Maybe make releases on github of "stable" version of the tools (yunitator, noiseme etc..) so that the stable version of the srvk/DiViMe can point directly to "frozen" version of the tools. If the latter solution is validated by everyone, we could already make a first release of each of the tools and of the DiViMe, do you agree ?

[alecristia]

I think by now we have gotten confused about the options and their pro/con list:

1) having a single repo where the main branch is what people pull and there are as many development branches as desired

pros:

• single link that is always valid,
• easy for us to push and pull;

cons:

• difficult to cite specific versions,
• difficult for users to realize there are different versions and how they differ,
• risk of pushing to main something that is not fully incorporated (eg contains a new tool that is being incorporated and has not been documented or tested)

2) having one repo being the public one and another the dev one (currently in place);

pros:

• single link that is always valid,
• even easier for us to push and pull (no need to remember to relevel)
• lower risk of pushing to public a half-baked version

cons:

• difficult to cite specific versions,
• difficult for users to realize there are different versions and how they differ,

3) actually using a release system

pros:

• single link that is always valid
• easier for users to understand there are versions and they differ
• lowest risk of pushing to public a half-baked version
• easier to cite

cons:

• we need to learn how to do this

In view of this, my preference would be option 3 > 2 > 1. Something not taken into account (because I don't know how it works) is the question of weight. I'm installing divime in a totally new machine and it took 3 minutes to clone divime. I'm surprised about this, since it's essentially a few text files. So I suspect there may already be some historical garbage (in a very short use history - it's been only 6 months, right?) that seeped in there.

[riebling]

there must be aftifacts left over from things that used to be in Git (maybe the ACLEW repository, maybe from even longer ago) that never get deleted (a problem with Git). We could get it to be smaller by starting fresh (git init) with just the few text files and couple test audios, though we'd be losing the history of the project and issues.

I tested, it looks like the size is currently 107M but if we delete all the Git overhead/history it shrinks down to 1.8M in size, as you noted, essentially a few text files.

[riebling]

I was thinking of the concept of "doing a release" - maybe we can think of it in terms of pulling a stable set of changes from the SRVK 'Dev' repository into the ACLEW 'Release' repository. So in fact we just 'did a release' with https://github.com/aclew/DiViMe/pull/8. Yay! (I'll have to look into the size history of ACLEW's repository now, maybe it's leaner and meaner :) )

[riebling]

Who knew it was as simple as clicking the Releases link? Not us, having never done so ;) :)

[alecristia]

Hmm I don't see the release: https://github.com/aclew/DiViMe/releases https://github.com/srvk/DiViMe/releases

Also, where did we land on aclew vs srvk? I'd vote for the public releases being linked to aclew since it's the grant that is currently active for this.

[riebling]

Correct, no release tags have been created yet. I'd have said something, and we'd probably have been notified. Want to just choose things as they stand right now, or is there a more meaningful milestone? I suppose timing with Interspeech is memorable enough!

[alecristia]

@riebling Can you please make two releases: 1.0 return to Interspeech submission date (circa March) and release 1.1 fast forward to today; the new things in 1.1 are: 2 more SAD/VAD tools, several bug fixes

[riebling]

Turns out 'doing a release' may be more complicated than just tagging a single repository. The Vagrantfile pulls in code from several repositories. We might need to also:

• Add version/release Tags to each repository brought in by the VM provisioning process
• Edit Vagrantfile in some way that it can be back-dated, such that each repository it pulls from, it gets a specified version

[fmetze]

yes, that is not a bad idea, simply to make sure every sub-module has a defined state as well. probably a few extra keystrokes, but not a showstopper?

[riebling]

During testing I realized that if a person clones the SRVK/DiViMe repository, they get the head branch of the Vagrantfile which provisions all v1.0 tagged tools. As a result, the tools are not up-to-date with respect to the Vagrantfile, which is ahead of v1.0.

I think for the SRVK/DiViMe repo to truly be the Dev repository, it's Vagrantfile should pull from the head (Dev) branch for all included tools.

Maybe it should work like this: for a person to get a stable Release v1.0 version of DiViMe they should either:

• Explicitly clone that version from SRVK repo with git clone http://github.com/srvk/DiViMe --branch v1.0
• Make the ACLEW repo be the same as v1.0, have users clone from ACLEW and get the "stable v1.0 release"

[riebling]

(and if we implement either of those 2 strategies, then remove the --branch v1.0 from the head version of Vagrantfile in SRVK/DiViMe so that it gets all the head versions of tools)

[fmetze]

I think the most intuitive way is to tell people to clone a "stable release version" of a repository, rather than point to two different repositories. in this way, we can even support multiple stable releases in a single repository.