[wildfly-dev] Notifications / Plans Around Upcoming WildFly Core Tags

[Darran Lofthouse]

On Thu, 21 Jun 2018 at 10:43 Jeff Mesnil <jmesnil at redhat.com> wrote:

> Hi Darran,
>
> > On 21 Jun 2018, at 11:15, Darran Lofthouse <darran.lofthouse at 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180621/72e93d9e/attachment.html