[Sugar-devel] [FEATURE] Automatic activity updates

[Ajay Garg]

Daniel,

what you say makes sense for small-but-critical patches (like it happens in
the linux-kernel world, where there is rarely a patch more than 10 lines
long. Moreover, the linux-kernel code is cleanly segregated into different
modules, so there are rarely clashes in people's work, as far as touching
the same code is concerned.)

However, here in "sugar", code is being modified on quite a military basis
everyday (which is a good state to be in, during the development-process
:-) ). This makes it very tedious to work ::

      * Externally on a patch (as it will be needed to be rebased everyday
on the mainline branch, if not sooner).
      * Ensure that nothing breaks (in the new feature) in every iteration
of the patch.


Thus, I agree with James. If there is a feature that is rock-solid in its
working, we must think of including in the mainline/master branch right
away (of course, after ensuring that it does not mass-break things), *and
then* make changes (if at all required). This serves the additional
following purposes ::

      * This ensures that the code-change-and-then-commit cycle is always
upto date with the latest mainline code.
      * This ensures that nothing breaks in every code-iteration (or if it
does, have a "log" and "state" in git, where it worked fine).

Of course, even an averagely smart developer will at least gauge the
broad-level architecture of the newly written feature, just by skimming
through the code. If that "bigger picture" architecture is good enough (in
addition to the fact that the feature is rock-solid), I think it makes all
the more sense to include the feature right away in mainline/master (of
course, if it does not mass-break things), *and then* continue working on
the minor tweaks (if at all necessary).

My 2 cents :)



On Thu, Jun 13, 2013 at 3:26 PM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> On 13 June 2013 07:56, James Cameron <quozl at laptop.org> wrote:
>
>> On Thu, Jun 13, 2013 at 01:54:24AM -0300, Gonzalo Odiard wrote:
>> > Yes, but somebody should provide patches, and do any change needed
>> > when the maintainers do the review, to be sure we have the quality
>> > needed upstream.
>>
>> Maintainers could do this themselves if they wanted to.
>>
>
> They could or they could have other priorities, which I suspect is the
> case here.
>
>
>> I'd caution against change given the stability of the feature in the
>> dextrose deployments.
>>
>
> These patches needs to be reviewed, like any other patch that makes it
> into the sugar code base. Even assuming they are rock stable, it's not just
> matter of stability but also of code quality, how do they integrate with
> existing code etc. If reviewers feels like they are not able to review them
> in the form they have been submitted, someone needs to refactor them. No
> way around that.
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130613/fa7501df/attachment.html>