Offical policy for plugins stored not in organization

[Gavin Mogan]

So just saw octopus deploy was recently updated, and that it mentioned docs were in the github repo

Realized the plugin is being deployed from https://github.com/OctopusDeploy/octopus-jenkins-plugin not  https://github.com/jenkinsci/octopusdeploy-plugin

Is this something that update center should be preventing?

Gavin

[Mark Waite]

No, it is allowed to host a plugin outside the jenkinsci organization. 

--
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/CAG%3D_DutMUH6ApfjQ155AzKRN9PURO2kVkKywCv4vGGMquOBqEA%40mail.gmail.com.

[Daniel Beck]

We require a fork into jenkinsci for all newly hosted plugins (no upload permissions if you don't), and ask that it be the canonical repo (including inverting the fork relationship, or deleting the original).

Obviously we cannot make people release from jenkinsci; and there's still a handful of old repos that never were forked (since nobody controlled upload permissions back then). https://jenkins.io/doc/developer/publishing/source-code-hosting/ documents 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/CAG%3D_DutMUH6ApfjQ155AzKRN9PURO2kVkKywCv4vGGMquOBqEA%40mail.gmail.com.

--

Daniel Beck
Senior Software Engineer
CloudBees, Inc.

[Daniel Beck]

On Thu, Dec 5, 2019 at 10:21 AM Daniel Beck <db...@cloudbees.com> wrote:

Obviously we cannot make people release from jenkinsci

Or rather; we could (e.g. by blacklisting the plugin and pulling permissions until it is addressed, not unlike what we'd do for license violations), but so far nobody has been willing to open that can of worms.

FWIW, a related old discussion: https://github.com/jenkins-infra/repository-permissions-updater/pull/41

[Baptiste Mathus]

Actually, it is not allowed Mark, as summarized by Daniel in https://github.com/jenkins-infra/repository-permissions-updater/pull/41#issuecomment-249007272

As Daniel wrote, I had done some history excavation a few years ago to understand also what had been the historical expectations. 

And it had been confirmed that the expectation always was to host under the Jenkins org.

We have started requiring it more clearly since 2 or 3+ years for various reasons.

So, for any new plugin hosted in the last ~3 years (Slide has been doing an awesome job on this BTW), I think it would be quite disingenuous to pretend to be unaware that the expectation is to host under the jenkinsci GH org.

Now, during the hosting process, we even post at the end "Please remove your original repository so that the jenkinsci repository is the definitive source for the code. Also, please make sure you have a wiki page set up with the following guidelines in mind".  (random example: HOSTING-863)

In the very case of this octopus-deploy plugin, this was hosted before the HOSTING project was put in place.

It was hosted by Oleg in https://groups.google.com/d/msg/jenkinsci-dev/sFsi9qBEwa0/O9bA3l2naqsJ, and Oleg made it clear it got forked, etc. 

So I think similarly it would sound disingenuous to pretend that not using https://github.com/jenkinsci/octopusdeploy-plugin but another one outside the jenkinsci org would be perfectly normal :).

-- Baptiste

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

[Mark Waite]

Thanks Daniel and Baptiste for the clarification!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPyTVp0v%3DEfn9U19sSJ-UHH%3DJG%2BskEt0-cSyg_rQ4VJ8GSmDRg%40mail.gmail.com.

[Oleg Nenashev]

I think we should block releases from non-Jenkins organizations for newly hosted/released plugins.

AFAICT the easiest way to do so is to add a check to Plugin POM, but we can also do some enforcement on the update site later. As Daniel said, it is likely to be a can of worms.

FTR the plugin site currently does not support non-jenkinsci organizations as a source of plugin documentation.

Personally I have no intent of changing that

On Thursday, December 5, 2019 at 2:34:40 PM UTC+1, Mark Waite wrote:

Thanks Daniel and Baptiste for the clarification!

On Thu, Dec 5, 2019, 11:30 AM Baptiste Mathus <bma...@cloudbees.com> wrote:

Actually, it is not allowed Mark, as summarized by Daniel in https://github.com/jenkins-infra/repository-permissions-updater/pull/41#issuecomment-249007272

As Daniel wrote, I had done some history excavation a few years ago to understand also what had been the historical expectations. 

And it had been confirmed that the expectation always was to host under the Jenkins org.

We have started requiring it more clearly since 2 or 3+ years for various reasons.

So, for any new plugin hosted in the last ~3 years (Slide has been doing an awesome job on this BTW), I think it would be quite disingenuous to pretend to be unaware that the expectation is to host under the jenkinsci GH org.

Now, during the hosting process, we even post at the end "Please remove your original repository so that the jenkinsci repository is the definitive source for the code. Also, please make sure you have a wiki page set up with the following guidelines in mind".  (random example: HOSTING-863)

In the very case of this octopus-deploy plugin, this was hosted before the HOSTING project was put in place.

It was hosted by Oleg in https://groups.google.com/d/msg/jenkinsci-dev/sFsi9qBEwa0/O9bA3l2naqsJ, and Oleg made it clear it got forked, etc. 

So I think similarly it would sound disingenuous to pretend that not using https://github.com/jenkinsci/octopusdeploy-plugin but another one outside the jenkinsci org would be perfectly normal :).

-- Baptiste

On Thu, Dec 5, 2019 at 9:31 AM Mark Waite <mark.e...@gmail.com> wrote:

No, it is allowed to host a plugin outside the jenkinsci organization. 

On Thu, Dec 5, 2019, 1:31 AM 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

So just saw octopus deploy was recently updated, and that it mentioned docs were in the github repo

Realized the plugin is being deployed from https://github.com/OctopusDeploy/octopus-jenkins-plugin not  https://github.com/jenkinsci/octopusdeploy-plugin

Is this something that update center should be preventing?

Gavin

--
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 jenkin...@googlegroups.com.

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

--
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 jenkin...@googlegroups.com.

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

--
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 jenkin...@googlegroups.com.

[Oleg Nenashev]

I created https://github.com/OctopusDeploy/octopus-jenkins-plugin/issues/60 to discuss this issue with maintainers

[Daniel Beck]

On Tue, Dec 10, 2019 at 12:25 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote:

I think we should block releases from non-Jenkins organizations for newly hosted/released plugins.

Newly hosted plugins need to be forked, else they don't get permissions (I hope -- at least that's how I did it when I reviewed new plugin permission requests).

New releases of existing plugins could be blocked by taking away release permissions.

 

AFAICT the easiest way to do so is to add a check to Plugin POM, but we can also do some enforcement on the update site later. As Daniel said, it is likely to be a can of worms.

Enforcement that requires plugin maintainers to keep their parent POM up to date is doomed to fail. Or how would you in turn enforce an up to date parent POM? In a way that both does not break Gradle-built plugins, nor allow maintainers to circumvent the restriction by switching to Gradle?

Not to mention that we'd want to have a toggle to support private-source plugins, so any check here would be trivial to disable.

[Gavin]

Wouldn't it be easier to do in update center? Since SCM block has to be up to date so mvn release actually pushes tags to your SCM, couldn't update center be updated to ignore and not list any plugins that don't have the SCM set to the jenkinsci org?

--

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/CAMo7PtLhkvzJX97qNOEO9s_a89fOm5fwMm%3DiHK0NQ2%2BAX7zEhQ%40mail.gmail.com.