Usable-milestone

[quarnster]

What is missing for getting Lime into a state where we can start coding Lime using Lime? Let's define a milestone for this and open up issue numbers for every issue we see as remaining. Issue suggestions are welcome

[FichteFoll]

You should assign issues to a milestone that you created here. Not sure if you knew. (example1, example2, example3)

[quarnster]

Ok, I've added a few issues to the v0.1 milestone. Let's keep adding to it and filing new issues for everything missing

[zoli]

Is this usable state for qml frontend? IIRC as we discussed earlier(in one of issues) I think we should start separating frontends repo from the backend repo.

[erbridge]

As long as we can get travis to fail the backend if the frontends fail after a change to the backend, I agree with splitting them out.

[quarnster]

If the frontend fails but the backend didn't on a backend-change IMO that's indication of needing a better test in the backend to capture that failure.

This might indeed be a good time to split them out as v0.1 of the QML frontend isn't v0.1 of the termbox frontend.

[quarnster]

As long as we can get travis to fail the backend if the frontends fail after a change to the backend, I agree with splitting them out.

Or did you mean something like renaming a function in the backend? Obviously that would still have the backend pass but would definitely break the frontends. Perhaps we instead keep the backend master-branch as the stable "release" branch and do further development in a separate branch? That would avoid breaking frontends and having to maintain all frontends by a single person doing a single change in the backend. Or is there a better way of doing this?

[zoli]

There are some tools for dependency management like godep, gopkg.in also we can create a vendor directory in frontend repos sth like docker does here.

[erbridge]

I'm also worried about the frontends relying on partial functionality or bugs in the backend and us not noticing when the backend is changed, and having to work out why the frontend fails at some later date. Fixing the dependencies might be a good answer, since at least upgrading would be something triggered by a developer.

[quarnster]

I kind of hate all the solutions suggested, as it all just seems like a lot of work for something that might just not even be that a big of a deal :)

Maybe we just trigger travis to rebuild all frontends on backend commits so that we're made conscious of any side effects this can have? Is it possible to trigger a project to rebuild from another project?

[quarnster]

Is it possible to trigger a project to rebuild from another project?

It's possible via the "travis" command-line tool, but it doesn't seem to be installed by default in the travis ci environment. travis restart -r limetext/lime, might have to travis login -t <travis token> --github-token <github token> before also. IIRC there's some way to configure tokens and other sensitive information so that they are not shown in clear text in the travis logs, but I don't have time to research this right now.

[erbridge]

Yup, it is possible: http://docs.travis-ci.com/user/environment-variables/#Secure-Variables

[quarnster]

Oh, there's also https://github.com/pote/gpm and https://github.com/pote/gvp

[erbridge]

We'll also need to come up with some way of dealing with the packages folder being outside of the repo (or in a different place).

[erbridge]

I've suggested a structure for splitting the project out into in #546.

[quarnster]

Go 1.5 adds support for experimental vendoring, so we can "freeze" libs of other repositories using git submodules ("go get" will indeed checkout submodules when vendoring is enabled).