Sahoo wrote:
> Kedar Mhaswade wrote:
>
>>>> But shouldn't build system *of a modular product* be designed such
>>>> that a wrong commit in module "m" does not affect anyone other than
>>>> those
>>>> who depend on latest version of "m"?
>>>
Yes. I agree. Versioning issues are still there. It is in the
to-do-list. From the surface, I don't know if this is feasible.
Addressing this would be very sensitive, causes multiple versions (of
the same functionality ) in the same build which we don't want to get into.
Right now, the wrong commit in module "m" would be known to be wrong
(or come to light), only a dependent of "m" uses it
and makes a huge cry that, "m" is wrong. That's also because, we don't
know "m" is wrong at the beginning. Why? inadequate tests that are being
checked in and conducted!
>>>>
>>>> I understand we are not there yet, but that should be our goal.
>>>
Yes.
>>> Yes, that's our goal, but the goal can't achieved by build team
>>> alone. Developers have to first modularize their components. Until
>>> then, we should have a monolithic build system to avoid all the
>>> build problems we are having today.
>>
>>
>> I agree. I had no intention to blame it on someone.
>> How should developers help?
>
By adding more tests for every module that is being worked. Have a test
ratio / metric for the lines of code generated.
>>
>> Have we identified specific action items that module developers must
>> finish?
>>
>> Have we identified modules (and owners) that make v3 Prelude release?
>
> Excellent questions.
Very good questions Kedar.
> They deserve a dedicated thread and have nothing to do with build as
> such. Do you want to start one?
May be a wiki is good to start with. Emails are confusing and can get
lost easily.
thanks,
-hg
>
>