> This could be a submitter changing state to "Patch Available" or could be
a naming convention
Yes, I was thinking on something along those lines too. I've also seen
tools triggering by specific comments in Jira. Any way is fine with me.
> If the state is set automatically, how do we know when to set it?
I was just trying to understand what you were proposing really. If we use
that as an optional step to trigger the validation it makes sense (although
since it's optional, filtering by this state to find issues with patches
will not give you a complete view)

On Wed, May 17, 2017 at 4:35 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. 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB