[wildfly-dev] Re: Processing an issue in a new Feature Development Process

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(a)redhat.com&gt; wrote: > > > On Fri, Dec 1, 2023 at 10:49 AM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; 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-RlMfH5xWmHHs... >> 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/... >> 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(a)redhat.com&gt; >> 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(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)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