Rename 'default' stability level
by Brian Stansberry
One of the bigger pain points I'm seeing with our stability level stuff is
the name/meaning of the 'default' level. The only sense in which that one
is truly 'default' is the internal implementation detail that in various
management kernel classes it's the default value of some fields. Which is
irrelevant to anyone but developers of WF. It's not the OOTB, aka 'default'
stability level of standard WildFly or of WildFly Preview.
This has been a recurring topic of discussion, and I think early in …
[View More]the WF
35 cycle would be a good time to fix it.
If we change it we should make sure the old value still works (as an alias)
in places where users can set it.
Darran suggested using 'base' instead, which I personally like.
The true meaning of this level is "same as community, but we made sure
people with formal QE and docs writing expertise were part of the feature
team". In lots of conversations about alternative names no one came up with
a good word that has that meaning. Surprising! 'Endorsed' came closest.
Adjacent concepts like 'mature' came up but that implies age, and things at
this level are not necessarily older. Plus the opposite is 'immature' and
that's not the intent of 'community'.
I like 'base' because it sidesteps the above and focuses on the fact that
our levels are basically supersets of each other in terms of what sets of
features are available. And what's available in 'default' stability is the
core, or 'base' set.
Thoughts?
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
[View Less]
6 months, 2 weeks
'Critical' JIRA cleanup
by Brian Stansberry
We've got a lot ofJIRAs with 'Critical' priority that have been inactive
for a long time. I think we should define 'Critical' as roughly "important
enough that we need to work on it soon." At some point if something goes
unaddressed long enough that's a sign that it's not important enough to be
called critical.
I propose doing the following: for any Critical WFLY or WFCORE that was
opened > 12 months ago and hasn't shown signs of activity since the WF 32
release, I'll leave a comment saying …
[View More]I plan to downgrade it to Major unless
the assignee says they plan to deal with it for the WF 34 cycle. And then a
couple weeks later downgrade issues.
Similarly, for issues with Fix Version 33.0.0.Final that have been rolling
from release to release since WF 31 or earlier, when I release 33 I intend
to remove the Fix Version instead of rolling it to 34.
WDYT?
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
[View Less]
6 months, 2 weeks
Promotion from wildfly-extras?
by Brian Stansberry
The discussion Flavia started about the process around the proposed
wildfly-ai-feature-pack[1] got me thinking a bit about how we are using
wildfly-extras.
The basic concept when we started that was it would be used for:
1) Projects that are incubating.
2) Some vague idea around the notion of things that are out of the
mainstream for the overall WildFly project. Perhaps something meant for
more specialized use, etc.
But now we have some things in there that are not incubating and are very
…
[View More]mainstream. In particular, WildFly Glow now maintains knowledge of a set of
feature packs it uses when making suggestions, and that includes feature
packs housed in wildfly-extras.
Is it time to move some things to the main 'wildfly' organization,
particularly these feature packs Glow uses? Going forward should that be a
criteria for inclusion in Glow recommendations? (At least that we have
decided something is ready to be moved. The actual move is just a detail.)
I don't know if cleaning this up would provide any greater freedom to
experiment with things in wildfly-extras without following the feature dev
process. Probably not, at least not for things that the WildFly project in
general will be promoting.
[1]
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
[View Less]
6 months, 3 weeks