Define a syncronization workflow about scribus HOT 12 OPEN

From @aoloe on September 11, 2014 14:44

Here is a first proposal by Sarath:

1. 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>
   

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
   

3. 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:

1. Developers work as usual.
2. 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.

from scribus.

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.

from scribus.

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.

from scribus.

@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 (#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.

from scribus.

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.

from scribus.

From @sarathms on September 11, 2014 18:19

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

from scribus.

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

from scribus.

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.

from scribus.

@sarathms, the link mentioned in the above #13 (comment) 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.

from scribus.

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

from scribus.

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)

from scribus.

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

from scribus.