What's our current process for new committers?

[Anders Hammar]

Hi,

At Codehaus Mojo I think we added new devs/committers to the team when accepting them, so they can work on all plugins. But know it looks like some devs have been added separately to just one plugin.

As there is a new dev whosing interest in working with ther aspectj-m-p I wonder how we should handle that?

/Anders

[Baptiste Mathus]

Thanks for raising this question Anders!

AFAIK, we don't have a strict process. Or at least I'd say this process has not been exercised enough in the last years to be considered really *our* process I guess...

So, I've been pondering a bit on this.

Given our current status (I.e. not extremely active and many de facto abandoned plugins)

I'm thinking that maybe we'd want to transform our process to be more like the Jenkins one: moving away from an all-or-nothing maintainer access, and giving maintainer permissions in a more open manner/less barrier (which was anyway part of the reasoning behind MOJO vs. Apache).

Also, our current status from an ownership perspective seems quite dangerous: we have 31 owners (23 having 2FA enabled).

I would propose something like the following:

* We reduce the number of people with owner status (e.g. by removing the ones without 2FA enabled, then pinging existing people to see if they're willing to keep the permissions)

* We initiate maintainers' team per plugin.

** By default, we could for instance only put 'members' (as listed in GitHub) who merged anything since we switched to GitHub.

Anyway, not really asking for specifics at this stage. More like: do you agree with the general idea/intent?

Overall what I'm saying is I think we should together make the barrier lower so mojohaus keeps rocking, instead of keeping it locked and it progressively decays even more in terms of activity...

WDYT ?

-- Baptiste

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CAKDUN1u7nVywOa9D%2BfD6fSEDA29RfKaDFgJaCBdduh_2W7MQ-A%40mail.gmail.com.

[Anders Hammar]

Sounds good to me! We need more activity!

/Anders

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CANWgJS6ZTM3f2rEv8sVLW8UeuU6a0vJvTzfKPx3E-jHNXwG3Rw%40mail.gmail.com.

[Mirko Friedenhagen]

Hello Baptiste, hello Anders,

agreed. The process needs to be clarified. So is your suggestion to let more people work on the code by allowing access to single repositories and let a smaller group of people only do releases/publish to repo1, so that we keep at least some review process here?

The lazy consensus was very lazy in the last years (I have to admit that I did not look for some time into releases deeply, mostly saw the release e-mails fly by).

Best Regards Mirko

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CAKDUN1vUbA_YLcfyrr9aUDtNL0qyJSf1%3D7a_sR5NjMeOQA7JKg%40mail.gmail.com.

[Zos ROTHKO]

Hello

Le 14/02/2020 à 16:39, Anders Hammar a écrit :

Sounds good to me! We need more activity!

/Anders

On Fri, Feb 14, 2020 at 2:54 PM Baptiste Mathus <m...@batmat.net> wrote:

Thanks for raising this question Anders!

AFAIK, we don't have a strict process. Or at least I'd say this process has not been exercised enough in the last years to be considered really *our* process I guess...

So, I've been pondering a bit on this.

Given our current status (I.e. not extremely active and many de facto abandoned plugins)

I'm thinking that maybe we'd want to transform our process to be more like the Jenkins one: moving away from an all-or-nothing maintainer access, and giving maintainer permissions in a more open manner/less barrier (which was anyway part of the reasoning behind MOJO vs. Apache).

Also, our current status from an ownership perspective seems quite dangerous: we have 31 owners (23 having 2FA enabled).

I would propose something like the following:

* We reduce the number of people with owner status (e.g. by removing the ones without 2FA enabled, then pinging existing people to see if they're willing to keep the permissions)

* We initiate maintainers' team per plugin.

** By default, we could for instance only put 'members' (as listed in GitHub) who merged anything since we switched to GitHub.

I am interested by your proposal for the javacc-maven-plugin. I started to work on this plugin under the umbrella of Jochen Wiedmann <jochen....@gmail.com>. But despite many mails on the subject, he stopped the exchange about my PR, may be because what I was proposing was too dumb...(no one knows ALL of the Maven ecosystem, specially the newcomers). I am a owner-by-side of the JavaCC library and as I got no response from Jochen Wiedmann <jochen....@gmail.com> and this plugin needs a update for the upcoming release of JavaCC, I started to forks this javacc-maven-plugin by changing its groupId to org.javacc. I do not want to go in this direction of making a fork, but I need to extend the Mojo javacc-maven-plugin for building JavaCC itself.

Anyway, not really asking for specifics at this stage. More like: do you agree with the general idea/intent?

Overall what I'm saying is I think we should together make the barrier lower so mojohaus keeps rocking, instead of keeping it locked and it progressively decays even more in terms of activity...

WDYT ?

-- Baptiste

Le mar. 11 févr. 2020 à 08:56, Anders Hammar <and...@hammar.net> a écrit :

Hi,

At Codehaus Mojo I think we added new devs/committers to the team when accepting them, so they can work on all plugins. But know it looks like some devs have been added separately to just one plugin.

As there is a new dev whosing interest in working with ther aspectj-m-p I wonder how we should handle that?

/Anders

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CAKDUN1u7nVywOa9D%2BfD6fSEDA29RfKaDFgJaCBdduh_2W7MQ-A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CANWgJS6ZTM3f2rEv8sVLW8UeuU6a0vJvTzfKPx3E-jHNXwG3Rw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CAKDUN1vUbA_YLcfyrr9aUDtNL0qyJSf1%3D7a_sR5NjMeOQA7JKg%40mail.gmail.com.

[David Karlsen]

Opening up seems reasonable.

By using automated tooling (bots) it's easier to lock down repos (e.g. not requiring owner, or even direct write-access) - and handle more things through PR labelling. This makes it easier to onboard people.

I used to maintain the aspectj plugin - but have not found the time for it, so I believe it was forked and some folks use that, but there is now interest in maintaining the original again - as seen on the mailing-list.

[Baptiste Mathus]

Yeah, I agree about the automation (obviously :)). I'm just not definitely *personally* committing to it as I know this takes time to do well, and even then takes some maintenance time.

@Mirko: yes, the/some releases AFAIK started not following our process. I think many got pushed out without an email here, though I might be wrong.

I think instead of frowning at this, we probably should go back to David's take and my answer above around making things easier.

E.g. I was thinking using a common build & release pipeline for all plugins to make everything easy for contributors.

I know how to do this, I just quite lack the time to do this these days.

-- Baptiste

--

You received this message because you are subscribed to the Google Groups "mojohaus-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojohaus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/85dbc717-8633-48a8-89ec-2e5455902377%40googlegroups.com.

[Anders Hammar]

To follow up here, we have a case here where a new committer (for one specific mojo) wants to do a release. Mirko brought up the idea of having a smaller group of people do the releases. Should we go that route, or should all committers for a mojo also be able to do releases?
What we need to understand is that the privs on Sonatype OSSRH is for the whole org.codehaus.mojo groupId, not specific mojo sub-groupIds. So when you get access you can publish all mojos. But as you don't have write privs for all git repos releases shouldn't happen by accident though.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CANWgJS43v81Pu%2BvRTEyc_CKs95YjAhqVmF8SaF5NOdJacZ1yaA%40mail.gmail.com.

[Baptiste Mathus]

Very good point on the restrictions aspects.

I assume we could ask comm...@sonatype.com for what are the possibilities.

On the Jenkins Project side e.g., we have a repository dedicated to this https://github.com/jenkins-infra/repository-permissions-updater/ and this gets applied to permissions on the MRM every 5 min or so (artifactory), unsure we _could_ ever do something similar with OSSRH...

I guess we could ask comm...@sonatype.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mojohaus-dev/CAKDUN1unjpX1mJ%2BsmYZWd75DkJe0C2TrKrShN7Mx44PEQZrN3w%40mail.gmail.com.