[Sugar-devel] [FEATURE] Automatic activity updates

Daniel Narvaez dwnarvaez at gmail.com
Thu Jun 13 09:52:37 EDT 2013


On Thursday, 13 June 2013, Ajay Garg wrote:

> 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.)
>
>
Heh patch reviews are used by the vast majority of open source projects,
certainly not just the kernel.


>
>
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.
>
>
It only becomes tedious if you fail to upstream the patch. It is good
practice to split up big changes in many small logical commits, if you had
done that the code would probably be upstream by now and you wouldn't need
to rebase it.


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

We had this discussion multiple times already and we are not making any
progress.  In the end it's up to the maintainers to decide how code should
be accepted into the tree. And, like them or not, I'd say the rules are
pretty clear these days.

As release manager, I need to know if you intend to keep working on the two
features you proposed by playing to the current rules. If you want to
convince maintainers to change them you can try but please let's keep that
as a separate topic.


-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130613/d38b00f5/attachment.html>


More information about the Sugar-devel mailing list