RFC: Stop accepting persistent forks as-is

[rnelson0]

From time to time, we have accepted persistent forks of modules, either as actual forks of modules or because the upstream maintainer has not responded. An example is puppet-grafana. This has caused us some problems:

• PRs by default go to the upstream repo. Very easy to put it in and not notice for hours.
• PR/Issues history is preserved in the commit log, but not as PRs and Issues in the GitHub API. This breaks github_changelog_generator among other things.

I am proposing that when we perform such a fork, we create a new repo, rather than a persistent fork. i.e. git clone [email protected]:bfraser/puppet-grafana.git; cd puppet-grafana; git remote rm origin; git remote add origin [email protected]:voxpupuli/puppet-grafana.git; git push --mirror origin. This breaks the tie to the previous fork and assists with PR creation. The GitHub history is lost but that happens anyway.

This policy would of course apply to permanent forks. If we intend to push changes and return those changes to the original maintainer, this policy would in no way apply

I'd like to have a discussion to weigh any other pros and cons of the current policy of accepting persistent forks vs the proposal to create all repos fresh.

UPDATE

Maintaining Forks
Pros:

• It is obvious then where the repo comes from
• We can check upstream regularly and contribute fixes to the original or pull updates from it
• It is more respectful for original makers, it lets the door open to a real transfer, looks less aggressive

Cons:

• Opening a PR for a branch on the fork (i.e. modulesync) by default is a PR against the upstream repo
• Code/issue/pr searches on the fork are disabled (unless the fork has more Stars than the parent)
• Issue/PR numbering starts over, only original IDs are tracked in history without any reference to the actual event

Starting Fresh Repos
Pros:

• All PRs default to being against our repo
• Search works, all the time

Cons:

• Signals an inability to migrate module, for whatever actual reason there may be
• Issue/PR numbering starts over, only original IDs are tracked in history without any reference to the actual event

[bastelfreak]

+1. A migration should be the prefered solution. And if that isn't possible we should use the described method from @rnelson0 and not an actual fork.

[roidelapluie]

Please talk to the Jenkins guys. They fork everything ans it seems to work.

[rnelson0]

Who specifically could we talk to? -- Rob Nelson

[roidelapluie]

@rnelson0 No idea. Maybe @daniel-beck can point us to the right direction.

Jenkins forks are searchable

What I have seen, for example:

https://github.com/voxpupuli/puppet-grafana/search?q=foo&type=Code&utf8=%E2%9C%93

"Sorry, forked repositories are not currently searchable."

And:

https://github.com/jenkinsci/jenkins/search?utf8=%E2%9C%93&q=foo

Which is also a fork but is searchable.

[roidelapluie]

Also, we should use forks because:

• It is obvious then where the repo comes from
• It is more respectful for original makers, it lets the door open to a real transfer, looks less aggressive

[roidelapluie]

Also, having a fork reminds us that this is not the original repo. Once in a while we can see if there is activity on the remote repo, and so do our users.

Without that, this will never be checked again.

[roidelapluie]

«PRs by default go to the upstream repo. Very easy to put it in and not notice for hours.»

Not true. PRs by default go to the repo you have forked.

[bastelfreak]

" it lets the door open to a real transfer," how should this easily be possible?

[roidelapluie]

It means that we still show that we hope to be able to transfer the repo. Creating a new repo sends the message: now we have our repo we are not interested in the transfer.

[rnelson0]

@roidelapluie Ah I forgot missing search. I'll google for that and then try to hit up @daniel-beck if I can't find a solution.

PRs only go to the fork if they're from a fork of it (i.e. rnelson0/puppet-grafana -> voxpupuli/puppet-grafana). Any PR from branches on that fork (voxpupuli/puppet-grafana modulesync) by default go to the original repo and must be changed.

I do like the pros of open door, I'll update the OP.

[roidelapluie]

Found it:

"repository forks will not be searchable unless the fork has more stars than the parent repository."

Looks like an acceptable challenge!

[rnelson0]

Ouch, that is very gamified. It feels wrong to star-bomb a repo just to enable searching it.

[roidelapluie]

It is perhaps the best they could came with.

[daniel-beck]

Right, this is how it works for jenkinsci – our repos generally have more stars.

I am proposing that when we perform such a fork, we create a new repo, rather than a persistent fork. … git push origin master …

If you go this route, I recommend git push --mirror origin to retain tags.

[rnelson0]

@daniel-beck Thanks, updated. What pros and cons have you experienced with maintaining forks?

[daniel-beck]

Well, it's only a fork in the sense of how it's implemented on GitHub, as it's almost all Jenkins plugins. Jenkins' plugin manager also has no native fork support, having competing variants of the same plugin makes no sense. So our situation is different from actual forks of other, independent projects.

FWIW in the past, there was confusion about where to file issues or PRs to what is the same project, just hosted in multiple places. So we started asking new plugin maintainers to delete their origin repo after we 'fork', converting the repo in jenkinsci into the root of the network graph.

[juniorsysadmin]

We can check upstream regularly..

I doubt this is going to happen

From our website:
"One of the benefits we hope to achieve is that by a shared ownership of modules we no longer end up in situations where the original maintainer has moved on and a forest of disparate forks try to fill the void."

The question is: Why is a forked repository being put under active maintenance?

Before this occurs one would think that at the very least:

• there have been active, repeated attempts to get the module author to transfer ownership
• there have been active, repeated attempts to get the module author to merge PRs
• possibly some other actions attempted as well

..it lets the door open to a real transfer

If the above steps have already been taken, I wouldn't be too hopeful.

[sacres]

I agree on @rnelson0 approach as well as @juniorsysadmin's comment

From our website:
"One of the benefits we hope to achieve is that by a shared ownership of modules we no longer end up in situations where the original maintainer has moved on and a forest of disparate forks try to fill the void."

This is truly what makes Voxpupuli, or any software a great project.. standardization.

[roidelapluie]

Okay. I agree that in this case (puppet-grafana) we have done everything we could, and that we can stop the fork and create a new repo. However I do not think we want to make that automatic. It would be something to be decided case by case.