Re: [Gluster-devel] [Gluster-Maintainers] Master branch lock down for stabilization (unlocking the same)

[Shyam Ranganathan]

On 08/14/2018 12:51 AM, Pranith Kumar Karampuri wrote:
> 
> 
> On Mon, Aug 13, 2018 at 10:55 PM Shyam Ranganathan  > wrote:
> 
> On 08/13/2018 02:20 AM, Pranith Kumar Karampuri wrote:
> >     - At the end of 2 weeks, reassess master and nightly test
> status, and
> >     see if we need another drive towards stabilizing master by
> locking down
> >     the same and focusing only on test and code stability around
> the same.
> >
> >
> > When will there be a discussion about coming up with guidelines to
> > prevent lock down in future?
> 
> A thread for the same is started in the maintainers list.
> 
> 
> Could you point me to the thread please? I am only finding a thread with
> subject "Lock down period merge process"

That is the one I am talking about, where you already raised the above
point (if I recollect right).

> 
> >
> > I think it is better to lock-down specific components by removing
> commit
> > access for the respective owners for those components when a test in a
> > particular component starts to fail.
> 
> Also I suggest we move this to the maintainers thread, to keep the noise
> levels across lists in check.
> 
> Thanks,
> Shyam
> 
> 
> 
> -- 
> Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Master branch lock down for stabilization (unlocking the same)

[Pranith Kumar Karampuri]

On Mon, Aug 13, 2018 at 10:55 PM Shyam Ranganathan 
wrote:

> On 08/13/2018 02:20 AM, Pranith Kumar Karampuri wrote:
> > - At the end of 2 weeks, reassess master and nightly test status, and
> > see if we need another drive towards stabilizing master by locking
> down
> > the same and focusing only on test and code stability around the
> same.
> >
> >
> > When will there be a discussion about coming up with guidelines to
> > prevent lock down in future?
>
> A thread for the same is started in the maintainers list.
>

Could you point me to the thread please? I am only finding a thread with
subject "Lock down period merge process"

>
> > I think it is better to lock-down specific components by removing commit
> > access for the respective owners for those components when a test in a
> > particular component starts to fail.
>
> Also I suggest we move this to the maintainers thread, to keep the noise
> levels across lists in check.
>
> Thanks,
> Shyam
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Master branch lock down for stabilization (unlocking the same)

[Shyam Ranganathan]

On 08/13/2018 02:20 AM, Pranith Kumar Karampuri wrote:
> - At the end of 2 weeks, reassess master and nightly test status, and
> see if we need another drive towards stabilizing master by locking down
> the same and focusing only on test and code stability around the same.
> 
> 
> When will there be a discussion about coming up with guidelines to
> prevent lock down in future?

A thread for the same is started in the maintainers list.

> 
> I think it is better to lock-down specific components by removing commit
> access for the respective owners for those components when a test in a
> particular component starts to fail.

Also I suggest we move this to the maintainers thread, to keep the noise
levels across lists in check.

Thanks,
Shyam
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Master branch lock down for stabilization (unlocking the same)

[Pranith Kumar Karampuri]

On Mon, Aug 13, 2018 at 6:05 AM Shyam Ranganathan 
wrote:

> Hi,
>
> So we have had master locked down for a week to ensure we only get fixes
> for failing tests in order to stabilize the code base, partly for
> release-5 branching as well.
>
> As of this weekend, we (Atin and myself) have been looking at the
> pass/fail rates on the tests, and whether we are discovering newer
> failures of more of the same.
>
> Our runs with patch sets 10->11->12 is looking better than where we
> started, and we have a list of tests that we need to still fix.
>
> But there are other issues and fixes that are needed in the code that
> are lagging behind due to the lock down. The plan going forward is as
> follows,
>
> - Unlock master, and ensure that we do not start seeing newer failures
> as we merge other patches in, if so raise them on the lists and as bugs
> and let's work towards ensuring these are addressed. *Maintainers*
> please pay special attention when merging patches.
>
> - Address the current pending set of tests that have been identified as
> failing, over the course of the next 2 weeks. *Contributors* continue
> the focus here, so that we do not have to end up with another drive
> towards the same in 2 weeks.
>
> - At the end of 2 weeks, reassess master and nightly test status, and
> see if we need another drive towards stabilizing master by locking down
> the same and focusing only on test and code stability around the same.
>

When will there be a discussion about coming up with guidelines to prevent
lock down in future?

I think it is better to lock-down specific components by removing commit
access for the respective owners for those components when a test in a
particular component starts to fail.


>
> Atin and Shyam
> ___
> maintainers mailing list
> maintain...@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel