[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