Hosting process

13 views
Skip to first unread message

Slide

unread,
Aug 27, 2019, 1:01:27 PM8/27/19
to jenkin...@googlegroups.com
Based on some feedback from various people during plugin hosting requests, our current method of forking and renaming repositories is not as desirable as one might hope. I am thinking of creating a JEP to change the process, but wanted to solicit some feedback before I do so. I would like to propose that the process be changed as follows:

1) Person/Org submits request to the HOSTING project, but the New Repository Name field is removed. 
2) The normal checks occur, however, now the originating repository name must follow the rules that we normally used for New Repository Name (e.g., if a plugin it must end in -plugin, no camelcase, etc). 
3) Once the plugin has has completed the review process as it does now (automated checker and human review) the requester would initiate a repository transfer request on Github
4) Once the transfer request has been submitted, the ircbot would be updated such that the "host" command would accept the transfer and setup the teams on the repository to complete the transfer.

This would remove the need for users to break the relationship between the originating repository and the jenkinsci repository (which would become the canonical repository).

Please let me know your thoughts on this process change idea. If it has good feedback, I'll submit a JEP to document the process.

--

Gavin Mogan

unread,
Aug 27, 2019, 1:03:49 PM8/27/19
to jenkin...@googlegroups.com
+1
I like the idea of not having to contact support to break the link


--
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/CAPiUgVdKJLWzcuAAVnmZRwwLvrZyRSC_wYdizp-TYbEMyh-ziQ%40mail.gmail.com.

Matt Sicker

unread,
Aug 28, 2019, 11:16:04 AM8/28/19
to jenkin...@googlegroups.com
Sounds like a good idea.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuGgswR6B%2BC930Sh%3Dm-yzU%3D%3DrD3FA%3DNXh9YXDAXrQaV5Q%40mail.gmail.com.



--
Matt Sicker
Senior Software Engineer, CloudBees

Oleg Nenashev

unread,
Aug 28, 2019, 11:59:10 AM8/28/19
to Jenkins Developers
 the requester would initiate a repository transfer request on Github

Note that it used to require some additional automation logic, because a contributor cannot just move a project to jenkinsci.
It has to happen through an intermediate organization like https://github.com/jenkinsci-transfer we use now.

I need to test whether there is a transfer request feature in GitHub and whether we can automate the bot somehow. If so, this is perfect

 

On Wednesday, August 28, 2019 at 5:16:04 PM UTC+2, Matt Sicker wrote:
Sounds like a good idea.

On Tue, Aug 27, 2019 at 12:03 PM 'Gavin Mogan' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
>
> +1
> I like the idea of not having to contact support to break the link
>
>
> On Tue, Aug 27, 2019 at 10:01 AM Slide <slid...@gmail.com> wrote:
>>
>> Based on some feedback from various people during plugin hosting requests, our current method of forking and renaming repositories is not as desirable as one might hope. I am thinking of creating a JEP to change the process, but wanted to solicit some feedback before I do so. I would like to propose that the process be changed as follows:
>>
>> 1) Person/Org submits request to the HOSTING project, but the New Repository Name field is removed.
>> 2) The normal checks occur, however, now the originating repository name must follow the rules that we normally used for New Repository Name (e.g., if a plugin it must end in -plugin, no camelcase, etc).
>> 3) Once the plugin has has completed the review process as it does now (automated checker and human review) the requester would initiate a repository transfer request on Github
>> 4) Once the transfer request has been submitted, the ircbot would be updated such that the "host" command would accept the transfer and setup the teams on the repository to complete the transfer.
>>
>> This would remove the need for users to break the relationship between the originating repository and the jenkinsci repository (which would become the canonical repository).
>>
>> Please let me know your thoughts on this process change idea. If it has good feedback, I'll submit a JEP to document the process.
>>
>> --
>> Website: http://earl-of-code.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/CAPiUgVdKJLWzcuAAVnmZRwwLvrZyRSC_wYdizp-TYbEMyh-ziQ%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.

Slide

unread,
Aug 28, 2019, 12:02:55 PM8/28/19
to jenkin...@googlegroups.com
On Wed, Aug 28, 2019 at 8:59 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
 the requester would initiate a repository transfer request on Github

Note that it used to require some additional automation logic, because a contributor cannot just move a project to jenkinsci.
It has to happen through an intermediate organization like https://github.com/jenkinsci-transfer we use now.

I need to test whether there is a transfer request feature in GitHub and whether we can automate the bot somehow. If so, this is perfect


Correct, the transfer request is initiated by someone with access on the origin repository side, but the request has to be authorized by the receiving organization. The automation of the transfer request acceptance is definitely something that needs to be figured out.

 
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/a9f09d9d-7c03-4610-993d-c5a448134192%40googlegroups.com.


--

Gavin Mogan

unread,
Aug 28, 2019, 12:31:56 PM8/28/19
to jenkin...@googlegroups.com
Why transfer it at all? Why not clone, create the new repo, then push.

That would break the fork linkage, and be less complicated.

Probably a little slower but doesn't need to be realtime speeds

Slide

unread,
Aug 28, 2019, 12:36:06 PM8/28/19
to jenkin...@googlegroups.com
On Wed, Aug 28, 2019 at 9:31 AM 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
Why transfer it at all? Why not clone, create the new repo, then push.

That would break the fork linkage, and be less complicated.

Probably a little slower but doesn't need to be realtime speeds

That is another option. That would require the ircbot that completes the hosting request to have git capabilities in its container to clone the originating repo and push to the newly created repo. That is not unreasonable, it may be more complex to make sure all steps work all of the time.

 

Jesse Glick

unread,
Aug 28, 2019, 2:56:01 PM8/28/19
to Jenkins Dev
On Wed, Aug 28, 2019 at 12:31 PM 'Gavin Mogan' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
> That would break the fork linkage

Which would be a downside I think. Also the current method forces you
to remember to delete your own account’s clone so the @jenkinsci one
does not appear as a fork of it.

Also you would lose any existing issues, PRs, etc.

The repository transfer operation seems like the most intuitive and
least problematic approach.

Gavin Mogan

unread,
Aug 28, 2019, 2:58:13 PM8/28/19
to jenkin...@googlegroups.com
> Which would be a downside I think.

Oh I thought that was the intention

Yea for sure a downside

--
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.

Oleg Nenashev

unread,
Aug 29, 2019, 5:48:28 AM8/29/19
to Jenkins Developers
As long as the transfer process is automated, +100 for that.
It should also help to avoid issues when contributor companies request hosting but then continue development in their own repos (no finger-pointing in this thread).

On Wednesday, August 28, 2019 at 8:58:13 PM UTC+2, Gavin Mogan wrote:
> Which would be a downside I think.

Oh I thought that was the intention

Yea for sure a downside

On Wed, Aug 28, 2019 at 11:56 AM Jesse Glick <jgl...@cloudbees.com> wrote:
On Wed, Aug 28, 2019 at 12:31 PM 'Gavin Mogan' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
> That would break the fork linkage

Which would be a downside I think. Also the current method forces you
to remember to delete your own account’s clone so the @jenkinsci one
does not appear as a fork of it.

Also you would lose any existing issues, PRs, etc.

The repository transfer operation seems like the most intuitive and
least problematic approach.

--
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.

Baptiste Mathus

unread,
Sep 5, 2019, 5:40:15 AM9/5/19
to Jenkins Developers
I am +1000 on the transfer goal, instead of forking.

I am quite bothered TBH by the immense amount of fork links that are still present on many (most?) plugins in our GH org. I believe that it sends quite a misleading message especially to new contributors.

We indeed need to be very careful and automate ideally everything, because to be allowed to transfer repo, AFAIR one needs to be admin. And in the past, we've had someone even *delete* the https://github.com/jenkinsci-transfer organization after the transfer had been done, thinking this was a one-off one...

On top of the fact PRs against forked repositories are simply ignored in one's statistics (granted, not everybody cares about this, but I think this can be important for some people, possibly more juniors, who want to join the pleasant and the useful to grow their résumé).

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/cc66f864-4acc-4cc0-b79f-71d918f3fe37%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages