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. 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. Tomas, I think you're asking for two opposed things here. If we encourage people to submit lots of patches, some of which may not be ready for automated verification, then it seems like we must have a step for them to take to indicate that a specific patch is "ready" This could be a submitter changing state to "Patch Available" or could be a naming convention (PATCH-XXX v PATCH-XXX-WIP?) or could be something else that I haven't imagined. I'm totally in agreement though that if somebody posts a knowingly incomplete patch there's very little benefit from getting scolded by an automated tool (and potentially even some harm). 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? Mike On Wed, May 17, 2017 at 12:28 PM, Tomás Fernández Löbbe < [email protected]> wrote: > > Additionally, we could use that to start running precommit checks on > Jenkins whenever a new patch is put up. > This is a good idea, but we don't want to do this for every patch I'd say. > We encourage people to submit patches early, probably with failing tests > and nocommits. We probably want an explicit trigger. > > Patch Available JIRA state > In your mind, who is setting this state? automatically or by the user? I > fear this could just become an extra step that could complicate the process > > See Apache Yetus for how this might work > Didn't know it, it looks like the right tool. +1 > > > > On Sat, May 13, 2017 at 8:06 PM, David Smiley <[email protected]> > wrote: > >> Thanks for researching the state of our JIRA issues and summarizing the >> situation for us. >> >> > Patch Available JIRA state >> >> +1 >> >> > We should also consider running unit tests as part of the process. >> >> +1 That'd be cool! Hopefully without generating comments that trigger >> email/watcher notifications and thus no more dev list traffic. >> >> > Apache Yetus >> >> I'm not sure what to make of it... perhaps you can make a specific >> proposal. >> >> ~ David >> >> On Fri, May 12, 2017 at 12:31 PM Hrishikesh Gadre <[email protected]> >> wrote: >> >>> >>For current patches, I think we could really benefit from a Patch >>> Available JIRA state. It would be a bright big flag for committers, instead >>> of making contributors have to hound us periodically to look. Additionally, >>> we could use that to start running precommit checks on Jenkins whenever a >>> new patch is put up. See Apache Yetus for how this might work. >>> >>> +1. We should also consider running unit tests as part of the process. >>> >>> >>> On Thu, May 11, 2017 at 1:54 PM, Mike Drob <[email protected]> wrote: >>> >>>> Wanted to follow up on this, since I've been steadily working away at >>>> old JIRA issues when I have some time for them. I think read through 100s >>>> of issues and closed about 20 as either duplicates or already committed, >>>> which is a tiny drop in the ocean of what we have open. In an attempt to >>>> cut the task to a more manageable size, I only looked at Solr issues. >>>> >>>> I'd like to adjust my earlier statement that most of the attachments >>>> are patches. Most of the really old attachments are patches, the mid-age >>>> ones are bug reports (indices, screen captures, logs) and the recent ones >>>> being actively worked are patches again. So, the situation isn't as bad as >>>> I imagined it at first. For a lot of these old issues, there's not much to >>>> be done going forward. I don't expect to have much traction asking >>>> contributors to rebase their patches from 1.x, 3.x or even 4.x onto the >>>> current code line, and without that many of them are just unworkable. >>>> >>>> For current patches, I think we could really benefit from a Patch >>>> Available JIRA state. It would be a bright big flag for committers, instead >>>> of making contributors have to hound us periodically to look. Additionally, >>>> we could use that to start running precommit checks on Jenkins whenever a >>>> new patch is put up. See Apache Yetus for how this might work. >>>> >>>> Is there interest in the community for this path? I'm personally a big >>>> fan of enabling static analysis and always like to explore ways to improve >>>> in that area. >>>> >>>> Mike >>>> >>>> On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <[email protected]> >>>> wrote: >>>> >>>>> On 4/28/2017 9:42 AM, Mike Drob wrote: >>>>> > Thanks for this hint, Alex. >>>>> > >>>>> > I ran the following JQL to get some idea of our current status: >>>>> > project in (lucene, solr) and "Attachment count" > 0 and status >>>>> = Open >>>>> > >>>>> > There were 1500 results. >>>>> > >>>>> > 1500. I couldn't believe it. This is a huge number of patches that >>>>> are >>>>> > out there. >>>>> > >>>>> > I did a spot check, thinking that a lot of these might be bug reports >>>>> > with error logs or screen shots attached, but nope. These are mostly >>>>> > patches. I'm going to try starting with the oldest ones to see if >>>>> they >>>>> > can be rebase, have already been committed, or generally try to >>>>> triage >>>>> > them. Would appreciate any volunteers that want to help. >>>>> >>>>> This doesn't surprise me at all. Many users submit patches for issues >>>>> they encounter, but for one reason or another, no committer action ever >>>>> happens. There are many possible reasons. >>>>> >>>>> 1) The patch has bugs or some other problem that makes it unacceptable. >>>>> 2) When the issue/patch is reviewed, one of these situations exists: >>>>> a) Committers don't think it's worth pursuing. >>>>> b) The code is behaving as designed. >>>>> c) The committer cannot reproduce the problem. >>>>> d) The committer doesn't understand the problem. >>>>> e) The committer doesn't think it's actually a problem. >>>>> f) A workaround exists that is just as effective as the patch. >>>>> 3) Nobody has had time to review the issue/patch. >>>>> >>>>> In some of these situations, the reviewing committer should probably >>>>> close the issue with an appropriate reason ... but issue triage is a >>>>> difficult and unrewarding job. Sometimes it just doesn't happen. >>>>> >>>>> Thanks, >>>>> Shawn >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>> -- >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> http://www.solrenterprisesearchserver.com >> > >
