Hi Darran,
> On 21 Jun 2018, at 11:15, Darran Lofthouse <darran.lofthouse@redhat.com> wrote:
> Would it be possible to try and get some notifications or routine around the WildFly Core tags so that teams that feed into WildFly Core can coordinate around these?
I have been working towards that goal.
The idea is to have time-boxed releases of WildFly Core (either every 2 or 3 weeks) that are integrated in WildFly codebase.
I’m still figuring out the automation of that process[1] so that doing core releases is less time consuming (hence the Alpha2 to check that the automation is fine)
That sounds great, we have a number of engineers working concurrently on security - if we know where the timeboxing of core is going to hit we can also define our own timebox.
I am working on a document that will give all interested users (and component leads) the information about the planned schedule for WildFly Core.
I also plan to send reminders to wildfly-dev before each important releases (Beta, CR, Final).
These releases will be driven to some extent by WildFly own release schedule and may be in addition to the predictable time-boxed releases
Regarding the coordination of merging PRs, I’ll need some help from the PR authors. If you think several PRs needs to be merged within a single Core release, please make it clear in the PR description.
In that case, we’ll hold until all PRs are ready-to-be-merged and do that in a single step.
For PRs that adds new features, we have some other external requirements (documentation, QE approval) that
may delay the merge. This has to be taken into account if several RFE PR must be delivered within a single
Core release.
Yeah this is the issue I am also trying to work with here, but I also have changes going into Elytron that I can not merge until I know the complete chain has passed otherwise even the component upgrade will not be mergable. Where we have a set mergable PRs as a single until once all code review. QE review etc.. is complete I wonder if it will be easier for me to combine the component upgrade and individual PRs into one PR so we can test it as a single unit. Some of the core PRs will depend on the component update anyway and then I may be able to use the staging repo testing we talked about previously.
@darran, does that address your concern?
jeff
[1] https://github.com/jmesnil/wildfly-core-release/wiki/WildFly-Core-Release-Process
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/