[Gluster-Maintainers] Patch-etiquette reminder

[Amar Tumballi]

Hi Jeff,

Thanks for reminder, I was almost about to believe 'experimental' was my
personal branch :-P

I will try to respond inline, and try to clarify some concerns!

On Thu, Aug 31, 2017 at 9:43 PM, Jeff Darcy <jeff at pl.atyp.us> wrote:

> I've seen a few patches lately that were merged before affected parties
> in other timezones had a chance to see them (or see them in their
> current form).



>   In at least one case, a patch wasn't even reviewed by
> *anyone* other than its author before being merged.


Sorry about both the above. I am fine to have max of 2 day delay in minor
patches and a week for any large patches, unless there is any review from
either peer or maintainer of specific component.



> I'd like to
> discourage this.


Ack!


> Yes, even on the "experimental" branch because that's
> already more active than master so it's effectively what master should
> be.


But, To be honest, in last 3 months of activities in 'experimental' branch,
I
just had you reviewing one patch and ndevos checking 2-3 patches (mainly
the commit message). Other than that, mostly I did was to rebase long
pending
patches from master, with exception of below:

Significant feature/enhancement patches are:
1) error code patches (for github issue #280)
2) changes for 'metrics'.



> If something's not reviewed on experimental, the chances that it
> will *ever* be reviewed before being merged into master trend toward
> zero.


Agree! But, again when I proposed the 'experimental' branch, idea was to
push changes *quickly* to repository where other significant changes are
also happening, so we can keep running regressions, and feel confident
about the patch. We surely need people to participate in reviews even when
patch is submitted to experimental, rather sometime develop them here
instead of taking 40+ iterations for 1 big patch.

We have a review process for a reason.  Reviewing helps us avoid
> bugs that would be more difficult to find at later stages, and design
> errors that might lead to costly rewrites when issues already known in
> the community but not to the author are raised.  It's an essential part
> of effective collaboration, and we should try to maximize those
> benefits.
>

Totally agree! I would like to hear how we can get more eyeballs into
experimental branch, mainly considering about meeting possible deadline of
Nov-Dec, 2017 for Gluster 4.0.

Regards,
Amar



> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>



-- 
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170831/a94aff30/attachment.html>