[jbosstools-dev] ACTION REQUIRED: making sure commits are in master, help INSIDE!!!

Rob Stryker rob.stryker at redhat.com
Wed Apr 20 14:02:05 EDT 2016


On 04/20/2016 11:35 AM, Martin Malina wrote:
>
>
> You see, there is nothing different - apart from checksums, it's the 
> bundle version. But that is outside of the changes - that is just 
> there for context, not part of the commits. Any idea why the patch-id 
> is different?

The patch-id includes context. It ignores whitespace. So yeah, different 
context will lead to a false-positive. There's no really efficient way 
to get rid of these without writing your own utility i guess ;)

>
> -Martin
>
>> On 18. 4. 2016, at 23:09, Rob Stryker <rob.stryker at redhat.com 
>> <mailto:rob.stryker at redhat.com>> wrote:
>>
>> On 04/18/2016 05:05 AM, Max Rydahl Andersen wrote:
>>>
>>> great initiative - may I suggest you do a PR for your script and put 
>>> it at 
>>> https://github.com/jbosstools/jbosstools-build-ci/tree/jbosstools-4.3.x/util 
>>> where we have other such utilities.
>>>
>>> Also, might be easier if you put the run info into jira since the 
>>> output is quite hard to read/use here from mail.
>>>
>>> btw. it looks like this tool actually is very good at finding the 
>>> false positives - i.e. change in pom.xml where it just changes 
>>> version seem to be something you could filter out somehow ?
>>>
>>
>>
>> First, I disagree that these are false-positives ;) These are commits 
>> that are in maintenance that aren't in master.
>>
>> And, in all honesty, I think it'd be a mistake to simply filter them 
>> out. I think it's much better to list the false positive and let the 
>> component owner use his judgment whether the patch needs further 
>> inspection or not. Such simple version-changes will be very very easy 
>> for a human to spot as irrelevant to master.  This may cause the 
>> repository owner to waste 2-3 seconds for each commit, but it 
>> guarantees that every possible unmatched commit is found.
>>
>> I think this is much better and safer than possibly adding some logic 
>> to filter out version changes and later discover that the logic was 
>> wrong and so it was hiding legitimately missing commits from being 
>> shown. Also, since we're not inspecting the patches at all, but 
>> rather comparing patch-id's, it would make the script much much more 
>> complicated.
>>
>> /Il meglio è nemico del bene  -  Perfect is the enemy of good
>>
>> /https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
>> /
>> /
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org <mailto:jbosstools-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160420/5514220d/attachment-0001.html 


More information about the jbosstools-dev mailing list