1:45 p.m.
On Tue, Sep 3, 2019 at 3:54 AM Tomas Hofman <thofman(a)redhat.com> wrote:
On 02/09/2019 17:55, Brian Stansberry wrote:
> Hi Tomas,
>
> 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.
That's a good idea, we could definitely start with an email report. Would
give
us chance to get the configuration in shape without cluttering the PR
queue. I
will post it.
Thanks for that!
I was thinking about what is the most easily consumable form to
deliver
this.
If we do manual review first, than perhaps single large PRs is better than
separate PRs for each upgrade, to minimize CI burden and generate less
noise
for PR reviewers.
Looking at the first report I think we've got a way to go before we get to
PRs. :)
In general I don't think PRs with a lot of upgrades will be useful, as they
are not actionable unless 100% of the upgrades are valid. OTOH I can see
how having 20 PRs for different CXF components would be annoying and would
drown CI for some hours.
Something slick might be for the tool to understand the version property
strings and aggregate based on that.
I see three categories of upgrades:
1) Projects that the main WF devs control, so we're doing the release and
the upgrade. Or ones where the WF dev is heavily involved so even if they
don't release they know about the release.
2) Other projects that are only direct deps of the WF/WF Core code bases.
3) Transitive deps.
Posting an automated PR is most useful for the #2 case. For the #3 case
we'd need to go to the WF dev responsible for integrating whatever
project(s) is pulling it in, say RESTEasy or CXF and get them to confirm
that the upgrade is ok.
>
> 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.
Agree.
>
> 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.
I also think long interval is better. Even maybe rather than running on
regular
intervals it could be triggered manually by RC after every EAP release or
during some part of the release cycle.
Tomas
>
> Best regards,
> Brian
>
>
> On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <thofman(a)redhat.com
> <mailto:thofman@redhat.com>> wrote:
>
> Hello,
>
> would the Wildfly team be interested in (or opposed to) receiving
component
> upgrade PRs, which would be created automatically when a new
component version
> is released? (I'm talking about new micro/SP versions, depending on
the
> component, i.e. version that could be reasonably expected to be
suitable for
> consumption, without issues like breaking API changes etc.)
>
> I'm working on a tool [1], which is able to provide these PRs.
>
> The tool scans given project for dependencies, and then looks at
what versions
> of those dependencies are available in Maven Central and possibly
other
> repositories. I can configure rules for each dependency, that
specify what
> versions should be considered viable for upgrading (e.g. for
> "org.picketlink:*"
> we would only offer new "SP" builds in the same micro, for most of
the other
> dependencies we would only offer new micros, and some artifacts
would perhaps
> be blacklisted). Example of this configuration is here [2].
>
> Advantages that I believe could be gained from this:
>
> * It would bring us an advantage of having new component micros
tested soon in
> Wildfly, and therefore having more confidence when we need to do the
same
> upgrades in EAP.
>
> * It would also help in preventing EAP running ahead of Wildfly in
component
> versions, which happens occasionally. EAP release coordinator
usually spots
> this problem and creates missing PR in Wildfly, but it's a manual
check and
> therefore a small risk remains.
>
> * It would ensure Wildfly is consuming latest component fixes.
>
> You can review PRs generated last week in my fork of Wildfly [3].
>
> It's a work in progress, I expect the tool and it's configuration
would evolve
> according to experiences we would get from using it...
>
> What do you think?
>
> [1] https://github.com/TomasHofman/maven-dependency-updater/
> [2]
>
https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil...
> [3] https://github.com/TomasHofman/wildfly/pulls
>
> --
> Tomas Hofman
> Software Engineer, JBoss SET
> Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat