UI code repo

[kdm9]

This repo is a software library, i'd like to keep all user-facing code in a separate repo. As the only user interface code i've written is CLI-based, we've used timestreamCLI until now. However, we're now getting GUI code. I'd ideally like to have these in the same place.

Given most of the timestreamCLI code is super-hacky and largely out of date, I propose we start a new repo to contain all user-facing code. timestream-ui is the web ui Gareth's writing, and I think we should keep this separate. What about traitcapture-interfaces? The, the re-writes of the CLI code, pipeline_demo, and any GUI code, can live there, independent of any library hackery.

Open to suggestions on naming, but I strongly suggest we keep all UI code and the library in separate repos.

[kdm9]

we can cover this in the code review if you want

[Joelgranados]

I'll have a rant post and then I'll do a compromise post. Here goes the rant part: I disagree with separating the project into different repositories. If it were up to me, we would have everything under the same roof (library, ui and tests). Here are my arguments:

1) By separating we are loosing relations between components. Look at the history of pipeline_deom.py (UI component); click on some of the commits at https://github.com/borevitzlab/timestreamlib/commits/traitcapture_v0/util/pipeline_demo.py. Notice that every time that we changed something in the library that had to do with the UI, we made the respective change in pipeline_demo.py. This wont happen if we have different repos. With different repos we do a change in timestreamlib, then we do a change in timestreamui, then we commit them both separately and we wont be able to track the interelationship between them.

2) Makes finding bugs that much harder. You now have to consider 3 or 4 repositories with different history to see what is happening. What if the bug is a relation between the UI and the lib? where do you put the bug? on both the repositories bug systems? The relationship between repositories is going to end up being in the commit messages which will get very confusing when hunting bugs. On the other hand, if they were in the same repo, you would immediately see the relation between the lib and the ui because the changes are on the same commit; like in https://github.com/borevitzlab/timestreamlib/commits/traitcapture_v0/util/pipeline_demo.py

3) What is the reasoning behind it? I know that they are different components, but with that reasoning we should separate the image processing stuff from the timestream stuff. Or we should separate parse stuff from the timestream: they are all "separate" components.

4) Whatever you want to do with separate repos, you can do with directroy structure: For interface, since we are going to have different languages we can have language specific directories like so many projects out there such as opencv (https://github.com/Itseez/opencv) that has C, C++, java, python in the same repository or the redhat installer (https://git.fedorahosted.org/cgit/anaconda.git/tree/) that has python, bash script, C in the same repo, Network Manager (http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/clients) that actually has a UI specific directory.

5) other discussions: Here are some other link that can give perspective to our dicussion. http://programmers.stackexchange.com/questions/194822/when-to-separate-a-project-in-multiple-subprojects, http://programmers.stackexchange.com/questions/206668/using-multiple-git-repositories-instead-of-a-single-one-containing-many-apps-fro?rq=1, http://programmers.stackexchange.com/questions/206668/using-multiple-git-repositories-instead-of-a-single-one-containing-many-apps-fro?rq=1

Comments are greatly appreciated.

[Joelgranados]

Now my compromise post: If there is no convincing you out of fragmentation, I vote to keep it to a minimum. This project is not that big that we need 4 different repositories (tests, timestreamlib, timestreamCLI, timestreamui). Why don't we keep 3 repositories: tests, library and the user interface? We can use the timestreamui as our User interface repository and put the CLI, GUI and PHP stuff there.

What do you think?

[kdm9]

Joel,

Great points thanks! A brief response, will comment further later:

• I haven't made my mind up that exactly what I proposed is a good idea, but I think some reorganisation is necessary. The project should be either one repo (so we merge the whole lot, including tests, into timestreamlib, or even a new repo called traitcapture), or 3 (library, UI, testdata).
• Most of your concerns can be addressed with judicious use of git submodules (particularly 1 & 2). This keeps the ease of bisection etc, and ties a version of the UI to a version of the library & test data, but keeps the git logs separated, and development of the internals of each component is separated. Only changes to the way the two interact need be tracked.

Let me think about it, we'll discuss in next week's group meeting (we'll hold it on Wednesday, so I'm back). At the earliest, this would happen during the code review, so let's not sweat it.

K

[Joelgranados]

Let me insist.

There would be too much overhead to do 1&2 with submodules. 1) Maintaining the relations would bring too much overhead: Lets assume that we are "judicious" about submodule use. To maintain the relation between repositories we would be adding unnecessary overhead. It would go something like this: I would commit to GUI, then I would update submodule GUI in timestreamlib and commit to timestreamlib and finally I would need to update the timestreamlib submodule in GUI. Isn't tihs too much work? Wouldn't it be easier to just do one commit?

2)The relations are not direct: Lets say you are looking at the history of timestreamlib and you find that the commit has and update to the GUI. To actually see the relation, you would have to have the timestreamlib and GUI repositories in different places pointing to the relevant commits. Isn't it just easier to look at one commit?

3) Assuming that developers will follow is too optimistic: If it already happens when we just have one repository (I changed stuff and did not change the tests, or I change stuff in the config file and failed to update chuongs GUI), what do you think will happen when you add more overhead to the process? KISS it, I insist!

If what is putting you off is the prospect of putting these projects together, I volunteer to make that happen.

[kdm9]

I'm going to close this, now #126 has been merged.