Abandoned Extension Maintainer Proposal - camunda-dmn-xlsx

[gitgoodjhe]

We would like to make this extension compatible with Java 17, SpringBoot 3 and the recent Camunda Releases. For this the extension needs dependency updates regularly which we would implement in our day-to-day business dealing with other open source software maintained by us.

Our goal as a maintainer is to get this extension up and running with current versions of the software, tools and frameworks it is intended for

We currently maintain the open source software TASKANA. In the project we have a modern CI/CD Pipeline with GithubActions that runs a lot of automated tests. The Test Coverage overall is 80%. We always work in a four-eyes principle, meaning another experienced developer reviews any pull requests that we create ourselves. In addition to that we make use of SonarCloud in our Pipeline which further makes sure that the quality of the new code is sufficient to our standards, e.g. no security hotspots or bugs as well as atleast 80% test coverage

I agree that I have either:

• [ ] Made a good faith effort to contact the extension's original maintainer.
• [x] Successfully reached the extension’s original maintainer and they are in agreement that I am to maintain this extension moving forward.
• [x] I will update the documentation accordingly to reflect my status as this extension's Maintainer.
• [x] I have read the Camunda Community Hub documentation.
• [x] I have read the Camunda Community Hub abandoned extension Maintainer proposal documentation.
• [x] I will /assign myself this issue, and add the relevant issue labels to it if they are not automatically generated by Probot.
• [x] I will tag @camunda-community-hub/devrel in a new comment on this issue if 30 days have passed since my pull request was opened and I haven't received a response from the extension's original maintainer.

[xomiamoore]

Hi @gitgoodjhe, thanks for submitting! After looking into everything, I'm happy to make you a maintainer for this repo https://github.com/camunda-community-hub/camunda-dmn-xlsx

Is it just you who needs Maintainer access or is there anyone else on your team that would need it?

[gitgoodjhe]

Hi @xomiamoore

Great News! Would it be possible to give the maintainer access to our Github organization which includes all team members? Or is it mandatory to name all other team members individually?

[xomiamoore]

@gitgoodjhe I did a little digging, it looks like I have to add them all individually.

[gitgoodjhe]

@xomiamoore

Alright, in that case our team members that would need a maintainer role besides me would be:

https://github.com/holgerhagen https://github.com/SebastianRoseneck https://github.com/nyuuyn https://github.com/ryzheboka https://github.com/jamesrdi

is that alright? Thanks a lot :)

[xomiamoore]

@gitgoodjhe Awesome, sent invites to everyone! They expire after a few days, so please accept them quickly. :)

[gitgoodjhe]

@xomiamoore Thanks for the invites! Unfortunately only these 3 got the invites so far:

https://github.com/nyuuyn https://github.com/ryzheboka https://github.com/jamesrdi

while

https://github.com/holgerhagen https://github.com/SebastianRoseneck

and myself don't have one yet. Is the invite pending for you?

[xomiamoore]

@gitgoodjhe Hmm, weird! Looks like @holgerhagen has accepted now, and both you and @SebastianRoseneck are pending. Let me know if you need me to cancel and try again 🤔

[xomiamoore]

Hey @gitgoodjhe, I wanted to check in on this to see what needs to be done to close out this issue. 🙂

[ryzheboka]

Hi @xomiamoore :) we have questions about the credentials for building a new release. We assume that we first need suitable access data or authorizations to be able to release the project under the same name. We plan to execute the release using Github actions based on community-action-maven-release. The template for this has already been a part of the project before us. Current release template uses the following Github secrets for authorization: NEXUS_USR, NEXUS_PSW, MAVEN_CENTRAL_DEPLOYMENT_USR, MAVEN_CENTRAL_DEPLOYMENT_PSW,MAVEN_CENTRAL_GPG_SIGNING_KEY_PASSPHRASE. We do not have access to the values of these secrets. We would be open to using our own users for authorization and creating new secrets. However, we suspect that new users must first be authorized before they have corresponding permissions to camunda-dmn-xlsx in Nexus and Maven Central. We could also take over the previous users if they were created and used exclusively for this project. Do we need to contanct the previous maintainers with our question? Or could you give our users the appropriate authorizations? Alternatively, we could also use the old credentials if it makes more sense.

[xomiamoore]

Great question @ryzheboka! Anyone with collaborator access to the repo should be able to use the organization secrets. All repos in the Community Hub that use these deployment methods use these secrets, but they are encrypted so you won't have the values of them.

Is there a reason you are trying to view the values? 🤔

[ryzheboka]

Hi @xomiamoore thanks for the answer! I falsely thought that the secrets belonged to the repo instead of the camunda-community-hub organization. With them belonging to the organization, it makes sense to not know the values. Our main reason for wanting to know the values was the assumption that the release might require steps that need to be performed manually (like we do it in our other projects). However, with your answer this doesn't seem to be the case when using community-action-maven-release. If we can rely on community-action-maven-release already performing all steps without the need for further authorization, we don't need the values of the secrets :) We will try out to relase the project using community-action-maven-release and see if it works!

[xomiamoore]

Excellent! Let me know if you run into any other issues (or feel free to tag me in anything on the repo itself) :)

[xomiamoore]

Closing this issue since it's about taking over the extension and that process is complete -- if anything else pops up, please tag me in the Issue or create a new one here.