[Dextrose] Defining Dextrose 4 code workflow

[Ruben Rodríguez]

2012/10/11 Ajay Garg <ajay at activitycentral.com>:
> Having so many branches is an overkill; it is too efforts-intensive,
> error-prone and generally daunting.

Some of those steps are optional, the workflow described is a very
complete one that would only happen during maintenance. During
development steps like staging will be omitted.

That being said, we *have* to isolate code being developed, being
tested, and being distributed. The minimal number of steps the code
should go through are:

Developer's local clones
--
Devel branch of dextrose'd package > common ground for devels to pull from
QA branch of dextrose'd package > to generate the daily rpm's
Production branch of dextrose'd packge > to generate the golden rpm's

There are two ways to do this:
A)
* The developer doesn't commit over the dextrose repo, he requests a merge.
* Code must enter in fast-forward mode, or be refactored by the devel
until it does (only a borderline case with multiple developers merging
on the same file)
B)
* All the developers push over the Devel branch


> We should just go for one branch (besides the upstream master branch).
> This singular branch should serve everyone's purposes  - developers, QA,
> staging, "golden", etc.

How would that work?

> As far as extracting patches is concerned, well, hold me responsible for
> doing it later.

The multiple-branch design is more related to having good QA than to
extracting patches.

> Right now, let's just focus on getting things completely and efficiently, IN
> AS SIMPLE A MANNER as possible, for December-16.

I'm all for simplicity, we need to find a balance so the workflow is
not a drag on the developers but still provides good separation
between development/testing and the deployment.

-- 
Rubén Rodríguez
CTO
Activity Central: http://activitycentral.com

Facebook: https://activitycentral.com/facebook
Google+: https://activitycentral.com/googleplus
Twitter: https://activitycentral.com/twitter