[Dextrose] Defining Dextrose 4 code workflow

[Ajay Garg]

On Thu, Oct 11, 2012 at 6:54 PM, Ruben Rodríguez
<ruben at activitycentral.com>wrote:

> 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.
>
> It may be a bigger effort when you compare it with how we work now,
> but there are good reasons for that scheme:
>
> * A lot more provision against failure. Think of what would happen if
> we ever push a rpm update that unexpectedly makes the machines stop to
> boot or causes some other big trouble. I've seen that happen in
> several distros, and it is a project killer. At least we need to
> separate what code is golden, what is being tested by the QA team and
> what is fresh from the coders.
>

Well, I think the onus lies on the developer then, since he/she was
responsible for committing a fix that caused the catastrophe.
Moreover, I think this is a blessing in disguise (if I may say), as this
will cause such catastrophes to be caught much earlier.




> * Most of that work is supposed to be automated or to be done by the
> RM. Code going up the branches should always be fast-forward.
>

Again, another candidate for time-wastage. Why not work in one branch
itself?  That would prevent un-necessary duplicate testing by the RM.

It makes MUCH, MUCH, MUCH more sense to concentrate all testing for one
codebase (i.e. for one code, corresponding to one branch).
(and this applies to everyone, not just the RM).




> * The developers only work in their personal clones of the devel
> branch,



That is understood. As long as developers don't commit, they are free to
do anything they want to do on the branch, as long as they don't commit. A
code is "effectively" in the branch, only and only after it is
remotely-pushed.





> so from their perspective there is only *one* branch that
> matters. All the rest is risk management. Of course this is a
> provision for more developers working on the code in the future, so I
> understand it can look overkill now that you do most of the code alone
> :)
> * Some steps in the scheme are optional and can be removed, like the
> master and the production branches being different. As with any
> proposal this needs to be tuned up.
>


All this I am speaking from personal experience, as giving commit-access to
the develper was a big step in saving time (courtesy Anish).

Earlier, before committing, me and Anish had to go through the testing
process individually (meaning double effort; surely no gain). Instead,
Anish then started to test on a RPM-level (i.e. building rpms, and
deploying on the XO). That served the following purposes ::

a)
End-to-End testing

b)
Testing at a rpm-level, not patch-level.



Anyways, now that the code-review would be in-place soon, the committer
(other than the developer) will anyways test the patch once before
committing (thus providing more security against catastrophes).


In summary, I am not in favour of multiple branches. As Rafa said, we may
split into a devel-branch sometime just before the final release; but even
that too if necessary.

Let's conceentrate on just one branch - meaning one branch to test.






>
> --
> 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
> _______________________________________________
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/dextrose
>



Regards,

Ajay Garg
Dextrose Developer
Activity Central: http://activitycentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20121011/85d22615/attachment.html>