Hello Taylor,
yes, it is pretty much an extension of [1].
Basically, it would rather be quite a generic description of the
fork/branching setup that would support a clear structure for having
MITK (or any other Git-based open source project for that matter) as
your external dependency which you would like to keep up-to-date with
releases while having your own modifications that wouldn't go to the
original MITK and at the same time be able to make clean pull requests.
The structure that I think would work well is something like
http://nvie.com/posts/a-successful-git-branching-model/ with the
difference of having an additional remote with its own development
process (MITK/master branch in case of MITK).
So there should be some additional branches and merging steps where one
would integrate a new MITK release or some feature that is not in the
release yet but is needed as well as creating the pull requests for the
things that one would like to contribute to MITK.
There are several issues that I'm still trying to resolve and I will
look into it in the near future. I'm relatively new to the Git-based
development (as opposed to non-distributed VCSs), so perhaps the more
experienced users might help me with the single issue that I'm not sure
how to approach yet. The issue is that suppose I work with the latest
MITK release as I would like to have the most stable version. Now I want
to contribute some bugfix to MITK. So if I make a branch from the MITK
'master' - it will be easy to contribute to MITK, but it would be a
trouble integrating those changes to my own stable branch as the bugfix
branch will also include the changes commited between the last release
and current master head. And if I branch from my own 'stable' branch,
then the pull request will contain the changes that are not only related
to the bugfix. I approached that by basically creating a bugfix branch
from the release tag - then the pull request is clean and the
integration to my development branch is easy. This works very well for
small changes, but it seems to me that it wouldn't work so well for
larger contributions. Additionally, as the bugfix branch is made not
from the current MITK master, some conflicts may appear that could be
avoided by making a bugfix branch from the MITK master. Do you have any
clean solutions for that issue in mind?
Also, once the branch structure is stabilized, it seems to me that
creating a script should be relatively easy. It could be a python script
based on something like this: https://github.com/github3py/github3.py
and this https://pypi.python.org/pypi/python-bugzilla/1.0.0.
Cheers,
Rostislav.
On 17/04/2014 21:44, Taylor Braun-Jones wrote:
Hi Rostislav,
On Wed, Apr 16, 2014 at 12:34 PM, Rostislav Khlebnikov
<[email protected]
<mailto:[email protected]>> wrote:
I think that after I give a good run for my setup - I could write a
simple guide for GitHub-based development with MITK which would
include:
- Forking MITK repo with a stable release tag
- Setting up major branches, e.g. "stable" and "development", where
stable would contain the MITK code guaranteed to work with "MyApp" and
"development" is for syncing changes between multiple developers of
"MyApp" and/or pulling from original MITK repository for testing a new
release or particular features needed before the next release
- Branching the "development" branch to introduce changes - that can
be directly related to the bug in MITK or later renamed after
testing a
solution and filing a bug.
- Contributing to MITK - creating pull request based on branches
from
"development" branch
So the question is: are the users of MITK at all interested in such a
guide and would the developers like to include this to the
original MITK
docs/website?
Yes, I'd be interested in such a guide. I'm guessing you've found the
existing documentation[1] and just want to extend it?
I'd be even more interested in script that helps automate a common
workflow I use:
1) Fix an MITK bug my MITK branch. Commit it. (e.g. commit 1234567)
2) Create a bug report at bugs.mitk.org <http://bugs.mitk.org> [2]
3) `git fetch upstream`
4) `git checkout -b bug-XXXXX-foo-bar upstream/master`
5) `git cherry-pick --signoff 1234567`
6) `git push origin bug-XXXXX-foo-bar`
7) Create a pull request from github.com <http://github.com> [3]
8) Add the pull request URL to the bugzilla bug report
Where the usage would look something like:
$ mitk-contribute-commits [--summary <msg>] <commit>...
Full bug description report read from stdin
<ctrl-d>
MITK bug report: http://bugs.mitk.org/show_bug.cgi?id=XXXXX
GitHub pull request: https://github.com/MITK/MITK/pull/YYY
[1] http://mitk.org/How_to_contribute
[2]
http://www.bugzilla.org/docs/tip/en/html/api/contrib/bz_webservice_demo.html
[3] https://developer.github.com/v3/
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
