Something like that would be an improvement. I think my frustration stems from a sense the burden isn't equitably shared. It also relates to what I do as a RM which isn't policy per se. First, I run the unit suite several times in a loop. This is scripted, but it takes time to complete and review the results, and investigating failures and filing issues takes time too. Then I will do the same basic checks a voter will take. Then I might run LTT or ITBLL, which is hands on and takes more time. So far the volunteer time spent seems perfectly reasonable and not onerous. This is not my complaint.
When there is a veto, is the expectation the RM will follow up and fix the problem? If it is a flaky test, that cannot be locally reproduced, this is an additional mandate that could be costly in terms of time. As a voter, when you cast a veto because of a compatibility issue have you really considered if it might be allowed - our guidelines are just guidelines, and are fuzzy by nature? Because as RM I looked at that report too and thought it ambiguous enough to continue. The committer allowed it implicitly by the commit. In some cases as RM I have reopened JIRAs for compatibility problems. The recent 1.4.10RC0 is case in point. After back and forth with the committer an incompatible change of low severity was allowed on a Public interface. The voter should take this kind of action. At the least we should have a JIRA reopened or filed for discussion of the problem. What should not be considered valid, in my opinion, is a pedantic veto that only mentions the compatibility report as reason. This is not helpful. Guidelines, and fuzzy, if you recall. In general for test or compatibility issues, is the expectation the RM will fix it? That is a big assumption about the RM's personal circumstances, wouldn't you think? Or interest in volunteering? Volunteer resources are precious. We need to be mindful of the tradeoff here. It also applies in code review. I think generally we strike the right balance between quality assurance and considerations to volunteer time, but in some recent RC votes I have gotten the impression not. No JIRAs for veto reasons. No proactive debug of unit test failure. No patches. Hence a sense the burden for maintaining the code isn't as equitably shared as it should be. A policy as suggested, like a consensus that vetos should only be cast if the issue deserves a JIRA with Critical would certainly be one way to shift the balance. I don't think something like that is necessary. Smaller steps as simple as giving the RM the courtesy of filing JIRAs that explain the veto and describe steps to fix would be enough. This would shift the burden for test failures onto the observers, who are in the best position to understand the failure because they are the ones seeing it. It also shifts burden on disagreements over compatibility report results. A veto for a compatibility issue is a priori a disagreement between the voter and the committer, and the voter and the RM. Proactive effort and remedy on the part of the voter should be implied by this. Thank you for your consideration. For your consideration. On Thu, May 9, 2019 at 9:52 AM Artem Ervits <[email protected]> wrote: > should -1 only apply with a valid critical Jira in hand? > > On Thu, May 9, 2019 at 12:41 PM Andrew Purtell <[email protected]> > wrote: > > > .. a code base to the RM role. I don't believe vetos for RCs for flaky > > tests should be considered valid reason to vote -1. I think we may be > > erring toward excessively maximal interpretation of compatibility > > guidelines in some cases. At any rate, where does the responsibility lie > > for fixing the issues? And do voters consider the personal cost to the RM > > in terms of time and attention in rolling the RC when deciding to vote > -1? > > The -1 vote has a cost. It requires the RM to restart the RC. My > impression > > is this isn't a consideration. > > > > > > On Thu, May 9, 2019 at 9:37 AM Andrew Purtell <[email protected]> > > wrote: > > > > > /cc private@ > > > > > > I believe you are pushing your collective burden as a group of > committers > > > sharing responsiblity to > > > > > > On Thu, May 9, 2019 at 9:33 AM Andrew Purtell < > [email protected]> > > > wrote: > > > > > >> My experience with the last four RC attempts I have made has been > just a > > >> constant stream of vetos for flaky tests which I can't reproduce (at > > least > > >> not with the usual 10 iterations of the suite) and possibly pedantic > > >> compatability report interpretations with no patches to help and in > some > > >> cases not even JIRAs filed to follow up on specifying the complaint. > > Life > > >> is too short to waste time and effort like this. > > >> > > >> > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > > - A23, Crosstalk > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > > > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
