[Gluster-Maintainers] RFC: Suggestions on patches taking more than 10 tries

[Amar Tumballi]

Possible reason it could happen, and possible suggestions, feel free to
voice your concerns:



   - If people are doing 'rebase' only to check centos regressions:
   - then I guess they should be told that they can probably be able to run
      the tests locally too.
      - is there a documentation on how to run the test locally? if not,
      lets write one.



   - If 'rebase' happens mostly to resolve merge conflicts:
   - very probable with patches which are big, and things which touch many
      files.
      - then maintainers of the components, or overall maintainers can step
      up and take call.
      - A request email for fastening the review process would also help.



   - If 'rebase' happens because maintainers like more than 50% of the code
   (ie, idea, logic etc), but there are dis-agreements on few pieces:
   - Can happen with a new contributor as they would be coming from
      contributing to different project and the method we follow may
be different.
      - Different maintainers have different opinions on how to use macros,
      how to define variables etc etc..
      - 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.
      - 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.
      - 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.
      - 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.
      - 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.


Let me know what you all think? I would also like to talk about it in
maintainer's meeting day after.

Regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20171031/c651f691/attachment.html>