Define a syncronization workflow

luzpaz commented 9 years ago

From @aoloe on September 11, 2014 14:38

Currently, we have:

The "svn" branch that get's automtically updated from the scribus' svn server.
The "master" branch that is manually kept in sync with the "svn" branch. This branch is where pull requests from the forks will be committed to 'master' after review.

We need to find a good workflow that allows us to keep the "master" in sync with the commits with the team.

The issues that should be considered:

conflicts that happen when a patch from "master" is also applied -- with small changes -- into the svn "trunk".
each patch that gets into "master" (on github) will have also to be manually uploaded to the bug tracker and we will have to wait (potentially for a long time) before they are applied "upstream".

As long as we have not pulled anything into master yet, we can use the simple workflow described by sarath:

Until we have a good workflow we can follow a simpler one (made possible by the fact that "master" has no changes yet):

https://github.com/sarathms/scribus/wiki/git-developer-workflow describes how anybody can make a pull request for the update.

here is the workflow for somebody having push rights on the scribusproject repository:

$ git clone git@github.com:scribusproject/scribus.git scribus-github
$ git checkout svn
$ git pull
$ git checkout master
$ git pull
$ git merge svn -X theirs
$ git push origin master

Copied from original issue: scribusproject/scribus-old-to-be-deleted#13

luzpaz commented 9 years ago

From @aoloe on September 11, 2014 14:44

Here is a first proposal by Sarath:

Rebase the 'master' branch with the svn commits since last rebase. Needs a

$ git svn rebase
First, rewinding head to replay your work on top of it...
Applying: <commit message from step 2>

Commit to the svn repo from the master branch with

$ git svn dcommit
Committing to https://svn2.sliksvn.com/sarathmada_scribussvn ...
 M    Readme.md
Committed r9
 M    Readme.md
r9 = 23f353f056fb9f004b7dc9405490147d5a5abee9 (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn

Rebase the 'svn' branch again to get the above commits from the svn server, not directly from master.

$ git checkout svn
$ git svn rebase
First, rewinding head to replay your work on top of it...
Fast-forwarded svn to refs/remotes/git-svn
server, not directly from master.

On SVN:

Developers work as usual.
Commits from svn come in like how commits come from another server, not directly from master. additional developer, representing many other developers from the other world.

luzpaz commented 9 years ago

From @JLuc on September 11, 2014 15:43

As for now, scribus core developpers want to stick to svn tool, and want to review very carefully each submitted code dont they ? So, "commit to the svn repo" refers to an unknown future when scribus developpers have changed their mind. Do i understand well this proposal ? IMO, at the moment, code merges to the svn repo will first have to be created against svn branch out of their original branch, or out of the master branch ... and then posted on the mantis bug tracker for review and feedbacks ! ... Unless, of course, some of the scribus core dev accepts to use git and to test the patches and to merge them into svn repo.

luzpaz commented 9 years ago

From @aoloe on September 11, 2014 16:47

@JLuc, you're right: each patch that gets into "master" (on github) will have also to be manually uploaded to the bug tracker and we will have to wait (potentially for a long time) before they are applied "upstream". i add this remark to the description above.

luzpaz commented 9 years ago

@JLuc @aoloe agreed some things:

My hope is that we can generate enough activity and patches coming from GitHub that the devs will recognize the wisdom in embracing git
That it's possible to test by quickly merging changes into master and then building scribus from master to test changes.
If we integrate a Continuous Integration engine like Travis CI (https://github.com/scribusproject/scribus/issues/6) then we can possible create seamless downloadable builds that can be tested. Because when ever someone submits a PR it can trigger Travis/Jenkis to test it.

luzpaz commented 9 years ago

From @sarathms on September 11, 2014 18:13

I was considering the possibility that github commits may have to go through the bug tracker as patches, but I was hoping that there would be at least one dev on github with commit privileges on svn.

git -> mantis -> svn sounds good too.

luzpaz commented 9 years ago

From @sarathms on September 11, 2014 18:19

Checking this out now Integrating Git and SVN with the Mantis Bug Tracker. Sounds relevant.

luzpaz commented 9 years ago

From @aoloe on September 12, 2014 9:2

@luzpaz, for testing patches, you don't even need to merge the pull request into master:

have a look at the diff and check that it's not malicious
clone, build and run the contributor's fork

luzpaz commented 9 years ago

From @sarathms on September 12, 2014 9:45

@aoloe going further, if @luzpaz's #6 is completed, pull requests would be built automatically for basic testing. But if more is needed, a core-dev can just checkout the pull request temporarily as documented here. Dev can even fix problems in pull requests if needed, or the contributor can be asked to do it.

luzpaz commented 9 years ago

@sarathms, the link mentioned in the above https://github.com/scribusproject/scribus/issues/13#issuecomment-55305876 doesn't have any live links to the plugins. It's also from 2009. Need to do a little more digging to see if there is a modern version of this. Thanks for finding that.

luzpaz commented 9 years ago

From @JLuc on October 11, 2014 19:1

today irc talk summary :

S : user forks from github -> commits to local master -> submits PR to github -> goes to MantisBT for reivew -> patch accepted -> scribus-git developer commits PR to local master -> sends commit to SVN -> committed on SVN -> github svn syncs with SVN -> master synced with svn

Some comments :

S : in such a case we don't need a separate branch. master itself can be a read-only svn-sync'ed branch to make PR's against because if we are not adding anything new to master, then it'd essentially be the same as svn, only older at times.

A : personally, i would not by default refuse the PRs because people might be very deceived and stop contributing if their patches do not show up anywhere after six months

luzpaz commented 9 years ago

From @aoloe on October 12, 2014 8:14

A:

people fork from github
create local branches and commit to them.
when they think their work is ready, they make a pull request against scribus' master
the patch gets reviewed
if the user is fine with with it, we can ask him/her to submit the patch to mantis, otherwise we will do it for him/her (you know, people are using git and github because they like it!). the link to mantis gets attached to the pull request.
the patch gets eventually a review from the team and/or gets integrated into svn
if the patch makes it into svn, it will be get through that way into the github master, we can attach the link to the svn commit message and we can close it (can we accept it and then manually refuse all conflicts or is it much simpler to just refuse it?)
if the patch lies for a longer time uncommented in mantis, we might want to accept the pull request and apply it to master and manually solve the eventual conflict when eventually the patch comes again in through svn. (we will probably have to properly document the status of the patches that gets in this way)

luzpaz commented 9 years ago

Because we haven't heard from @moskalenko I've for the time being disassociated @mrscribe from the project and @aoloe I anticipate will be working on implementing @chhitz's great work at https://github.com/scribusproject/scribus_svn_git

scribusproject / scribus

Define a syncronization workflow #8