On Wed, Oct 3, 2018 at 7:02 PM Shyam Ranganathan <[email protected]> wrote:
> On 10/03/2018 05:36 AM, Pranith Kumar Karampuri wrote: > > > > > > On Thu, Sep 27, 2018 at 8:18 PM Shyam Ranganathan <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 09/27/2018 10:05 AM, Atin Mukherjee wrote: > > > Now does this mean we block commit rights for component Y > till > > > we have the root cause? > > > > > > > > > It was a way of making it someone's priority. If you have > another > > > way to make it someone's priority that is better than this, > please > > > suggest and we can have a discussion around it and agree on it > > :-). > > > > > > > > > This is what I can think of: > > > > > > 1. Component peers/maintainers take a first triage of the test > > failure. > > > Do the initial debugging and (a) point to the component which needs > > > further debugging or (b) seek for help at gluster-devel ML for > > > additional insight for identifying the problem and narrowing down > to a > > > component. > > > 2. If it’s (1 a) then we already know the component and the owner. > If > > > it’s (2 b) at this juncture, it’s all maintainers responsibility to > > > ensure the email is well understood and based on the available > details > > > the ownership is picked up by respective maintainers. It might be > also > > > needed that multiple maintainers might have to be involved and > this is > > > why I focus on this as a group effort than individual one. > > > > In my thinking, acting as a group here is better than making it a > > sub-groups/individuals responsibility. Which has been put forth by > Atin > > (IMO) well. Thus, keep the merge rights out for all (of course some > > still need to have it), and get the situation addressed is better. > > > > > > In my experience, it has been rather difficult for developers without > > domain expertise to solve the problem (at least on the components I am > > maintaining), so the reality is that not everyone may be able to solve > > the issues on all the components where the problem is observed. May be > > you mean we need more participation when you say we need to act as a > > group, so with that assumption one way to make that happen is to change > > the workflow around 'recheck centos'. In my thinking following the tools > > shouldn't lead to less participation on gluster-devel where developers > > can just do recheck-centos until the test passes and be done. So maybe > > tooling should encourage participation. Maybe something like 'recheck > > centos <link-to-mail-where-they-reported-it-on-gluster-devel>' This is > > just an idea, thoughts are welcome. > > I agree, any recheck should have enough reason behind it to state why > the recheck is being attempted, and what the failures were, which are > deemed spurious or otherwise to require a recheck. > > The manner of enforcing the same is not present yet, and is possibly an > orthogonal discussion to the one here. > > The recheck stringency (and I would add even the retry a test if it > fails once should be removed), will aid in getting to less frequent > breakage in nightly, as more effort is put into correcting the tests or > fixing the code around the same. > > 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. > > > > > > > > _______________________________________________ > > maintainers mailing list > > [email protected] <mailto:[email protected]> > > https://lists.gluster.org/mailman/listinfo/maintainers > > > > > > > > -- > > Pranith > -- Pranith
_______________________________________________ maintainers mailing list [email protected] https://lists.gluster.org/mailman/listinfo/maintainers
