[Gluster-Maintainers] Lock down period merge process
Shyam Ranganathan
srangana at redhat.com
Wed Oct 3 15:34:03 UTC 2018
On 10/03/2018 11:32 AM, Pranith Kumar Karampuri wrote:
>
>
> On Wed, Oct 3, 2018 at 8:50 PM Shyam Ranganathan <srangana at redhat.com
> <mailto:srangana at redhat.com>> wrote:
>
> On 10/03/2018 11:16 AM, Pranith Kumar Karampuri wrote:
> > Once we have distributed tests running, such that overall
> regression
> > time is reduced, we can possibly tackle removing retries for
> tests, and
> > then getting to a more stringent recheck process/tooling. The
> reason
> > being, we now run to completion and that takes quite a bit of
> time, so
> > at this juncture removing retry is not practical, but we
> should get
> > there (soon?).
> >
> >
> > I agree with you about removing retry. I didn't understand why recheck
> > nudging developers has to be post-poned till distributed regression
> > tests comes into picture. My thinking is that it is more important to
> > have it when tests take longer.
>
> Above is only retry specific, not recheck specific, as in "we can
> possibly tackle removing retries for tests"
>
> But also reiterating this is orthogonal to the lock down needs discussed
> here.
>
>
> As per my understanding the reason why lock down is happening because no
> one makes any noise about the failures that they are facing as and when
> it happens, and it doesn't get conveyed on gluster-devel. So is there
> any reason why you think it is orthogonal considering it is contributing
> directly to the problem that we are discussing on this thread?
Taking steps to ensure quality is maintained is going to reduce
instances of lock down, hence orthogonal.
>
> --
> Pranith
More information about the maintainers
mailing list