openTx is moving to github!

[Kilrah]

A little announcement to point that openTx and companion9x have changed home and will now reside on github at the following address:

https://github.com/opentx/opentx

There will be little change for the user, but will make it easier on the backend for the developers. Everything will also be united at the same place now.

Code has already been transferred, issues are being copied over now (so if you have opened issues please post further updates on github!), downloads and documentation should follow suit soon enough

[MikeB]

Is there a specific reason for the move?

Mike.

[Kilrah]

Git makes it easier to work on things in parallel with much more efficient branching/merging than svn. It also allows for offline commits which will be much more convenient for Bertrand who can't access the network during the day, and currently has to commit things that aren't always related together in the evening.

Also, we think keeping the firmware and "openTx companion" will make it clearer and more maintainable.

If you work alone and only commit releases like you do now there probably wouldn't be much point.

[Spoogy]

So what does this mean for "normal" user?

OpenTX homepage is remained in Google and sources are in Github and not updated to Google anymore or what?

(I think I need to learn how to compile those sources).

[tilmanb]

Thanks I love you guys for that.
Svn made me want to poke a fork in my eyes sometimes.

[Rob Thomson]

So what does this mean for "normal" user?

OpenTX homepage is remained in Google and sources are in Github and not updated to Google anymore or what?

(I think I need to learn how to compile those sources).

Nothing. It will make no difference to anyone who uses companion. (A normal user)

Only of relevance if you compile your own firmware.

Sent from my GT-I9300 using Tapatalk

[ReSt]

In the past, I learned to use and navigate in the open... code repositories on google but I have problems to do so on github.
Hopefully I will find my way as time goes by. And maybe, at some time, I will install a newer version of my browser, as github requests me to do

Positiv is, that svn checkout still works, using address https://github.com/opentx/opentx/trunk

Reinhard

[rdeanchurch]

Did the Issues page get moved or dropped?
Where is it, I can't find it now.

[bertrand35]

Here:
https://github.com/opentx/opentx/issues ... state=open

[rdeanchurch]

Interesting, this thread doesn't have a thank you...thumbs up.

So thank you, Bertrand!

[huginen]

hmmm, do you use github or Google?
the source @ Google was updated 11 hours ago and on github a month ago, and companion9x can´t be found @ github

[Kilrah]

It's actually a bit of a mess right now - need to consolidate things as we've been running both in parallel to see the benefits of each but they're not really in sync either.
Github shows the "master" branch by default, which corresponds to the current release version. You need to browse the branches to find the new stuff.

[dvogonen]

As far as I can understand there is no defined workflow at the moment. Git is more flexible than subversion. While this is a good thing it also maks a predefined workflow essential. Without one there is a clear risk for confusion with branches all over the place with more or less finished work.

I only seldom contributed code changes, but try to maintain the quality of the Swedish translations of openTX and companion at the same level as the English original. Since development now can take place in several branches at the same time which may be in conflict with each other, it will be difficult to find what needs to be translated and make the translations in a timely manner.

I had a short conversation with Bertrand about the issue and it ended with him saying that he needed to think things through.

[tilmanb]

Github workflow is pretty clear. Clone and fork, make your changes and create pull request when you think they should be folded back into mainline. Of course do that in a branch if you have more than one commit to do.
You can work differently but this is what github kind of sets you up with.

[Kilrah]

Master = releases.
We've set up a branch called next onto which all newly implemented and finished features get merged.
When you want to implement a new feature you create a branch for it (from next in most cases), and do your work in it. When it's done it gets merged back into next.
I'd imagine the translations to be done directly in next after features get merged, then next gets merged into master for a release.

Being a project member and doing the work in the project's branches makes more sense than the fork/pull request process. The goal is to have an overview, which isn't the case if done in a fork.

[dvogonen]

As always the devil is in the details. Should changes be directly pushed into next by their originators or pulled in by repository maintainers after pull requests?
How do the translation maintainers know when the next branch needs to be translated as a release is impending?
What happens if a translation does not get done in time for a release?

[bertrand35]

Right, git is really powerful, but also we all feel lost at the beginning!

Normally, the changes should be pulled to 'next' by one of the admins once the feature is approved and tested. Then 'next' becomes 'master' once ready to be released.

About the translations, either the translations are done in the feature branch, or in a child of this branch. For example let's say I add a feature in my branch: bsongis/the_super_feature, you would create this branch: dvogonen/the_super_feature_swedish_translation and do the translations there.

[dvogonen]

The only way for me to know that you have changed something in bsongis/the_super_feature branch that affects the GUI is to continuously scan that branch for changes. The same goes for all other branches. There are already 11 branches in the repository. There will be a lot more as times go by. I have no idea which of these will be used in the next release, when they are finished so they can be translated and most importantly; when the translations have to be finished to make it into the release. The combination of these factors will make it impossible to maintain the quality of the translations.

The subversion model have not worked all that well either, since there was no way of knowing when a translation had to be finished to make it into the next release. But in subversion I only had to monitor one repository branch and keep that one up to date. The simplicity disguised the fact that the release process was broken as to the translation part. In the new model I would have to scan an unknown number of unknown repositories just to discover which need translation. This is hardly going to happen.

I think it makes much more sense to treat the translation as part of the release procedure. Translate all changes for each release in one go for each language.

When the features for a release have been finalized and merged to the next branch you could post an email instructing all comitters to post translations to the next branch (or to separate child branches of next if you prefer to merge them yourself). This will save a lot of time and effort for everyone involved, not least yourself who will not have to deal with dozens of more or less complete translation branches.

Your proposed workflow would work even less well for the translation of companion, which now is part of the same repository.The QT translation tool makes numerous automatic changes to the translation (.ts) files. These changes are references to the location of strings in the code. If you try to merge .ts files from parallel code branches you will have to deal with a lot of merge conflicts since the reference locations are different. And even after solving these the references in the resulting .ts file would be corrupt. This is easy enough to fix by re-indexing the files, but why bother merging and re-indexing when you could just as well make the translation once and be done with it?

[Kilrah]

I think it makes much more sense to treat the translation as part of the release procedure. Translate all changes for each release in one go for each language.

When the features for a release have been finalized and merged to the next branch you could post an email instructing all comitters to post translations to the next branch

Agree 100%.

[tilmanb]

I'm actually used to a process where master is the dirty bleeding edge and releases get branched off.
But it's just names so what's the matter. Makes no difference.
As for forking. That's not required for the core team members who have access to the main repository. But the barrier of entry for 3rd party contributions is zero that's why I'm so glad that we got rid of svn.

[Romolo]

I'm not happy at all we got rid of SVN especially for companion9x, also for the merging in the same repository...
What to say.... ah yes....
So long, and thanks for all the fish.

[Romolo]

The more I look to github the more I find it confusing, including email notifications not specifying what was modified if companion or opentx
I really don't like it at all.

[Geoffs]

I'm actually used to a process where master is the dirty bleeding edge and releases get branched off.

This is probably a more common approach to using Git (and how most projects do it on github in my experience).

New features are developed and tested in branches, and as the new feature is stable, you merge it in to master, then delete the feature branch.

Then, when the new features in master reach a point where they are stable, you tag the release, and keep going. Then you create your release based on the tag (which is basically just a branch).

This allows you to do updates easily to previous releases:
check out the tag of the release you want, cherrypick the commits from master, then create a new tag. For example, say you create a tag for v1.0.0, then you find a bug a month later after you have been working on new features for v1.1.0. So you fix the bug in master, then check out the previous tagged release, cherrypick the bug fix(es) you want from master, then create a new tag - so you end up with v1.0.1, which is just v1.0.0 + the only the bugfix commits from master. Then you go back to working on master, and when it's testing and "done" you tag it as your new version and the cycle repeats.

I'd recommend using this approach to make it easier for new developers to come on board and help out.

[rcsoar]

Google Code is still open for business which is a little confusing- I submitted an issue (re diff) to GC a few days ago and it was not carried over into Github, so have cross posted.

BTW as an occasional 'issue raiser' I find the Google Code interface more understated and pleasing. Having some default text in the issue submission form (for board, firmware etc.) was useful, presumably for the devs too. Any plans to replicate this in Github?

Mike

[dvogonen]

There are pros and cons with both Github and Google code. The Google code web interface is easier to get an overview of, while GitHub offers much better collaboration support for developers. The latter is the reason for the move.

As far as I understand, the next release will be made from Google code. From that point onwards they will be done from Github. So at the moment both repositories are active with manual synchronization between them.

It is probably smartest to report bugs to Github. That way they do not risk getting lost in the transition.

[Kilrah]

When the googlecode issue list is closed we will run the synchronisation script again, so any changes will be carried over.
Still best to use github already.

[ReSt]

Question from a "normal" user of the repository ( Using SVN checkout to download the source code; applying private modifications and compiling the code):

In the moment, I'm not able to find anything known like a version number that I can enter in SVN for the download.

I'm really lost, navigating on Github

How do I get the most actual version ?
How do I select an earlier version ?
How do I see what versions are selectable at all ?
How can I decide which selections should work and what is 'under construction' ?

My only option seems to be to select the Head revision.

Does that mean, that on Github, I will only be able to download the latest, officially pulled/distributed version ?

In the moment, this gives me (according to the svn information at the end of the download), a downloaded version of 2798 (pretty old one) but the latest information in the release notes of the download say rev 2834 ?

Reinhard

[Kilrah]

Ideally you should be using a GUI - the best for Windows and Mac is SourceTree.
This will allow you to see history and what happens much more clearly than with the command line.

The conventions we're using is that:

• The "master" branch you see by default is the latest release
• The "next" branch is a cleaner equivalent of what we had on svn, i.e. things that are finished and need testing for next release
• Work in progress is done in other branches.

So when we want to do something new we create a branch off next and do the work in there, potentially over several days, with more than one person working on it, and maybe doing work in other branches meanwhile too. When one branch is done with (changes regarding both firmware and companion), it is merged to next and available for testing. A release would mean merging next onto master and creating a tag.

If you want to get the latest, checkout the "next" branch. It's supposed to be good unless a bug has slipped through, there won't be any known-not-working in-progress things like we had on svn as that's done in separate branches.
We have tagged a few last releases, so if you wanted to retrieve it you'd checkout that tag, then create a local branch for it.
Same for any particular commit, checkout and create a local branch.

[ReSt]

Thanks for this information.
So I will have to get and install Source Tree and have a look at it.

Reinhard

[dvogonen]

I have always used Tortoise for subversion on Windows. So now I use Tortoise-Git on Windows. It works exactly the same, but has all the git stuff added. Pretty good and very familiar.