<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi Tomas,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Can this generate emails to this list instead of PRs? Processing PRs is expensive, both in terms of burden on our somewhat overburdened CI and in terms of forcing mergers to deal with a PR queue. I'm not opposed to ending up getting PRs but I'd like to see any system producing acceptable inputs before we let it at the PR queue.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I'm glad to see the discussion of configurable rules, as that's quite important. I wouldn't like to see anything proposed except micro version updates or less than micro. No minors. If that's inappropriate for some component then that could be adjusted for that one, but the default should be micros only.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I also think some sort of time delay is appropriate, probably at least a week. Having an automated system race with the humans working on WildFly would be annoying. Github already notifies us of possible upgrades to components with CVEs.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Best regards,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Brian</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <<a href="mailto:thofman@redhat.com">thofman@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
would the Wildfly team be interested in (or opposed to) receiving component <br>
upgrade PRs, which would be created automatically when a new component version <br>
is released? (I'm talking about new micro/SP versions, depending on the <br>
component, i.e. version that could be reasonably expected to be suitable for <br>
consumption, without issues like breaking API changes etc.)<br>
<br>
I'm working on a tool [1], which is able to provide these PRs.<br>
<br>
The tool scans given project for dependencies, and then looks at what versions <br>
of those dependencies are available in Maven Central and possibly other <br>
repositories. I can configure rules for each dependency, that specify what <br>
versions should be considered viable for upgrading (e.g. for "org.picketlink:*" <br>
we would only offer new "SP" builds in the same micro, for most of the other <br>
dependencies we would only offer new micros, and some artifacts would perhaps <br>
be blacklisted). Example of this configuration is here [2].<br>
<br>
Advantages that I believe could be gained from this:<br>
<br>
* It would bring us an advantage of having new component micros tested soon in <br>
Wildfly, and therefore having more confidence when we need to do the same <br>
upgrades in EAP.<br>
<br>
* It would also help in preventing EAP running ahead of Wildfly in component <br>
versions, which happens occasionally. EAP release coordinator usually spots <br>
this problem and creates missing PR in Wildfly, but it's a manual check and <br>
therefore a small risk remains.<br>
<br>
* It would ensure Wildfly is consuming latest component fixes.<br>
<br>
You can review PRs generated last week in my fork of Wildfly [3].<br>
<br>
It's a work in progress, I expect the tool and it's configuration would evolve <br>
according to experiences we would get from using it...<br>
<br>
What do you think?<br>
<br>
[1] <a href="https://github.com/TomasHofman/maven-dependency-updater/" rel="noreferrer" target="_blank">https://github.com/TomasHofman/maven-dependency-updater/</a><br>
[2] <br>
<a href="https://github.com/jboss-set/dependency-alignment-configs/blob/master/wildfly-18-minimal.json#L44" rel="noreferrer" target="_blank">https://github.com/jboss-set/dependency-alignment-configs/blob/master/wildfly-18-minimal.json#L44</a><br>
[3] <a href="https://github.com/TomasHofman/wildfly/pulls" rel="noreferrer" target="_blank">https://github.com/TomasHofman/wildfly/pulls</a><br>
<br>
-- <br>
Tomas Hofman<br>
Software Engineer, JBoss SET<br>
Red Hat<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>