On Thursday, 13 June 2013, Ajay Garg  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></div></div></blockquote><div><br></div><div>Heh patch reviews are used by the vast majority of open source projects, certainly not just the kernel.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></div><div></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><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). </div>
</div></blockquote><div><br></div><div>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, <span></span>I'd say the rules are pretty clear these days. </div>
<div><br></div><div>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.</div>
<br><br>-- <br>Daniel Narvaez<br><br>