Switch code repo to github and start using pull request workflow

[GoogleCodeExporter]

Git and pull request workflow make it much easier for third
party developers to submit complex patches that involve multiple
commits. And it is easy to make comments on the code and request
changes.

Don't be on the wrong side of history :)

Original issue reported on code.google.com by boxe...@gmail.com on 6 Jul 2014 at 1:18

[GoogleCodeExporter]

Ok migration to another repo takes time and effort and might confuse people 
having the repo URL in some config file. So I don't want to dive into this 
without being sure it can improve the project significantly.

So I need some more information / advices on this. 

Some inputs : 
* Googlecode allow switching to git repo if needed
* git-svn works fine locally to interact with a svn repo
* downloads are already hosted at sourceforge ... Is a complete switch to 
Sourceforge also an option ?
* what about migration tools ? We would need to migrate all repo history of 
course, but also issues, opened and closed

Original comment by antonin on 16 Sep 2014 at 1:55

• Changed state: Accepted
• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

git is only useful when dealing with complex branching/merging strategy. 
OpenJPEG has very very limited usage of branch (patch from 1.x to 2.x are 
manually merged since code is so different).

I doubt there is any real advantage in using git as main VCS for openjpeg. BTW 
nothing prevent users from using git-svn and have full git power on there 
client. 

Please submit single, well tested, clear patch on the mailing list. The github 
workflow may work for others, we did not required it for the past 10 years or 
so. 

Footnote: I am biased since github is a closed-source platform.

Original comment by mathieu.malaterre on 16 Sep 2014 at 2:01

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Mathieu - you are right regarding bug fixes, where SVN more than suffices. But 
from my experience with working on new features, branching helps immensely.

If the feature is complex, then it will require multiple commits, and this 
context is lost when submitting a patch.  Github allows patch developer and 
repo maintainers to make comments on the code being submitted (these comments 
appear right next to the relevant lines), request changes, re-submit the 
changes, and the history of this code conversation is saved and available for 
viewing.  

Since SVN has such poor branching support, it is not surprising that OpenJPEG 
has not used many branches over the last 10 years. But this doesn't mean it 
will not be useful in the future, if it is easy to use. There is a reason why 
SVN adoption is dropping and many new OS projects use Git.

Gits excellent branch support encourages other developers to fork the code and 
add features they are interested in, and easily keep up with changes in the 
forked repo. 

Another nice feature is git rebase - when developing one often wants to make 
checkpoint commits where the code is at a sane state, but the feature is not 
complete. After the feature is ready, it is possible to combine these commits 
into one polished commit using git rebase. I use this feature a lot when working
on a feature branch,  just before I merge into the master branch.

I could go on, obviously I am a git fanatic! 

Regarding Antonin's questions: 

Yes, googlecode supports git, but the Github workflow using pull requests is 
really nice. To submit a patch, you simply fork the parent repository, make the 
changes in a branch, and press a button to submit these changes as a "pull 
request". If the maintainer likes them, they can often automatically merge the 
changes in. Otherwise, they can request changes, and go back and forth until 
everyone is happy. I have found it much easier to use than manual patch 
submission.

We can port over the entire SVN repo with history into a git repository. I have 
already done this on my mirror:  https://github.com/OpenJPEG/openjpeg
Under the "branch" button you can switch to all of the SVN branches. 
The only thing missing would be the author information, since I don't have 
access to the authors file.

Regarding moving the issues, there are scripts out there to do this, but I 
haven't tried them.

Downloads can be hosted at github too.

And yes, there is a learning curve. It will take some time to get used to the 
new tools. But, well worth it, in my opinion.

Finally, last time I checked, google code and sourceforge were also closed 
source platforms :)

Kind Regards,
Aaron

Original comment by boxe...@gmail.com on 16 Sep 2014 at 3:03

[GoogleCodeExporter]

Here is an article outlining the rising fortunes of git, and the decline of SVN:

http://readwrite.com/2014/01/21/git-subversion-developers

Original comment by boxe...@gmail.com on 17 Sep 2014 at 1:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi,

I do not use git myself (for now) as my company heavily relies on Subversion. 
Nevertheless, when dealing with opensource libraries, I can sense that I spend 
more & more time on GitHub to browse source code/check changes/retrieve tags...

The adoption of Git by the opensource community has been growing for the last 
few years & is now (from what I've read) used more often than Subversion.

Since I don't really use git, I rely mostly on what I've read here & there. But 
what I could sense while browsing GitHub, and as Aaron pointed out, the GitHub 
workflow encourages developers to fork, make their own branches for new 
features or bugfixes. Git being much more "merge friendly" (that was one of the 
reason it's been developed in the first time) than Subversion, it will be 
really easy to merge back fixes & new features in the mainline SVN (& for those 
developers, to merge the mainline in their branches on the go).

As I said, this more of a feeling than concrete experience. Nevertheless, seems 
the way to go.

As Aaron pointed out, GitHub, GoogleCode, SourceForge are all closed source 
platforms relying on opensource software so no difference there.

Regards,
Matthieu

Original comment by m.darb...@gmail.com on 17 Sep 2014 at 7:52

[GoogleCodeExporter]

@Aaron: we're investigating migration to github. One thing I couldn't find is 
how to attach files to issues ? This is something we use *a lot* in OpenJPEG, 
attaching corrupted J2K files, and so on ... Do you have any comment on this or 
advice for a solution ?

Original comment by antonin on 23 Jan 2015 at 9:24

[GoogleCodeExporter]

https://github.com/blog/1347-issue-attachments

Original comment by boxe...@gmail.com on 23 Jan 2015 at 2:28

[GoogleCodeExporter]

@Aaron: This is only for image attachments (png, gif, jpg). By any chance, are 
you aware of any solution to attach other files (like JP2 files ... Which is 
very often the case when opening an issue in OpenJPEG) ? Thanks

Original comment by antonin on 27 Jan 2015 at 2:06

[GoogleCodeExporter]

sorry, don't know how to do this.

Original comment by boxe...@gmail.com on 27 Jan 2015 at 2:16