@sstur I've setup the CI/CD this way that from my repository it will still release a new version whenever I push to my own master. Github action result
For any other repository it only executes the tests and uploads the tarball of the package to github artifacts.

The conflicts are because 2 files changed on both sides, but you should be able to accept my version.

Hi! Seems like @sstur didn't find time to deal with the merge. Would you mind rebasing it on master? That way I might be able to test your PR, which might lower his effort to merge.

@mk-pmb I invited you to my repo. Currently not using it anymore so my drive to bring all my changes to this repo has been lowered.

Thanks! Unfortunately I can neither publish nor support that branch, because the author change makes the license implications a bit complicated. Would you mind if I make a copy that degrades your attribution to just contributor?

And then I discovered that even that would make the license non-trivial if I do it. Instead, could you publish a branch based on master where you just copy your new files, but without the author change anywhere in its history?

The author change can be reverted, but it's there because that branch is published to @svrooij/ftpd on npm. Will try to see if I can fix that issue

Since I now read in the other thread that you already moved on, I hope someone else can step in to try and salvage as much as possible, with a keen eye on proper attribution of the parts picked. Here's what I drafted earlier:

can be reverted,

IANAL but for my understanding this would keep some commits in our history that create at least ambiguity about their license. I'd thus strongly prefer a new branch based on master that re-commits only the parts relevant for how the ftpd works, and does not (yet) deal with publishing.

I had expected the fix to be as easy as making a new branch that just omits the commits that deal with authorship and publishing. So I tried to suggest the sequence of git commands that you could run to create that new branch that we could merge. Unfortunately, it's not that easy.

The problems with the patches in this merge request start as early as e18e3d9 , which claims in its commit message to be just a "Version bump", but has massive changes to lots of code files. It seems like most of them are just whitespace changes. In such a case, the whitespace changes should go into their own commit, so we can easily have git diff verify that nothing was changed except for whitespace.

Next up 8318301 , "Added npmignore". The commit message should probably have been something like "Ignore test directories", if that was your intent. However, the lack of leading slashes makes it hard to predict what will be ignored, and poses a trap for future development. We can only accept .gitignore files that are easy to understand.
Their entries should be grouped, each group starting with a comment that gives a title (e.g. "auto-created files", "temporary files", …) and if the title doesn't obviously justify why to ignore them, reasons.
All entries should be as specific as possible, which usually requires at least a preceeding slash, to limit them to the directory of the .gitignore file.
They should have an empty last chapter to help detect accidential uncategorized additions.
And as all text files, they should have a trailing newline, to reduce the git diff impact of lines added.

Stopping the review here for time reasons. I wish I had been able to review this way earlier, and could have saved some of the work that has now accumulated for fixing such issues and extracting the useful parts.

I'm unsubscribing, as said I moved on.

I'm not forcing anybody to do stuff they don't feel like. 3 years ago I made this PR, because the released version was lacking some features.

I'm all for automation, that is what I also do in my day-to-day job. If that's not your thing that is totally fine.

Use my code, or don't, feel free to do what is best for the project.

I’m cleaning my stale prs