/**

@file
@page dev_flow IntegralCES Developer Workflow

This continues to explain the form of work on the IntegralCES development
team and the resources that are used.

### Communication

We have and use the following communication channels:

* **Channel #integralces** on Freenode IRC Network. This is the most immediate
and most informal channel, enter and try your luck.

* **Email List**. 'integralces@llistes.cooperativa.cat' Email distribution list
which coordinates the project, mainly at the level of development as well as
communication, etc. The list is vailable to the public and you can join at 
http://llistes.cooperativa.cat:8081/mailman/subscribe/integralces . The usual 
languages of the list are Catalan and Spanish, although if you write in English
we will also respond.

* **Issue queue on drupal.org**. We use the list of _issues_ on drupal.org to 
keep organized the remaining tasks, who is responsible for working on it, etc.
This content is in English generally. There are separate issue queues for the
modules ( https://drupal.org/project/issues/ices ) and the greences theme 
( https://www.drupal.org/project/issues/1866046 ). Any minimally relevant
development needs to have its _issue_ associated.

### Flow of development

By 'development workflow' we mean the steps we have to take since we decided to
change the code of the project in order to realise something better that is
in published code and integrated in the project. The flow is based on the
recommendation of drupal.org located at https://drupal.org/node/711070 .

We have the following considerations:

  * The only general and common branch we work with is the branch with the
  name **7.x-1.x**. This is the branch that we call 'development'. The master
  branch is empty. There is no stable branch yet (it will be tags on 7.x-1.x).

  * When we want to play with code, we make a new branch for that _issue_
  following the convention that the name of the branch is: 
  `[issue-number]-[short description]`. For example:
    
    $git branch 1916476-migration
    $git checkout 1916476-migration

  * Until that issue is completely finished and revised, or what you need to 
  do once it is ready is _merge_ it into the main branch **7.x-1.x**.
  In particular, we may have important functions that are separated from the
  main branch for a long time. In the case of fixing bugs or making small
  things, we can do direct merge onto the main branch. 
  We have to ensure that the main branch always passes the automated tests.
  This does not mean that we always have to work in local: we can use the
  branches as necessary in the repository at drupal.org.
  * When we want to launch a stable version, we will make a tag in the 7.x-1.x
  branch. Thus is its not necessary to maintain two branches, for stable and
  development. 

### Example of development workflow

We collect an incident (issue) of the project or we create as necessary in
queue:  https://drupal.org/project/issues/ices

We make a branch referencing the incident:

  $git branch 2207369-Notice_messages
  $git checkout 2207369-Notice_messages
    
We make the developent or correct the bug, etc.

Pass the test. From the web: 

`/#.overlay=admin/config/development/testing`

If Overlay module is not active, use on web: 

`admin/config/development/testing`

Or in drush:

    $drush test-run --xml CES

Generate an xml archive with the details of the test in testsuite...xml

When all is good, we merge this with the main branch:
    
    $git fetch origin                    # Update the local with the remote
    $git rebase origin/7.x-1.x           # Match changes with 7.x-1.x branch
    $git commit -m "Issue #2207369 by Bob. Fix notice messages"
    $git checkout 7.x-1.x                # Get ourselves onto the main branch
    $git pull                            # Combine local and remote
    $git rebase 2207369-Notice_messages  # Combine branch w changes to 7.x-1.x
    
We submit our changes to the server:
    
    $git push

Close our incident (issue) on Drupal.org.

*/
