Draft github workflow document created

[jbalunas]

Hi All,

I just create the initial github workflow document AeroGear GitHub Workflow & Instructions based on Hacking on AS7 and working in our own comments and thoughts from the team meeting.

The only one I have not integrated with the branching concepts from Qmx - https://img.skitch.com/20111212-f6qd1bf38ucsw4gb56tcj2j1y3.jpg

Qmx - could you write in this thread how these changes would effect the workflow?  Also what would happen when users have overlapping topic branches going at the same time?  The image you provided looks very linier.  I just want to make sure I understand it better, so we can discuss it.

I'm also create How to Handle AeroGear Pull Requests document to talk about the steps we need to take for a clean merge, and other requirements.

Please let me know what you guys think?

-Jay

[jbalunas]

I've also updated the contributing to AeroGear, and jira usage wiki pages to be current.  Please take a look at these and let me know if I missed anything or if you have comments?

Contributing To AeroGear

AeroGear Jira Usage and Guidelines

[jbalunas]

Note that I've also created the AeroGear Licensing and Copyright page and have updated the AeroGear IDE config repo with the correct license and copyright information.  Note that these updates are in the aerogear branch, which is now the default branch for that repo.

[qmx]

The only one I have not integrated with the branching concepts from Qmx - https://img.skitch.com/20111212-f6qd1bf38ucsw4gb56tcj2j1y3.jpg

Qmx - could you write in this thread how these changes would effect the workflow?  Also what would happen when users have overlapping topic branches going at the same time?  The image you provided looks very linier.  I just want to make sure I understand it better, so we can discuss it.

My suggestion boils down on relaxing the "squash to one commit rule", meaning that it's good to keep history (given that the history is meaningful (usually it is).

About it looking very linier, that's exactly how it should look. Before doing the no-ff merge, you rebase your branch to keep the history linear, and in this case, linear != having no merge commits. I started adopting this practice after suffering to find a regression on a 20-commit-squashed-to-one

[jbalunas]

Douglas Campos wrote:

My suggestion boils down on relaxing the "squash to one commit rule", meaning that it's good to keep history (given that the history is meaningful (usually it is).

I agree with relaxing the "squash to one commit rule" - I think there is some wording around that.  I'll update make it clear that your only need to squash trivial commits.

Douglas Campos wrote:

About it looking very linier, that's exactly how it should look. Before doing the no-ff merge, you rebase your branch to keep the history linear, and in this case, linear != having no merge commits. I started adopting this practice after suffering to find a regression on a 20-commit-squashed-to-one

Let me see if I get this one - sorry for seeming dense. 

In your situation before merging your topic/pr branch, you rebase to the latest, and then merge to master.  This would give you the type of history here - https://img.skitch.com/20111212-f6qd1bf38ucsw4gb56tcj2j1y3.jpg

Each topic branch is isolated until merged, and you have a merge commit?

[qmx]

Each topic branch is isolated until merged, and you have a merge commit?

Perfect, that's exactly what I meant

[jbalunas]

Lets get some more feedback on this, but I think this would be good. 

Anyone else have thoughts here?