[Gluster-Maintainers] Lock down period merge process

Pranith Kumar Karampuri pkarampu at redhat.com
Wed Oct 3 15:58:54 UTC 2018


On Wed, Oct 3, 2018 at 9:04 PM Shyam Ranganathan <srangana at redhat.com>
wrote:

> 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.
>

Purpose of my responses has been to prevent a lock down because I believe
the existing process of locking down the complete branch doesn't change
behaviors of developers to prevent a lock down. The process seems to
reinforce it. Hence I raised it on this thread, because it is contributing
to it. It doesn't look like the discussion went to a logical end. I still
don't know what are the new actions we are taking to prevent lock down from
happening. What are they?


>
> >
> > --
> > Pranith
>


-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20181003/905c0997/attachment.html>


More information about the maintainers mailing list