On Mon, Dec 4, 2017 at 8:33 PM, Stuart Douglas <stuart.w.douglas@gmail.com> wrote:On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <brian.stansberry@redhat.com> wrote:Great. :)One thing I think we need to do is figure out how to get custom TCK runs for PR branches. The TCK is a big part of our test coverage, and one way to not "use master as a test bed" is to get a check of a branch on the TCK before we merge it.I know we've gotten TCK runs of ad-hoc branches before, so by "figure out" I mean work out how to make that not overly painful, come to some sort of consensus on when it's worthwhile, etc.I think if we were going to do this it should probably be something reviewers can ask for on specific PR. The TCK uses a *lot* more resources than a standard CI run, so we need to make sure we limit it to cases where it is required.Yes, for sure we wouldn't want to do this broadly; submitters or reviewers should ask.I had in mind a fairly limited set of scenarios. Things like major/minor version bumps of the big EE components, or some large scale change with fairly clear TCK implications where we'd be reluctant to undo the change if it caused a problem. *Perhaps* core upgrades, as those somewhat amount to the latter. And then late in the cycle some last minute fixes where we sometimes ask for a custom run anyway.Doing custom runs doesn't buy much for small changes where if they fail TCK after merge we just revert them or we can spend a few days sorting the problem without stressing out.StuartOn Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano <asoldano@redhat.com> wrote:______________________________AlessioThere you go... PR updated to consume the same api jar now released as final.CheersOn Fri, Dec 1, 2017 at 3:30 PM, David Lloyd <david.lloyd@redhat.com> wrote:On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano <asoldano@redhat.com> wrote:
> As suggested by Brian, I'd like to draw attention to the discussion on
> https://github.com/wildfly/wildfly/pull/10604 .
> The PR is an upgrade of the webservices stack, including JBossWS, Apache
> CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8 and
> better JDK 9 compatibility.
> Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
> stalled since 20 days; the new spec is released as an alpha (as it's been
> tested within JBossWS only) and that does not satisfy a rule that requires
> any artifact being pulled to be Final.
> We're talking about a spec jar, we could simply re-tag that as Final,
> chances are we won't need changes any time soon there anyway, but as Tomaz
> pointed out, in principle that would be dishonest.
My opinion is that you should go ahead and make a .Final tag. In the
(unlikely?) event that the spec has to be modified for some reason, I
think you could make a 1.0.1.Final tag and call it a "bug fix".
The alternative is to simply wait. I don't think there is any middle position.
> While I see the point in requiring that only sufficiently stable upgrades
> are applied to the codebase, I'm wondering whether, maybe, we're going a bit
> too far with the rules. Brian wrote on this topic: "how to determine that
> something is good enough to go in without using master as a test bed" ?
I don't think we are; I agree with the policy as it stands. If you
look at it in terms of being able to release at any time, then it
follows that everything _must_ be stable.
--
- DML
_________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev --Brian StansberryManager, Senior Principal Software EngineerRed Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev --Brian StansberryManager, Senior Principal Software EngineerRed Hat