Scott Marlow and I just got off a call with Ed and Arjan about the TCK work
needed and the timeframe is again back to Q4. The codename for this release
should be whiplash.
We will see how well that stands up.
On Fri, Apr 28, 2023 at 7:33 AM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
Thanks for the info, Scott.
If it turns out there really is an EE 11 in Q1 and if we wanted to pick it
up, it seems likely enough we could handle it. If it's small, maybe it
would make the April 2024 release, perhaps just in WildFly Preview if we
think whatever we've done needs more bake before appearing standard
WildFly. I think we should always give ourselves a couple weeks leeway on
any release schedule, so that would mean we'd have until the end of April.
Or we just wait for the July 2024 release.
It seems like the main pain point with these platform spec releases with a
time-boxed WildFly is if the spec lands too close to a time box end. That
puts us in a spot where we either have to delay the release or we can't
certify as compatible on spec release day with an alpha/beta, because our
code base is too locked down at that time. It seems like a "deal with it if
it happens" kind of scenario.
TBH, if EE really does start releasing on a much more frequent cadence I
suspect personally I'll feel less motivated to certify on release day. It's
a great thing to do of course but there are many great things to do.
If others feel otherwise that's a reason to reconsider time boxing.
Between EE and MP there might be 4 big spec releases a year; if we wanted
to make certifying on release day a key priority that means predictable
time boxing would not be practical; at best it could be something we do
sometimes.
On Wed, Apr 26, 2023 at 11:03 PM Scott Stark <sstark(a)redhat.com> wrote:
> So in yesterday's EE platform group call there has been pivot back to
> pushing for a Q1 EE11 release even if it contains very little. I complained
> about this and said it made no sense for us to spend time producing such a
> release. Two of the main proponents were not on the call, so there will
> have to be a more confrontational call next week. Bottom line is that is it
> not clear what resources will be marshaled to produce such a release, but
> Ed Burns from MSFT has signed up to co-lead EE11 with Arjan Tijms of
> OmniFish.
>
> On Wed, Apr 26, 2023 at 2:08 PM Brian Stansberry <
> brian.stansberry(a)redhat.com> wrote:
>
>> If there's no further input on this, I want to publish a blog post about
>> this on
wildfly.org this week and mention the post on the wildfly
>> google group, twitter and fosstodon.
>>
>> I'll note that these are all estimates that can change, and specifically
>> that the WF 29 date may shift a couple weeks as we keep an eye on what
>> happens with any MicroProfile release in June. (Thanks for asking about
>> that, Jeff.)
>>
>> Cheers,
>> Brian
>>
>> On Thu, Apr 6, 2023 at 12:20 PM Brian Stansberry <
>> brian.stansberry(a)redhat.com> wrote:
>>
>>> Thanks, Scott. Personally, I think that's for the best.
>>>
>>> I think we *mostly* should not try to adapt a WildFly time-boxed
>>> release schedule to align with expected Jakarta EE or MicroProfile
>>> releases. And we should avoid feature boxing releases for them as well. I
>>> don't think Jakarta EE is at all predictable enough to try and schedule
>>> align. MicroProfile has historically been more predictable, but it's
hard
>>> to align. To align well we'd need to go for 3 releases a year, for
example
>>> late March / late July / late Nov. And then if the MP release was delayed,
>>> or our impl was delayed, it doesn't get in the WF release and the delay
>>> before it gets into the next WF is even longer.
>>>
>>> I said "mostly" above because I think our schedules should be
"roughly"
>>> quarterly. I think it's fine to shift things around by two, maybe three,
>>> weeks if we think that will give us a chance to have a more meaningful
>>> release. So, for example, if we feel that MP is going to consistently do
>>> releases in June and we expect to be able to pick up that release quickly,
>>> maybe we'd schedule the July release for late July instead of mid July.
The
>>> next release then has a shorter dev cycle. That's something we can
foresee
>>> early in a release cycle and if we want such a shift we can adjust the
>>> release schedule that we announce for that release accordingly.
>>>
>>> If a major spec release comes out and for marketing purposes we want to
>>> certify as compatible on its release date we can always produce an alpha or
>>> beta, or even a minor. That's what we did with EE 10.
>>>
>>> EE platform updates are good examples of dev work that may not fit in a
>>> single time box. (Historically MP has been less of a problem.) I hope this
>>> year we can improve our feature delivery processes a lot and move toward a
>>> system where we can efficiently promote features to higher
'maturity'
>>> levels.[1] How exactly that would apply to EE spec updates is unclear to
>>> me, but the EE update use case is a good one to think about as we work on
>>> this stuff this year. In the end though, time-boxing means sometimes dev
>>> work needs to be maintained on a topic branch for a longer period. We've
>>> done that before.
>>>
>>> [1] See Paul Ferraro's
>>>
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
>>> and
https://issues.redhat.com/browse/WFCORE-6221 for one aspect of
>>> this, focused on the management API.
>>>
>>> Best regards,
>>> Brian
>>>
>>> On Thu, Apr 6, 2023 at 9:56 AM Scott Stark <sstark(a)redhat.com> wrote:
>>>
>>>> The earliest EE11 could be out is Q1 2024. I don't see that
happening.
>>>> I would expect something in Q4 2024 at the earliest.
>>>>
>>>>
>>>> On Apr 6, 2023 at 8:50:54 AM, Jeff Mesnil <jmesnil(a)redhat.com>
wrote:
>>>>
>>>>> Thanks Brian for the information.
>>>>>
>>>>> It's great that WildFly goes back to a predictable time-boxed
release
>>>>> schedule.
>>>>>
>>>>> The January/April/July/October looks better, it removes stress
>>>>> to hurry things in September (after summer holiday) and December
(before
>>>>> time off).
>>>>>
>>>>> I was just wondering how new releases of Jakarta EE and MicroProfile
>>>>> could affect the schedule.
>>>>> Would we adapt the schedule for them? Or if we miss some
>>>>> implementation, we will release without them and add them in the
next
>>>>> release?
>>>>>
>>>>> Thanks,
>>>>> jeff
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 3, 2023 at 7:17 PM Brian Stansberry <
>>>>> brian.stansberry(a)redhat.com> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> After spending the last year plus in a feature-boxed release
>>>>>> scheduling mode, I think it would be both good and feasible to
get the
>>>>>> WildFly project back into the roughly time-boxed delivery model
that we
>>>>>> managed pretty successfully starting with WildFly 12. This thread
is to
>>>>>> gather inputs from the WildFly developer community about doing
that over
>>>>>> the next year. After discussing here, my aim is to post our plans
to the
>>>>>> broader WildFly community via a
wildfly.org news post and a
thread
>>>>>> on the wildfly google group.
>>>>>>
>>>>>> One question is what length of time boxes we would shoot for.
>>>>>>
>>>>>> Personally I thought the roughly quarterly cadence worked well.
It
>>>>>> seemed short enough that we didn't find ourselves regularly
stressing about
>>>>>> getting a particular feature into a particular release because it
would
>>>>>> otherwise have to wait too long. I could imagine trying to go for
a shorter
>>>>>> cycle, but I don't think that's really practical right
now. Optimizing our
>>>>>> delivery processes to make that more practical would be a good
goal for the
>>>>>> next year though.
>>>>>>
>>>>>> If we go back to quarterly releases, the next question is what
that
>>>>>> schedule would look like. If we assume WildFly 28 goes out as
planned[1],
>>>>>> then a quarterly cadence would look like this:
>>>>>>
>>>>>> WildFly 29 Beta - Thur Jun 29
>>>>>> WildFly 29 Final – Thur Jul 13
>>>>>>
>>>>>> WildFly 30 Beta – Thur Sep 28
>>>>>> WildFly 30 Final – Thur Oct 12
>>>>>>
>>>>>> WildFly 31 Beta – Thur Dec 14 [2]
>>>>>> WildFly 31 Final – Thur Jan 11
>>>>>>
>>>>>> WildFly 32 Beta – Thur Mar 28
>>>>>> WildFly 32 Final -- Thur Apr 11
>>>>>>
>>>>>> Those dates are the Thursdays when the release is announced on
and
>>>>>> download links are added to
wildfly.org. We'd want PRs ready
>>>>>> intended for the release to be ready to merge 6 days before that
date, i.e.
>>>>>> the preceding Friday.
>>>>>>
>>>>>> In the past we tried for a March/June/September/December
cadence,
>>>>>> but, besides that fact the April WildFly 28 will become a
starting point,
>>>>>> my sense is January/April/July/October will work better. A lot
of
>>>>>> developers go on holidays in late July and August, which tended
to make
>>>>>> September releases difficult. And then aiming for a mid-December
Final
>>>>>> release was often a problem, because any delay would push the
release into
>>>>>> the late December period when folks are away, driving the actual
release
>>>>>> into January. Even if that didn't happen, the possibility
made December
>>>>>> releases stressful.
>>>>>>
>>>>>> I don't think a strictly quarterly cadence is necessary; e.g.
we
>>>>>> could make the Apr-Jul release cycle a couple weeks shorter to
get that
>>>>>> release out of July and into June, if devs would find that better
for their
>>>>>> summer schedules.
>>>>>>
>>>>>> Note that my idea here isn't to come up with a set-in-stone
schedule
>>>>>> a year in advance. It's more to come up with general idea
that we can
>>>>>> promise to our community (e.g. 4 releases in a year) and a rough
prediction
>>>>>> when they will be.
>>>>>>
>>>>>> [1]
>>>>>>
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/...
>>>>>>
>>>>>> [2] Note that the WildFly 31 Beta date is significantly further
>>>>>> ahead of the Final date than the typical 2 weeks. This is so the
Beta is
>>>>>> done and released before so many devs end work for the year.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Brian Stansberry
>>>>>> Project Lead, WildFly
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>>>>> To unsubscribe send an email to
wildfly-dev-leave(a)lists.jboss.org
>>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeff Mesnil
>>>>> Principal Software Engineer
>>>>> Red Hat
>>>>>
http://jmesnil.net/
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>>>
>>>>
>>>
>>> --
>>> Brian Stansberry
>>> Principal Architect, Red Hat JBoss EAP
>>> He/Him/His
>>>
>>
>>
>> --
>> Brian Stansberry
>> Principal Architect, Red Hat JBoss EAP
>> He/Him/His
>>
>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His