[Gluster-Maintainers] Lock down period merge process

[Pranith Kumar Karampuri]

On Wed, Oct 3, 2018 at 9:28 PM Pranith Kumar Karampuri <pkarampu at redhat.com>
wrote:

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

So far the responses from Atin/Nigel/Shyam have been helpful in shaping my
understanding of the problem and I documented an automated way to solve
this problem at https://bugzilla.redhat.com/show_bug.cgi?id=1635826


>
>
>>
>> >
>> > --
>> > Pranith
>>
>
>
> --
> Pranith
>


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