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 <[email protected]> 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 > [email protected] > http://lists.gluster.org/mailman/listinfo/maintainers > -- Amar Tumballi (amarts)
_______________________________________________ maintainers mailing list [email protected] http://lists.gluster.org/mailman/listinfo/maintainers
