Just an idea. We could have the concept of Historical Maintainers. Jakarta
does this within its specifications
is an
example.
I don't know that we plan to display this information anywhere or that we
even want to do that, but just an idea.
James R. Perkins
Principal Software Engineer
On Thu, Oct 30, 2025 at 11:06 AM Brian Stansberry <bstansbe(a)redhat.com>
wrote:
No need to apologize; I'm glad you asked. I think this the most
likely
discussion topic with this; whether we want to do any further review of
write perms and based on that reduce this initial list before merging it.
We should do further review; that's good general practice. I don't know if
we'd end up wanting to remove people from this list based on that though.
I'll admit my opinion on that is based on perms scanning I and some others
did, and a tricky thing is I don't think it's good practice to publish all
those details.
I'm also happy to answer any questions privately.
On Thu, Oct 30, 2025 at 10:52 AM James Perkins <jperkins(a)redhat.com>
wrote:
> Okay, thanks for the clarification. I should have read the document
> again, but it was late and I'm making excuses for it :)
>
>
> James R. Perkins
>
> Principal Software Engineer
>
>
> On Thu, Oct 30, 2025 at 8:01 AM Brian Stansberry <bstansbe(a)redhat.com>
> wrote:
>
>> During the governance discussions we discussed that people could propose
>> a cleanup.
>>
>> This was done to some extent as part of the work that went into the list
>> I submitted. It wasn't exhaustive.
>>
>> One thing though is being a Maintainer doesn't mean you have write
>> perms to any particular repository, or even to any repository. It means you
>> have the right to be given those (by the relevant repo admins) and that you
>> can perform the general duties of a Maintainer, e.g. "Responsible for
>> driving initiatives and reviewing/merging contributions in their area of
>> expertise".
>>
>> IOW repo admins can adjust who has write perms without removing people
>> from the Maintainer list.
>>
>> OTOH the opposite is not true -- repo admins cannot grant perms to
>> non-Maintainers; they have to start by getting people added.
>>
>>
>> On Wed, Oct 29, 2025 at 7:57 PM James Perkins via wildfly-dev <
>> wildfly-dev(a)lists.jboss.org> wrote:
>>
>>> Looking at the list I see some people who no longer actively maintain
>>> WildFly or its components. Do we want to set some kind of time frame or
>>> some kind of way to clean up/remove maintainers who are not active?
>>>
>>>
>>> James R. Perkins
>>>
>>> Principal Software Engineer
>>>
>>>
>>> On Wed, Oct 29, 2025 at 2:24 PM Brian Stansberry
<bstansberry(a)gmail.com>
>>> wrote:
>>>
>>>> The GOVERNANCE.md for WildFly AS that we adopted last week includes a
>>>> "Maintainer" role. Alongside that GOVERNANCE.md we have a
Team.md
>>>> where we'll list the people in the various roles. We need to
populate
>>>> that document.
>>>>
>>>> I've sent up
https://github.com/wildfly/wildfly-governance/pull/7 to
>>>> do that for the Maintainer role, plus a subset of those in the
>>>> 'Publisher' role -- those who publish the main wildfly/wildfly
repo.
>>>>
>>>> Your inputs on this are most welcome!
>>>>
>>>> The GOVERNANCE.md defines Maintainers as:
>>>>
>>>> "Contributors eligible for write access to a code repository for a
>>>> WildFly Application Server project. Responsible for driving
>>>> initiatives and reviewing/merging contributions in their area of
>>>> expertise. Write access might be limited to particular
repositories."
>>>>
>>>> So I started from the premise that our initial maintainers are those
>>>> who we've given write perms in the past. I did some tool-drive
Github
>>>> inspection + discussion with various folks who deal with GH orgs where
>>>> my tool didn't work, plus some permission list cleanup discussions.
>>>> The resulting set of names is in the PR.
>>>>
>>>> Thank you to those of you who helped me with this!
>>>>
>>>> Going forward, before any grants write access to any of the dozens of
>>>> WF AS repos we should check that they are on the Maintainer list and
>>>> if not have a discussion to get them added.
>>>>
>>>> Best regards,
>>>>
>>>> Brian Stansberry
>>>> WildFly project lead
>>>> He/him/his
>>>> _______________________________________________
>>>> 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:
>>>>
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
>>>>
>>> _______________________________________________
>>> 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:
>>>
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
>>>
>>
>>
>> --
>> Brian Stansberry
>> Architect, JBoss EAP
>> WildFly Project Lead
>> He/Him/His
>>
>
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His