<div dir="ltr">An e-mail report would be really good, component leads may want to apply the update to their own projects first to double check.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 3, 2019 at 9:55 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"><br>
<br>
On 02/09/2019 17:55, Brian Stansberry wrote:<br>
> Hi Tomas,<br>
> <br>
> Can this generate emails to this list instead of PRs? Processing PRs is <br>
> expensive, both in terms of burden on our somewhat overburdened CI and in terms <br>
> of forcing mergers to deal with a PR queue. I'm not opposed to ending up <br>
> getting PRs but I'd like to see any system producing acceptable inputs before <br>
> we let it at the PR queue.<br>
<br>
That's a good idea, we could definitely start with an email report. Would give <br>
us chance to get the configuration in shape without cluttering the PR queue. I <br>
will post it.<br>
<br>
I was thinking about what is the most easily consumable form to deliver this. <br>
If we do manual review first, than perhaps single large PRs is better than <br>
separate PRs for each upgrade, to minimize CI burden and generate less noise <br>
for PR reviewers.<br>
<br>
> <br>
> I'm glad to see the discussion of configurable rules, as that's quite <br>
> important. I wouldn't like to see anything proposed except micro version <br>
> updates or less than micro. No minors. If that's inappropriate for some <br>
> component then that could be adjusted for that one, but the default should be <br>
> micros only.<br>
<br>
Agree.<br>
<br>
> <br>
> I also think some sort of time delay is appropriate, probably at least a week. <br>
> Having an automated system race with the humans working on WildFly would be <br>
> annoying. Github already notifies us of possible upgrades to components with CVEs.<br>
<br>
I also think long interval is better. Even maybe rather than running on regular <br>
intervals it could be triggered manually by RC after every EAP release or <br>
during some part of the release cycle.<br>
<br>
<br>
Tomas<br>
<br>
> <br>
> Best regards,<br>
> Brian<br>
> <br>
> <br>
> On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <<a href="mailto:thofman@redhat.com" target="_blank">thofman@redhat.com</a> <br>
> <mailto:<a href="mailto:thofman@redhat.com" target="_blank">thofman@redhat.com</a>>> wrote:<br>
> <br>
> 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<br>
> "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> <mailto:<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>
> <br>
> <br>
> <br>
> -- <br>
> Brian Stansberry<br>
> Manager, Senior Principal Software Engineer<br>
> Red Hat<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></blockquote></div>