11:15 a.m.
Hello,
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?
The WildFly Core tags are the only way we can get our code changes into
WildFly. We have a few in progress RFEs that we are trying to coordinate
merging and tagging in conjunction with the remainder of the process. At
the same time I see Alpha2 has just been tagged - had I known there was an
upcoming Alpha I may have tried to set our dates around it to hit it. Even
if we don't have RFEs ready to merge if I know there is an imminent tag, if
we have a number of bug fixes merged to our repo I may create a new tag so
we can get our fixes into WildFly.
Regards,
Darran Lofthouse.
11:42 a.m.
Hi Darran,
On 21 Jun 2018, at 11:15, Darran Lofthouse
<darran.lofthouse(a)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)
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.
@darran, does that address your concern?
jeff
[1] https://github.com/jmesnil/wildfly-core-release/wiki/WildFly-Core-Release...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
11:53 a.m.
On Thu, 21 Jun 2018 at 10:43 Jeff Mesnil <jmesnil(a)redhat.com> wrote:
Hi Darran,
> On 21 Jun 2018, at 11:15, Darran Lofthouse <darran.lofthouse(a)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...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
2387
days inactive
2387
days old
2 comments
2 participants
participants (2)
-
Darran Lofthouse -
Jeff Mesnil