[Proposal] Transfer of CloudBees-community/syslog-java-client to jenkinsci Github org

[Michaël Pailloncy]

Hi all,

CloudBees would like to propose a transfer of CloudBees-community/syslog-java-client to the jenkinsci Github organization.

This project is currently used by the following projects, including:

• jenkinsci/audit-trail-plugin
• jenkinsci/logstash-plugin
  
• jenkinsci/configurationslicing-plugin

The reasoning behind this proposal is to let this project benefit from the infrastructure and processes of the Jenkins project.   

Please let me know your thoughts on this, and if everyone agrees, how you would like to proceed.

Thanks

---

Michaël Pailloncy

[Mark Waite]

+1 from me

[Basil Crow]

+1 from me as well. Once transferred, we will need to add a new YAML file to repository-permissions-updater (RPU) to grant someone GitHub and Artifactory permissions. I am CC'ing Cyrille Le Clerc as the original author and last maintainer of this repository. If Cyrille is interested in maintaining this repository, I can create the RPU PR to grant him GitHub and Artifactory permissions. In the absence of a positive response from Cyrille, we can consider the repository orphaned and allow anyone to adopt it pending the customary two-week waiting period. I am willing to facilitate the transfer and file PRs to ensure that the repository can be built on Jenkins CI infrastructure and released to the Jenkins project Artifactory server. Beyond that I cannot commit to doing any maintenance on this repository.

[Cyrille Le Clerc]

It's a great idea to allow the syslog-java-client to progress migrating it to the Jenkins Community. I'm fully supportive.

The MIT License should make it easy.

Note that I am less involved in Syslog things as I am now focused on OpenTelemetry and particularly at the moment OpenTelemetry Logs as I have just released the capability with the Jenkins OpenTelemetry plugin to store Jenkins pipeline logs in an external backend like Elasticsearch through the OpenTelemetry APIs and protocol: https://github.com/jenkinsci/opentelemetry-plugin/blob/master/docs/build-logs.md 

Cyrille

[Basil Crow]

On Mon, Mar 14, 2022 at 3:08 PM 'Cyrille Le Clerc' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
> It's a great idea to allow the syslog-java-client to progress migrating it to the Jenkins Community. I'm fully supportive.
> The MIT License should make it easy.

Thank you for the quick reply! In that case, I think we can proceed with the transfer without the two-week waiting period.

Based on my reading of Transferring a repository, the owner on the source side (i.e., CloudBees-community) needs to initiate the transfer to the target side (i.e., jenkinsci), and the owner on the target side needs to accept the transfer within one day. I am not a GitHub organization owner on either side, but I assume there will be no issue accepting the transfer on the target side. So I think the next step is to initiate the transfer on the source side. Once the transfer has been completed in GitHub, I can create a PR for repository-permissions-updater to grant Cyrille Le Clerc and myself initial GitHub and Artifactory permissions. If desired, I can then update the build to use the Jenkins project's build and release processes to complete the transition.

[Cyrille Le Clerc]

Sounds like a perfect plan.

Many thanks

Cyrille

[Cyrille Le Clerc]

A question please: as there are many users of the syslog-java-client outside of the Jenkins community, how do we plan to explain them the migration? I guess we will change the Maven artifact groupID...

Can we keep an archived version of the syslog-java-client repo under the CloudBeesCommunity organization to explain the migration?

Cyrille

[Gavin Mogan]

Why do you need to change the group of?

If you do a transfer, it'll leave a redirect from the old URL to new url. Plus you can update SCM info in the pom file.

If you want to change the group id, I think it should be a fork and leave the old one behind.

My 2 cents

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/93b73619-1ccd-4168-b3e9-f1a7d2edad7bn%40googlegroups.com.

[Basil Crow]

On Tue, Mar 15, 2022 at 1:30 AM 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

> Why do you need to change the group of?

I concur with Gavin. I see no reason to change the Maven group ID or artifact ID, and we have historically not changed these when transferring repositories into the jenkinsci GitHub organization. For example, the recently-transferred File Leak Detector retains the original org.kohsuke group ID.

[Cyrille Le Clerc]

Thanks, I assumed the Jenkins community didn't have the permission to publish on maven central artifacts with the group Id com.cloudbees.

Did you consider publishing exclusively to Jenkins' own maven repository?

Cyrille

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/ZmNbkgCadUY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqTCEASOE7Nh%2BhftZGSYqwfzSSH0u9H5EUftiMZ-NVhaQ%40mail.gmail.com.

[Basil Crow]

On Tue, Mar 15, 2022 at 11:00 AM 'Cyrille Le Clerc' via Jenkins
Developers <jenkin...@googlegroups.com> wrote:
> Did you consider publishing exclusively to Jenkins' own maven repository?

I have configured the repositories we have transferred already, like
Mock JavaMail and File Leak Detector, to publish exclusively to the
Jenkins project's Artifactory server. This is the path of least
resistance, as it allows us to reuse existing infrastructure. Projects
that are only consumed by the Jenkins community will have no issue
with this. Projects that are consumed outside of the Jenkins community
need to adjust their build to add the Jenkins project's Artifactory
server. I think this is a reasonable burden to bear in exchange for
the infrastructure provided by the Jenkins project, but if somebody
feels strongly otherwise they can always set up releases to e.g. Maven
Central. My plan for syslog-java-client was to follow the existing
pattern and publish new releases exclusively to the Jenkins project's
Artifactory server.

[Michaël Pailloncy]

Thanks all! 

FYI The repository has been transferred: https://github.com/jenkinsci/syslog-java-client

Michaël

[Cyrille Le Clerc]

> FYI The repository has been transferred: https://github.com/jenkinsci/syslog-java-client

Thanks Mikael,

I verified the redirection for people who consume the library directly rather than going through a Jenkins plugin and it works like a charm.

> My plan for syslog-java-client was to follow the existing pattern and publish new releases exclusively to the Jenkins project's Artifactory server.

Thanks for the clarification Basil,

I think it's still important to publish the new versions of this library  on Maven Central for all the projects outside of the Jenkins Ecosystem that use this library. Could we evaluate solutions for this? I understand that the Jenkins community doesn't publish artifacts to Maven Central for the moment [1], do you have such a capability in place?

Cyrille

[1] https://search.maven.org/search?q=jenkins

[Tim Jacomb]

Is there anyone from CloudBees who wants access to this?

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7f109d28-c27e-4d6d-a80c-f106e3f537a5n%40googlegroups.com.

[Basil Crow]

Cyrille and I both now have access to this repository as members of the syslog-java-client-developers group. I have updated the build to remove any CloudBees-specific parent POMs, run CI builds on Jenkins project infrastructure, and update all third-party dependencies. Cyrille should now be able to merge open PRs, such as jenkinsci/syslog-java-client#50.

On Wed, Mar 16, 2022 at 6:49 AM 'Cyrille Le Clerc' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

> Thanks for the clarification Basil,
> I think it's still important to publish the new versions of this library  on Maven Central for all the projects outside of the Jenkins Ecosystem that use this library. Could we evaluate solutions for this? I understand that the Jenkins community doesn't publish artifacts to Maven Central for the moment [1], do you have such a capability in place?

You are correct that the Jenkins project is not currently publishing releases to Maven Central. I do not think we would have any issue with releasing syslog-java-client to Maven Central, but someone would need to follow the process outlined in the Sonatype OSSRH (OSS Repository Hosting) guide, including creating a Sonatype JIRA account, filing a ticket with Sonatype to obtain permissions (including proving ownership), and updating the Maven build to deploy to OSSRH. Since this is not a primary use case for the Jenkins project, I cannot volunteer my own time to complete this process, but if Cyrille or anyone else is interested in doing this I would support their efforts.

If, on the other hand, we decide to use the Jenkins project's Artifactory server, just let me know and I will add the Jenkins project parent POM and Artifactory configuration to the build and file the usual repository-permissions-updater PR for Artifactory permissions.

[Cyrille Le Clerc]

Thanks Basil,

I would definitely be interested in publishing the syslog-java-client library to Maven Central from non Jenkins project to easily consume the library.

My understanding of the Sonatype OSS publishing process is that one can only publish on a groupId he is legitimate for which probably means that the Jenkins Community will not been authorized to publish an artifact under the "com.cloudbees" groupId and will probably require to rename the groupId from "com.cloudbees" to "io.jenkins.***".

Do this make sense to you?

Cyrille

[Basil Crow]

Hi Cyrille,

On Wed, Mar 23, 2022 at 3:39 AM 'Cyrille Le Clerc' via Jenkins
Developers <jenkin...@googlegroups.com> wrote:
> I would definitely be interested in publishing the syslog-java-client library to Maven Central from non Jenkins project to easily consume the library.

Great!

> My understanding of the Sonatype OSS publishing process is that one can only publish on a groupId he is legitimate for which probably means that the Jenkins Community will not been authorized to publish an artifact under the "com.cloudbees" groupId and will probably require to rename the groupId from "com.cloudbees" to "io.jenkins.***".

Based on my reading of the Sonatype documentation, I think your
understanding is correct, but I would not necessarily assume that the
use of the "com.cloudbees" namespace by the Jenkins project for such
legacy libraries is forbidden. I think that is an open question that
we could pose to CloudBees management, and in particular Michaël
Pailloncy (who started this discussion). Non-technical matters aside,
the technical cost to CloudBees would be small (assisting with
Sonatype verification), while the technical benefit to users would be
large (avoiding a migration of Maven group ID for all consumers of
this library), so I think it is at least worth asking. If the answer
is no, fine - we can switch the group ID to "io.jenkins", open a help
desk ticket with the Jenkins infrastructure team to assist with the
Sonatype verification, and ask all downstream consumers to change
group IDs. I have no strong preference either way.

Best regards,
Basil

[Cyrille Le Clerc]

Keeping the same groupId would definitively be the best solution. Let's see what's CloudBees' answer.

Cyrille

[Michaël Pailloncy]

Hi all - I'm checking this internally and will come back to you as soon as I have an answer. Thanks