We shall not use fork of mibk/dupl

[iwankgb]

We shall not use fork of mibk/dupl.

[ldez]

Hello,

could you explain why do you say that?

The repository https://github.com/mibk/dupl didn't receive any update since Oct 11, 2018

mibk/dupl@master...golangci:master

In your PR mibk/dupl#18, you say:

golangci-lint community is in the process of moving away from forks towards upstream versions of all existing linters.

Could point to me the reference for that decision?

[iwankgb]

I say that because the fork is even more outdated (last commit from upstream is dated for November 2017).

I can't point you at exact decision as there is no process for making such that I'm aware of. I was involved in two issues where users requested updates to linters: it'a easier to keep them up-to-date if we don't have a fork in between.

[iwankgb]

See #1495 for example.

[ldez]

Maybe it can be a good thing to open a discussion here: https://github.com/orgs/golangci/teams/team/discussions

[iwankgb]

If you think that it is bad idea - initiate a discussion please. I will take lack of disapproval for approval.

[ldez]

I just react to the fact that you express a golangci-lint community decision.

We shall not use fork of mibk/dupl is a strong assertion, IMHO a strong assertion requires a strong agreement.

Using less fork can be a good idea or not: it depends on the activity of the project, the type of the project, etc.
I'm not sure that we can create a global rule about the use or not of forks.

I think that, at least, we have to document why we are creating/using a fork instead of the original project.

[iwankgb]

I just react to the fact that you express a golangci-lint community decision.

You are right, I should have not said it. The description has been rephrased.

We shall not use fork of mibk/dupl is a strong assertion, IMHO a strong assertion requires a strong agreement.

It is. And I'm strongly convinced that using forks where that do not have (substantial changes, fork being maintained more than the upstream) to be used is bad idea.

I'm not sure that we can create a global rule about the use or not of forks.

We can't. There are forks in golangci organization that differs far too much from upstream (see: #1517).

I think that, at least, we have to document why we are creating/using a fork instead of the original project.

As far as I understand the (undocumented) reason for forking some of the linters was lack of ability to use them as library. I am aware of one exception at the moment. Majority of the forks were created in May-June 2018 and I think that person creating them was focused on adding more linters quickly (I'm judging it by character of changes).

[ernado]

In general we should remove forks in favor of upstream dependencies if possible.

I think that person creating them was focused on adding more linters quickly

Yes, it is correct. There were two reasons of forked dependencies: we were unable to use them as a library or they were too slow.

[iwankgb]

It is. And I'm strongly convinced that using forks where that do not have (substantial changes, fork being maintained more than the upstream) to be used is bad idea.

Or upstream being abandoned.

[ldez]

Related PR mibk/dupl#18

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.