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. 'integ.nosp@m.ralc.nosp@m.es@ll.nosp@m.iste.nosp@m.s.coo.nosp@m.pera.nosp@m.tiva..nosp@m.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.