[Dextrose] Defining Dextrose 4 code workflow

[Anish Mangal]

I guess one thing to remember here is that we have a dedicated quality
assurance team.

As a developer it makd s sense to have a fast dev cycle
As a PM it makes sense to have quality release
As a qa person it makes sense to be thd last person to signoff before a
package is declared golden
As a customer any bug that passes through devel to golden untested is a big
failure on ACs part

So
We need to think not only in terms of developers being able to come up with
quick changes but qa also being able to test them. Those processes need to
bw delinked as much as possoble so they dont block on each other
unnecessarily

Also I dont buy the argument that incentivizing developers to test more is
going to solve our testing requirements. There is a reason companies invest
in q.a. developers test pieces of code. Q.a. tests the functionality and
its correctness. That is ultimately what is most important to the customer.

Just my 2c
On Oct 11, 2012 9:40 AM, "Ajay Garg" <ajay at activitycentral.com> wrote:

>
>
> 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
>
> _______________________________________________
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/dextrose
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20121011/f5c4f7d5/attachment-0001.html>