<div dir="ltr"><div>Daniel,<br><br>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.)<br>
<br></div><div>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 ::<br>
<br></div><div> * Externally on a patch (as it will be needed to be rebased everyday on the mainline branch, if not sooner).<br></div><div> * Ensure that nothing breaks (in the new feature) in every iteration of the patch.<br>
<br><br></div><div>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), <i>and then</i> make changes (if at all required). This serves the additional following purposes ::<br>
<br></div><div> * This ensures that the code-change-and-then-commit cycle is always upto date with the latest mainline code.<br></div><div> * This ensures that nothing breaks in every code-iteration (or if it does, have a "log" and "state" in git, where it worked fine).<br>
<br></div><div>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), <i>and then</i> continue working on the minor tweaks (if at all necessary).<br>
</div><div><br></div><div>My 2 cents :)<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 13, 2013 at 3:26 PM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On 13 June 2013 07:56, James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Thu, Jun 13, 2013 at 01:54:24AM -0300, Gonzalo Odiard wrote:<br>
> Yes, but somebody should provide patches, and do any change needed<br>
> when the maintainers do the review, to be sure we have the quality<br>
> needed upstream.<br>
<br>
</div>Maintainers could do this themselves if they wanted to.<br></blockquote><div><br></div></div><div>They could or they could have other priorities, which I suspect is the case here.<br></div><div class="im"><div> </div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'd caution against change given the stability of the feature in the<br>
dextrose deployments.<br></blockquote><div><br></div></div><div>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.<br>
</div></div></div></div>
<br>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br>Ajay<br>
</div>