[Dextrose] Defining Dextrose 4 code workflow

[Ajay Garg]

On Thu, Oct 11, 2012 at 7:40 PM, Anish Mangal <anishmangal2002 at gmail.com>wrote:

> 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
>

+1. That's why Rafa point makes absolute sense, to have a devel-branch
before the final release (in case development needs to start on new
feaures, that ought NOT to go in the release).


> 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.
>

+10.
Here, by testing I meant just a confirmation that the patch worked in the
"broad" sense, and did not render the system/UI usable (this is a part of
on-going discussions with Rafa, as to how to enable code-review, so that
there are more eyes for the code, and developers in general remain in sync).

I compleltely agree that the finer/polishing touches need to be given by
the QA, as they don't face the mental-blocks that developers tend to have
(at least I do, when I am in that "developer" zone :D ).

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
>>
>>


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/d6749811/attachment.html>