On Wed, May 17, 2017 at 7:36 PM Mike Drob <[email protected]> wrote: > David, what do you mean by > > > Hopefully without generating comments that trigger email/watcher > notifications and thus no more dev list traffic. > > How else other than a comment could the system communicate results back to > the user? Or do you mean that whatever runs should post a comment, but > suppress email notification somehow. >
Yes; that. The rationale being that if someone posts a patch, it'll become inevitable that there will be a follow-up bot comment. It's not a big deal though. > I'm not sure that last bit is possible... would have to talk to INFRA > about it maybe. > > > I'm not sure what to make of it... perhaps you can make a specific > proposal. > > Nothing concrete yet, but it's likely a good candidate tool for the job > here. There are already ASF Jenkins jobs to look for JIRA updates on other > projects, download patches, and try to run precommit checks. If this is > something we were interested in, I think it wouldn't be too hard to add > ourselves to the list. I'd much rather use an existing tool than worry > abotu coming up with something myself. > +1 to that last bit especially. No reason to reinvent any wheels here. <snip> > If the state is set automatically, how do we know when to set it? > > Maybe this could be an extra (optional?) step for the committer looking at > the issue? Change to "Patch Available" triggers a run on the most recent > attached patch? > +1 nice idea; seems straight-forward compared to other ideas. I don't think we need to limit this transition to only committers though; even the submitter might do it to demonstrate their patch is ready. Cheers, ~ David -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
