AeroGear github repo cleanup and setup

[jbalunas]

The AeroGear github organization needs to be cleaned up and organized for the launch.

Right now it have forks of jboss-as/quickstarts and /archetypes.  We don't want to have all of the quickstarts and archetypes in our repo because keeping them in sync with so many updates is a pain.  It also makes it more confusing to new users what parts are from the AeroGear team. 

We need to look into using git sub-modules or some other approach so that the AeroGear quickstarts and archetypes are included in jboss-as repos, but pointing to AeroGear repo.

We also need to discuss other repository and structure setup.

Do's:

• Have an /examples repo for most examples
  • Exceptions could be made for more advanced examples, or key demo's
• Have code style, and format settings for IDE's in the repo
• Keep archetypes separate from the examples
• Common AeroGear parent in place for maven based builds
• Forks of 3rd party projects we intend to modify
  • Likely not right away

Don'ts:

• Have 1 repo for each example
  • Should have a /examples repo or something like that

What else should we consider and have as part of our repo?

[jbalunas]

So our initial structure might be something like:

/examples

/archetypes

/code-style

/parent

BTW - one issue with git submodules is it is likely that only repo's can be pointed too.  That means AeroGear quickstarts and archetypes for jboss-as would each need their own repo.  This is not ideal.  Perhaps go with Wesley's suggestion and just have a readme fine in the AeroGear quickstarts/archetypes in jboss-as that points to our repo for the latest versions. 

I'll need to talk with Pete about this, and also about possible workflows with this.

[jbalunas]

I had a quick talk with Pete, and he believe subtree merges might be a better approach than sub-modules, but he also warned that both approaches can make for more complex workflows and ?history?.

I'll follow up with Pete, as he said once we know the requirements we can pretty much make git do anything.

-Jay

[wesleyhales]

Why can't we just detach from the AS7 quickstarts?

[jbalunas]

Because it will be important that our examples are included with the quickstarts.  The primary reason being exposure for AeroGear, and vs versa for JBoss AS quickstarts. 

So maybe with that it just makes sense to keep the complete /archetypes, and just keep whatever jboss-as quickstart/archetype we have in there?  Then any other examples - like aerogear-7 - should exist on their own in aerogear repos.

[jbalunas]

Some notes from my talk with Pete.

• /aerogear/quickstarts[archetypes] repo
  • Will only have aerogear related content
    • And only content we want in JBoss-as q&a (quickstarts, archetypes)
  • Must follow in sync with jboss-as coding standards
  • Pete is investigating sub-tree's to accomplish this
  • We need to get our repo's (q & a) into the shape we want them to integration.
  • Repo name in aerogear might be as-quickstarts and as-archertypes or something like that
  • The jboss-as team will only pull from a tag - M1, M2, etc...
  • The jboss-as team must be notified of pull requests to review as well
  • We'll work with Pete for initial setup
    • likely M1
    • then we'll work through instructions pete writes for others
• /aerogear/examples repo
  • Will have non jboss-as quickstart examples for various things
  • Any larger examples we want broken out will have their own
• /aerogear/denizen
  • Example of a large example with its own repo
• /aerogear/code-styles
  • Will fork jboss-as's coding standards
• /aerogear/parent
  • Not sure we need this one - will think on it

[jbalunas]

We also discussed git workflow and some rules for it.

We will need to review JBoss AS workflow, and talk with Jason to see if they have it written down.  It is not following gitflow, but does have a multi-step workflow for commits, merges, rebasing, etc...  It is similar to the dictator+trusted lieutenants approach from pro-git, but might have changes - http://progit.org/book/ch5-1.html

Rules:

• Never push your own commits upstream
  • Always use a pull request, and have someone else merge it
• Don't use github pull request merge
  • Merge/rebase yourself then close the pull request
• Never do any work in your master
  • Always use topic branches
• When ever you merge rebase.

We need to get worked out quickly.

[wesleyhales]

Here's the AS7 workflow https://community.jboss.org/wiki/HackingOnAS7

[pmuir]

Would recommend following the As7 workflow.

[jbalunas]

Create https://issues.jboss.org/browse/AEROGEAR-64 to cover the as-quickstart, and as-archetype setup.