<div dir="ltr"><div>Possible reason it could happen, and possible suggestions, feel free to voice your concerns:</div><div><br></div><div><br></div><div><ul><li>If people are doing 'rebase' only to check centos regressions:<br></li><ul><li>then I guess they should be told that they can probably be able to run the tests locally too.</li><li>is there a documentation on how to run the test locally? if not, lets write one.</li></ul></ul></div><div><br></div><div><ul><li>If 'rebase' happens mostly to resolve merge conflicts:<br></li><ul><li>very probable with patches which are big, and things which touch many files.</li><li>then maintainers of the components, or overall maintainers can step up and take call.</li><li>A request email for fastening the review process would also help.</li></ul></ul></div><div><br></div><div><ul><li>If 'rebase' happens because maintainers like more than 50% of the code (ie, idea, logic etc), but there are dis-agreements on few pieces:<br></li><ul><li>Can happen with a new contributor as they would be coming from contributing to different project and the method we follow may be different.</li><li>Different maintainers have different opinions on how to use macros, how to define variables etc etc..</li><li>In this case, I suggest maintainers can send a message to author, and send an updated patch with their suggestion (with making sure '--author' is set to original author). This can save both the effort of review, and also heart burn of someone not understanding the comments properly. </li><li>Documenting that this can happen also means a developer wouldn't feel bad, and would learn from watching the actual diff between his last change, and the change maintainer did.</li><li>This also means, a work which may be critical for the project doesn't take very long to land into project. Reminder, stability and progress of the project should be our utmost priority.</li><li>Note that I have seen at least 5 such instances where if the reviewer picked up the patch, and worked on it, it could have been faster.</li><li>Again, this is not good to repeat always from a developer. Should be OK for a contributor who is less than an year into the component (Considering different maintainers have different choices). Not ideal for someone older than that to the project. But it should be maintainer's call.</li></ul></ul></div><div><br></div><div>Let me know what you all think? I would also like to talk about it in maintainer's meeting day after.</div><div><br></div><div><div>Regards,</div><div>Amar</div><div><br></div><div class="m_3644521334551501092gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br></div></div></div></div></div>
</div></div>