Hi Troels,
Before reading this, note that I will write two responses. The first
one, this one, you will find a little negative. The second, which
will come a little later, will be git-positive. So, to the first
post:
I'm sorry I didn't explain the process properly at the start. Most of
the difficulties you have encountered are only in the initiation
stages of joining the relax project. But it is only temporary! Once
a someone has been voted in as a developer - after the contribution of
a certain amount of code so that trust can be built up - then the
commit process becomes much easier. The process once full commit
access has been granted would be:
0) Maybe first discuss the idea on the mailing list, if it is a major change,
1) Write the code,
2) Commit.
That's it! It's very simple. There are some post commit steps, but
these are independent of the version control system. For example
maybe the code is not the best solution, or it breaks other parts of
relax. Then the commit needs to be reverted. And then there is the
responding to feedback on the commit. This is much easier, and there
is no waiting (unless there are discussions).
One thing I agree with is that this process is a little painful. But
the simplest way for new developers is:
0) Simply bite the bullet and use subversion (for now),
1) Make a change according to discussions on the mailing list,
2) Use 'svn diff > patch' to create a patch,
3) Submit the patch for review,
3b) At the same time write a suitable commit message - also for review,
4) Once reviewed and changed are needed, go back to step 1,
4b) Otherwise once reviewed and everything is ok, it will be
committed by a relax developer,
5) Run 'svn up',
6) Only then can you go back to step 1.
This is difficult and the pace is painfully slow at the start. But
this does have a huge advantage that git does not. With git you start
at a running pace. But when you start up with an established project,
you must start at a slow walking pace! This is important because all
new developers need to be pointed in the right direction. The first
code someone writes will, without question, require major revision and
modifications (the commit messages as well).
So this is one aspect that I strongly disagree with in the git
philosophy. The initial review process for git is not ideal for a new
developer. They will have run too far (too many commits) in the wrong
direction before they receive feedback. I do not like this! The git
philosophy is to ignore these rogue developers and don't pull from
them. This I also don't like - it is not very productive. And the
new developer will be very unhappy when their code is rejected and not
being pulled upstream. I have seen this process in action, and it is
very effective in loosing new developers. I would prefer to help the
developer take the correct direction at the start. And this requires
a very slow process with thorough review. Step 4 above, the waiting
game, is frustrating. But this step 4 is essential for the initial
training.
Once the initial training is over and you are a full developer, then
there will be no more waiting. Until then, you can drastically
decrease the waiting time by prompting me via Google Chat, MSN, etc.
(assuming I'm not on holiday, as I was at the start of this month). A
good target would be to have the NMRPipe seriesTab support in the
trunk functional, and maybe also adding the Tollinger/Kay equation to
the relax_disp branch. This will clearly show your abilities to the
relax developers and that you can be trusted, and we can then hold the
private vote. This is not all inclusive like git (let us ignore the
fact that many are ignored in the git system), but it is a meritocracy
and anyone can prove themselves and become a developer. Code speaks
louder than words (unless you are adding text to the manual). There
is nothing stopping anyone from joining. And the barrier of entry is
about the same with svn and git, despite being free to run in any
direction within the git system. Linus Torvalds is free to ignore new
developers in the Linux project
(https://www.youtube.com/watch?v=4XpnKHJAok8) but, in a small project
like relax, we are not at liberty to take such an approach.
Now, as for using git itself, that is something I have considered for
many, many years now. I have also considered GNU Arch and Mercurial.
The only reason there has not been a shift is because the Gna!
infrastructure does not currently support this. The other is that the
initial developer training is much more difficult. I will start a
second thread about the benefits of using git as this is a separate,
very much unrelated issue.
Regards,
Edward
On 24 July 2013 01:54, Troels Emtekær Linnet <tlinnet@xxxxxxxxx> wrote:
Hi relax developers.
I would like to suggest yet another development possibility by using Git.
Motivation:
Subversion needs an online repository, to store each commits.
Subsequent calls to svn diff > patch will generate the difference
according to the last revision.
Therefore the development at the moment require to:
* make some lines of code
* make a path file and a commit message
* use the support tracker to upload patch and commit message
wait for acceptance
wait for commit to official repository
then do an svn update
then return to point 1
This takes time, and require that repository maintainer is online.
If the above scheme is not followed, the patch files will come out of sync.
I suggest to introduce yet another development possibility by using Git.
I do not suggest to shift away from the GNA! infrasctructure,
I merely suggest to use the powers of Git, to collaborate on a feature
development, before
releasing a patch for review and commit to SVN repository.
This is maintained by a server, who tracks the relax-commit messages at
http://www.mail-archive.com/relax-commits@xxxxxxx/
That server translates the history, and commits to github.
Here a range of developers can pull the latest changes.
Make feature branches. Share those branches.
Make edits online. Use android/iphone apps.
Work on trains/planes etc. Allowing offline commits.
When the feature is ready, easily make a patch file, and upload
to the GNA trackers.
The patch file contains all the commit messages, and
changes between each commit.
That should make it easy to review, and comment on.
Git also allow to squash commits and rewrite commits.
A feature highly appreciated, based on the review comments.
I have made a wiki page, from where we can start discussing.
Here I tried to make an image of my idea.
I am very skilled in MS paint. :-)
http://wiki.nmr-relax.com/Git_development
Best
Troels Emtekær Linnet
_______________________________________________
relax (http://www.nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
Re: Suggested faster development with Git, keeping GNA infrastructure