openTx is moving to github!
openTx is moving to github!
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
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
- 9x Developer
- Posts: 17993
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: openTx is moving to github!
Is there a specific reason for the move?
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: openTx is moving to github!
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.
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.
Re: openTx is moving to github!
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).
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).
What goes up, must come down. -Isaac Newton
OpenTX - expanding possibilities
OpenTX - expanding possibilities
Re: openTx is moving to github!
Thanks I love you guys for that.
Svn made me want to poke a fork in my eyes sometimes.
Svn made me want to poke a fork in my eyes sometimes.
- Rob Thomson
- Site Admin
- Posts: 4543
- Joined: Tue Dec 27, 2011 11:34 am
- Country: United Kingdom
- Location: Albury, Guildford
- Contact:
Re: openTx is moving to github!
Nothing. It will make no difference to anyone who uses companion. (A normal user)Spoogy wrote: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).
Only of relevance if you compile your own firmware.
Sent from my GT-I9300 using Tapatalk
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
Re: openTx is moving to github!
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
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
-
- Posts: 750
- Joined: Tue Dec 27, 2011 11:22 pm
- Country: United States
- Location: Carson City, Nv
Re: openTx is moving to github!
Did the Issues page get moved or dropped?
Where is it, I can't find it now.
Where is it, I can't find it now.
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
-
- 9x Developer
- Posts: 2764
- Joined: Fri Dec 30, 2011 11:11 pm
- Country: -
-
- Posts: 750
- Joined: Tue Dec 27, 2011 11:22 pm
- Country: United States
- Location: Carson City, Nv
Re: openTx is moving to github!
Interesting, this thread doesn't have a thank you...thumbs up.
So thank you, Bertrand!
So thank you, Bertrand!
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
Re: openTx is moving to github!
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
the source @ Google was updated 11 hours ago and on github a month ago, and companion9x can´t be found @ github
Re: openTx is moving to github!
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.
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.
Re: Sv: openTx is moving to github!
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.
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.
Re: openTx is moving to github!
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.
You can work differently but this is what github kind of sets you up with.
Re: openTx is moving to github!
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.
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.
Re: Sv: openTx is moving to github!
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?
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?
-
- 9x Developer
- Posts: 2764
- Joined: Fri Dec 30, 2011 11:11 pm
- Country: -
Re: openTx is moving to github!
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.
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.
Re: openTx is moving to github!
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?
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?
Re: openTx is moving to github!
Agree 100%.dvogonen wrote: 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
Re: openTx is moving to github!
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.
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.
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: openTx is moving to github!
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.
What to say.... ah yes....
So long, and thanks for all the fish.
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: openTx is moving to github!
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.
I really don't like it at all.
Re: openTx is moving to github!
This is probably a more common approach to using Git (and how most projects do it on github in my experience).I'm actually used to a process where master is the dirty bleeding edge and releases get branched off.
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.
Re: openTx is moving to github!
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
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
Re: Sv: openTx is moving to github!
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.
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.
Re: openTx is moving to github!
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.
Still best to use github already.
Re: openTx is moving to github!
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
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
Re: openTx is moving to github!
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:
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.
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.
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.
Re: openTx is moving to github!
Thanks for this information.
So I will have to get and install Source Tree and have a look at it.
Reinhard
So I will have to get and install Source Tree and have a look at it.
Reinhard
Re: Sv: openTx is moving to github!
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.