hi Brian,

Thanks for the reply and sorry for the delay on my side as well. OK, I see that Paul PR has been merged already and as the feature has already been implemented I will try to get more familiar with it and adopt it accordingly.

Regards,

Tomek

On Fri, Dec 1, 2023 at 5:51 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:

On Fri, Dec 1, 2023 at 10:49 AM Brian Stansberry <brian.stansberry@redhat.com> wrote:

Hi Tomek,

Sorry; I just saw this! You sent it over the long holiday weekend here in the US and I just now checked this list for older stuff.

I'd like to use this feature, and perhaps similarly-scoped ones, as a way of progressing on the new process by working on a concrete case. That would involve two parallel tracks:

Track 1:  Working through topics like the questions you ask, and doing what we can on your PR to have it ready for when the Track 2 is integrated.

Track 2: Getting Paul's work at https://github.com/wildfly/wildfly-core/pull/5413 merged (hopefully next week) and integrated into full WF.

Then we could tweak your PR to add the settings that make it appear as some stability level other than default.

So, for your questions:

1) Deciding stability level: I think the way it would work is the feature author decides what stability level they want to aim for. So that's you.

Sorry; that's Ivo, in consultation with you. :)

Then when a feature freeze deadline comes the people working the issue either meet the requirements for that level, or they don't. If they don't they can keep working, or they can choose a different level that they can meet. They of course can also change their mind at any point, not just at the feature freeze deadline.

We should add a field for this to the wildfly-proposals template as this is info that should be available to readers of the analysis.

(FWIW this sounds like a Community level feature to me, but it's up to the feature team.)

2) JIRA: The initial development is a normal Feature Request JIRA in WFLY or WFCORE. File related issues etc as appropriate/desired to account for any independent pieces of work. So just normal stuff.

I think for any feature that's not targeting the default stability level, the JIRA title should state the target level. That makes it prominent in the release notes, and makes it easy for me to find when I write release announcements. We should come up with some standard format for how to express that.

JIRA issues are associated with a Fix Version, so once merged and that version is released, any further work to get the feature to a higher stability level would require a follow-up JIRA.  I think that would be another Feature Request "Promote <the feature name> to stability level <the level>".

3) Bootstrapping.

What you should do is:

a) Start a discussion -- done, here :)

b) Work with Ivo to choose a target stability level. Use https://docs.google.com/document/d/15_yKhW74-X9s2zUhs_ZUuZ3h-RlMfH5xWmHHsfYf1AA/edit#heading=h.vaxfllj8snno to get a sense of what each level would require.

c) Work to meet the requirements in that doc for your target level. If the meaning of the requirements are unclear, use this thread or the discussion channels I mentioned in https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/JI5GX7Q2UPGXTDEMZG4F3PNF4BDQKB4A/ to get clarification.

I know this work has been around for a long time, so it should be possible to do those things pretty quickly.  Perhaps the biggest aspect is creating a test plan. What that means is a TODO in the proposed process. I think in general the idea of the process is to make things more formal in higher levels. These "expose component feature X via the WF management API" ones are a bit tricky as the heart of the feature is in the component (IJ), so there's always the question of how well it's tested at that level, and how much we want to document that testing.

I think for the basic Stage.MODEL management API testing we should come up with some standard boilerplate. Same for domain transformation testing. For this particular issue we can problem just use a placeholder like "standard subsystem model testing" and "standard subsystem-level domain transformation testing". I think there's a general understanding of what that means that's enough until we formally write it down.

HTH,

Brian

On Thu, Nov 23, 2023 at 11:57 AM Tomasz Adamski <tadamski@redhat.com> wrote:

Hi,

This mail is a follow up to the discussion regarding processing WFLY-17180 in the new feature process. I would like to discuss what are the steps that I have to take to follow the new process. I have a feature that  is a model change (adding query-time parameter to datasource validation) so it seems to me that it would qualify as either preview or community feature: imho it is neither complex nor risky, it is already implemented (the implementation is partially done in IronJacamar library, so it would require component upgrade), the tests are provided as part of implementation PR and analysis as part of other PRs as well.

If we decide that this issue is suitable to be delivered using the new process the initial questions that come to my mind are:

What is the maturity of the issue and how is it going to be decided?

How is it going to be traced in JIRA? 

What steps do I need to take to bootstrap the process?

Regards,

Tomek

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives:

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

He/Him/His

--

Regards,

Tomek