Collaboration: pull request? Or direct commits?

[gbonnema]

Hi Alessandro,

I am undecided what is the best strategy to propose change. The advantages of pull request are:

• They are a checkpoint before commit and merge
• They are a checkpoint for review and comments with resulting changes
• They are traceable after the fact

A point of consideration is that each commit to the same branch gets added to an existing pull request. That should not be a problem as long as I keep different pull request into different branches, or withhold new changes until the pull request is put through.

The advantages of direct commits are ease of use and traceability trough commits. What they miss is the possibility to comment and change before the final commit.

At the moment I have some changes that I could commit directly, but I am hesitant to do so. Also, I could easily transfer the changes to my own (forked) repo and then do a pull request.

What is your stance on this subject? How do you want us to work together?

[gbonnema]

Awaiting a reply, I had time to work and think about this. I decided that doing pull requests would be clearer for all. Even if I merged them into devel myself, at least it would be traceable and if necessary we could revert changes. I am pretty sure that at some point we will merge something that we will have to revert anyway for any of a list of reasons: too soon, bug in commits, did just not work out, etc. etc.

I have now 2 pull requests waiting. Would you mind terribly if I would merge them? I noticed you didn't have the time to comment on them and I would really like to build on these changes. Any comments? Suggestions?

OTOH I don't want to do anything to antagonize the only partner I have in this ;P

[amagnasco]

I'm swamped right now, so I'm going to add continuous integration testing so we have some degree of help with this. It's going to be through Travis CI, so there's going to be a weird file in the main directory configuring the testing paradigm.

Let's add another branch, "experimental", for changes that haven't been tested by more than one person. I'll merge your requests into that one, and you should feel free to merge into these as well (I added you as a collaborator). I want us to make sure the devel branch is 100% clean for the first milestone. This software has way too many bugs for us to add more to the public branch.

This brings me to the second question, which is, how do you want to be credited for your work? So I can add it to the readme.

Best, Alessandro

[gbonnema]

On 06/04/2017 08:04 PM, Alessandro G. Magnasco wrote:

I'm swamped right now, so I'm going to add continuous integration testing so we have some degree of help with this. It's going to be through Travis CI, so there's going to be a weird file in the main directory configuring the testing paradigm.

Let's add another branch, "experimental", for changes that haven't been tested by more than one person. I'll merge your requests into that one, and you should feel free to merge into these as well (I added you as a collaborator). I want us to make sure the devel branch is 100% clean for the first milestone. This software has way too many bugs for us to add more to the public branch.

This brings me to the second question, which is, how do you want to be credited for your work? So I can add it to the readme.

Best, Alessandro

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/amagnasco/xwpe/issues/31#issuecomment-306056422, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLZqy1MWLGr-pDd3xAS3nJlzMCyOuIPks5sAvGqgaJpZM4NqR_e.

Continuous integration with Travis is fine. Travis is flexible enough to add anything, including functional tests.

I don't object to the experimental branch, but usually development is on the devel branch and experimental changes on subbranches of devel. I suspect that what you are looking for is a release branch, that you only create after you have agreed on the changes, but not yet tested them extensively. The release branch should be flawless before merging with master (= production).

On the other hand, it really doesn't matter what names we use, so experimental for development and devel for milestones is fine by me.

How to be credited? I am not sure what you mean, but if you need my name, it's Guus Bonnema. If it is something else you are after, let me know.

Kind regards, Guus.

[amagnasco]

Re: experimental branch, sorry I wasn't clear-- that is exactly what I did.

Recent changes: Experimental subbranch created under development. Basic CI added to Master. Build is passing.

Currently doing: Trying methods for extended CI in Experimental. Build failing. Adding your name to the Readme.