I think that a big problem with this approach is that there is always
going to be another task that should be done and another reason to hold
the core release by just a few more days.
I don't really think that we need this level of process around a Wildfly
Core release. I think that we should just be doing these releases fairly
frequently, and if some work misses the release then there is always
another release coming up in the near future.
I think that a JIRA that tracks what is waiting on the next WF core
release is a good idea, as it lets us see what is blocked waiting on the
next release, however I don't think we should be holding up a core
release based on work in the pipeline.
Stuart
David M. Lloyd wrote:
If you are assigned a JIRA for WildFly that requires a change to
WildFly
Core (either a direct fix or a component upgrade), there (obviously)
needs to be a WildFly Core release and upgrade into WildFly proper
before the change can be completed. But because we're all asynchronous
here, coordination is something of a problem.
So, to organize things a bit, I've opened
https://issues.jboss.org/browse/WFLY-3945 for upgrading WildFly Core to
1.0.0.Alpha9.
If you have a WFCORE task or component upgrade that you think should be
finished before the upgrade happens, add the corresponding JIRA as a
dependency to that issue. If a WFLY task is blocked waiting for the
WFCORE upgrade, add that task as a dependent (in other words, add
WFLY-3945 as a dependency to that task; you can do it either way though).
If the list gets too large, we'll have a discussion about splitting the
work between Alpha9 and Alpha10 (or whatever is next).
Keeping the work organized around this issue will remove some of the
confusion around what needs updating and when, and why.