> On Jan 11, 2018, at 11:54 AM, Scott Kruger <[email protected]> wrote: > > > > On 1/11/18 10:40 AM, Patrick Sanan wrote: >> One idea is to impose a stricter guideline that things on the bitbucket PR >> page are things that everyone is actively trying to merge. That way, >> maintainers can just look at the bottom of the list to see what's lagging, >> instead of having to to work up the list and try to remember which of the >> PRs are WIP or proposals or experiments or even abandoned ideas. >> This probably requires an itchier trigger finger on declining PRs which need >> substantial work. >> A related point is that (as happened with the last PR I made), if a big edit >> is performed after the original PR is made or even approved, then it's not >> always clear "whose court" the PR is in. Maybe it's better to just make a >> new PR in this situation. I'm not sure if bitbucket allows you to decline >> your own PR (I fear not) - that would make this easier. > > You can. > > > > My own suggest is to hook bin/maint/exampleslog.py up to the > nightly runs such that the output is on the main testing > page and even, perhaps, an automated email to the people > who are "responsible". I am unclear how the nightly > workflow works -- if there is a description somewhere, I > can try hooking it up myself.
In theory the nightly builds send out email to each particular person reasonable for a particular failure (based on git commits). For some reason this is pretty fragile and the email does not get sent at all or to the appropriate person as much as it should. > > The goal is to distribute the responsibility for fixing > errors in master/next testing, and to make it easier to > see what the problems are (without parsing two dozen log > files). > > Scott > > > > -- > Tech-X Corporation [email protected] > 5621 Arapahoe Ave, Suite A Phone: (720) 974-1841 > Boulder, CO 80303 Fax: (303) 448-7756
