[Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Niels de Vos]

On Thu, Nov 10, 2016 at 02:13:32PM +0530, Pranith Kumar Karampuri wrote:
> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee <amukherj at redhat.com> wrote:
> 
> >
> >
> > On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
> > pkarampu at redhat.com> wrote:
> >
> >> I am trying to understand the criticality of these patches. Raghavendra's
> >> patch is crucial because gfapi workloads(for samba and qemu) are affected
> >> severely. I waited for Krutika's patch because VM usecase can lead to disk
> >> corruption on replace-brick. If you could let us know the criticality and
> >> we are in agreement that they are this severe, we can definitely take them
> >> in. Otherwise next release is better IMO. Thoughts?
> >>
> >
> > If you are asking about how critical they are, then the first two are
> > definitely not but third one is actually a critical one as if user upgrades
> > from 3.6 to latest with quota enable, further peer probes get rejected and
> > the only work around is to disable quota and re-enable it back.
> >
> > On a different note, 3.9 head is not static and moving forward. So if you
> > are really looking at only critical patches need to go in, that's not
> > happening, just a word of caution!
> >
> 
> Yes this is one more workflow problem. There is no way to stop others from
> merging it in the tool. I once screwed Kaushal's release process by merging
> a patch because I didn't see his mail about pausing merges or something. I
> will send out a post-mortem about our experiences and the painpoints we
> felt after 3.9.0 release.

All bugfix updates have defined dates for releases. I expect that all
maintainers are aware of those. At least the maintainers that merge
patches in the stable branches. A couple of days before the release is
planned, patch merging should be coordinated with the release
engineer(s).
  https://www.gluster.org/community/release-schedule/

This is not the case for 3.8 yet, but because it is in RC state, none
but the release engineers are supposed to merge patches. That is what we
followed for other releases, I do not assume it changed.

We should probably document this better, possibly in the maintainers
responsibilities document (which I fail to find atm).

Niels


> 
> 
> >
> >
> >> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee <amukherj at redhat.com>
> >> wrote:
> >>
> >>> Pranith,
> >>>
> >>> I'd like to see following patches getting in:
> >>>
> >>> http://review.gluster.org/#/c/15722/
> >>> http://review.gluster.org/#/c/15714/
> >>> http://review.gluster.org/#/c/15792/
> >>>
> >>
> >>>
> >>>
> >>>
> >>> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
> >>> pkarampu at redhat.com> wrote:
> >>>
> >>>> hi,
> >>>>       The only problem left was EC taking more time. This should affect
> >>>> small files a lot more. Best way to solve it is using compound-fops. So for
> >>>> now I think going ahead with the release is best.
> >>>>
> >>>> We are waiting for Raghavendra Talur's http://review.gluster.org/#/c/
> >>>> 15778 before going ahead with the release. If we missed any other
> >>>> crucial patch please let us know.
> >>>>
> >>>> Will make the release as soon as this patch is merged.
> >>>>
> >>>> --
> >>>> Pranith & Aravinda
> >>>>
> >>>> _______________________________________________
> >>>> maintainers mailing list
> >>>> maintainers at gluster.org
> >>>> http://www.gluster.org/mailman/listinfo/maintainers
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>>
> >>> ~ Atin (atinm)
> >>>
> >>
> >>
> >>
> >> --
> >> Pranith
> >>
> >
> >
> >
> > --
> >
> > ~ Atin (atinm)
> >
> 
> 
> 
> -- 
> Pranith

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20161110/d48fe3b4/attachment.sig>