<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
The tool is not WildFly specific, so it should be able to run on any
project.<br>
<br>
Carlo<br>
<br>
<div class="moz-cite-prefix">On 03-09-19 11:01, Darran Lofthouse
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMxVf4M3g2cu8sEa7XsLvo8xeTmD8PWAyZXFtQ+b2h1eSHK+Hw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">thofman@redhat.com</a> <br>
> <mailto:<a href="mailto:thofman@redhat.com"
target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">wildfly-dev@lists.jboss.org</a>
<mailto:<a href="mailto:wildfly-dev@lists.jboss.org"
target="_blank" moz-do-not-send="true">wildfly-dev@lists.jboss.org</a>><br>
> <a
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">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"
moz-do-not-send="true">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br>
</body>
</html>