<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 21 Jun 2018 at 10:43 Jeff Mesnil <<a href="mailto:jmesnil@redhat.com">jmesnil@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Darran,<br>
<br>
> On 21 Jun 2018, at 11:15, Darran Lofthouse <<a href="mailto:darran.lofthouse@redhat.com" target="_blank">darran.lofthouse@redhat.com</a>> wrote:<br>
> 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?<br>
<br>
I have been working towards that goal.<br>
The idea is to have time-boxed releases of WildFly Core (either every 2 or 3 weeks) that are integrated in WildFly codebase.<br>
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)<br></blockquote><div><br></div><div>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.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am working on a document that will give all interested users (and component leads) the information about the planned schedule for WildFly Core.<br>
<br>
I also plan to send reminders to wildfly-dev before each important releases (Beta, CR, Final).<br>
These releases will be driven to some extent by WildFly own release schedule and may be in addition to the predictable time-boxed releases<br>
<br>
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.<br>
In that case, we’ll hold until all PRs are ready-to-be-merged and do that in a single step.<br>
For PRs that adds new features, we have some other external requirements (documentation, QE approval) that <br>
may delay the merge. This has to be taken into account if several RFE PR must be delivered within a single<br>
Core release.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
@darran, does that address your concern?<br>
<br>
jeff<br>
<br>
<br>
[1] <a href="https://github.com/jmesnil/wildfly-core-release/wiki/WildFly-Core-Release-Process" rel="noreferrer" target="_blank">https://github.com/jmesnil/wildfly-core-release/wiki/WildFly-Core-Release-Process</a><br>
<br>
-- <br>
Jeff Mesnil<br>
JBoss, a division of Red Hat<br>
<a href="http://jmesnil.net/" rel="noreferrer" target="_blank">http://jmesnil.net/</a><br>
<br>
</blockquote></div></div>