Combine efforts?

[ghost]

Seems a bit pointless to maintains 2 "new" NZBGets. The other repo has more stars so perhaps it would be better to combine efforts with https://github.com/nzbget-ng/nzbget ?

[paul-chambers]

I've been keeping nzbget-ng/nzbget on life-support for over a year, since hugbug archived the original nzbget/nzbget repo, and all the fallout that caused.

I kinda 'fell into it' because I'd made the most recent pull requests at the time (before the repo was archived) and realised it wasn't going to be merged when hugbug archived it. So I pulled the other pending pull requests into my fork, and started trying to dispell the public's notion that the project was 'dead' (how can an open source project with 176 forks be 'dead'?).

There was (and is) a very active community of users, myself included, and I didn't want to see it 'die' because of an assumption the project had been 'abandoned'. But no-one was stepping up to maintain it. There have been plenty of posts on reddit from people reluctantly switching away because they'd assumed sanzbd was now the only game in town (nothing wrong with sanzbd, but going from a choice between two single-maintainer projects to only one isn't a good thing). Linuxserver.io's decision to drop their popular nzbget docker image just fueled this fire.

To be clear, it was hugbug's prerogative to move on; he put far more effort into it over a longer period of time than any of us had a right to expect. I see he's listed as a contributor to this project, does that mean he's reconsidered and actively involved again? that would be great news indeed.

I've never made a secret of the fact I don't have the time, nor breadth of OS development experience, to successfully maintain a complex multi-platform project like nzbget single-handedly. I'd hoped that other developers would pitch in, and I have received pull requests (thank you!). But I don't have the time to invest in actively building a dev community either, so I expect the few requests I put out there seeking help haven't landed on fertile ground.

I don't know the genesis of this repo, nor whether it incorporates the incremental updates contained in the nzbget-ng flavor, or if it's just the original nzbget/nzbget repo resurrected. I suspect the latter, going by the network graph.

I'm more than happy to point people to this repo from nzbget-ng/nzbget, and encourage them to redirect their efforts here. It already looks more active, has more than one maintainer, and I hope it stays that way long-term. All I care about is that the project remains healthy and active.

It serves no-one's interests to keep the repos running in parallel, so my main question is how determine what changes in nzbget-ng/nzbget have value for nzbgetcom/nzbget, and how best to merge them?

Please let me know - a few more pull requests turned up in the last week.

I'd also like to transfer over the current list of issues in nzbget-ng/nzbget to your repo, hate to see them drop on the floor.

Respectfully,

• Paul

p.s. if you'd prefer to talk privately, my github email is projects@bod.org.

[ghost]

Wow that was a very good and eloquent reply. Thanks. Curious what @phnzb will say.

[luckedea]

Hello @paul-chambers

Thank you! Myself and @phnzb and @dnzbk share your vision and passion about nzbget.

We started development by going through all open PRs and Issues from the original repository, and we we looked at nzbget-ng repository as well, and did our best to include changes from it! However with focus for v23 development we have to refactor many pieces (make it easier to maintain and move forward) - with so it's hard to just pick individual commits.

Your offer is really generous. We are willing to take any help - routing new PRs and Issues to our repository would be great. If you could share your experience and thoughts like you did with #67 - that's even better. That helps a lot.

v22 is a refresh and revamp of @hugbug's v21.
v23 is extensions-related rework including all relatively small features and bugs we would fit it. Coming up soon
v24 would include deeper improvements around performance and it would include leftovers from the backlog.

Saying all that to show that I try to address all issues arriving here quickly, or schedule it for future developments.

P.S. No, @hugbug's only visible here because this repository was recreated from original and includes his commits.

[paul-chambers]

Thanks for getting things on a firmer footing; frankly, I don't know how @hugbug did it alone for so long. I find it puzzling that he abandoned something he has put a lot of time and effort into without making an effort to pass it on to someone else gracefully. That's not 'the open source way', in my opinion. Though it's his prerogative, of course. I hope that it wasn't forced upon him by some significant event in his life.

I'm glad to hear that you've already adopted some of nzbget-ng/.nzbget's improvements. Nothing worse than seeing good stuff dropped on the floor.

I'll figure out what differences remain, and where it makes sense, we can discuss whether it's worth pulling across in its current form or if we should just solve it in a different/better-suited way for the current codebase in nzbgetcom/nzbget. I probably can't get to it immediately, but I am painfully aware that codebases diverge as time passes, and so the task gets more difficult...

Yes, it's an aging codebase that has clearly grown organically over many years. I agree; there's a dire need for refactoring in some areas (generally true for any non-trivial codebase ;) ). It's easy to arrive late to the party and be critical, but 'it still works' is a strong argument.

I have little patience for autoconf; it's always struck me as a major hack with a pretty bow glued on top. I'm glad to see you're already moving towards cmake. It has its challenges too, but it's a much better starting point. I'm pretty sure that some less portable parts can be dropped completely. For example, when the code works just fine without elevated privileges, it probably makes more sense to log a security warning when run with elevated privileges than to implement a non-portable method to drop them. Hindsight is always 20/20 ;)

In my opinion, there's a good amount of code that could/should be replaced with modern equivalents, like boost classes. Again, no criticism of @hugbug intended. It's easy to assume this stuff has always been around (and mature enough), and that's really not the case. It's easy to forget that kernel 2.6 wasn't EOL'd until late 2011, for example...

I'm glad my comment on #67 was helpful. I guess one consolation prize of developing software for as long as I have is you can't help but develop a better sense of the answer to the question of 'how hard can it be?' before you start trying ;)

I don't know how demanding my next job will be, so I don't know what kind of time I can commit, but I intend to 'pitch in' and hope you'll accept whatever help I can offer. We want the same things, and that's usually a good start.

[paul-chambers]

OK, the word is out - in r/nzbget, r/usenet, r/sonarr, and r/radarr, plus the readme.md on nzbget-ng/nzbget. That's probably all the high-traffic places. I'll set up a redirect from nzbget-ng.github.io soon, too.

[ghost]

Thanks for the work on NZBGet-NG @paul-chambers 💪🏻

[luckedea]

Thank you for all the work @paul-chambers
I also don't know how @hugbug was doing all that alone or not alone, it's mysterious.
But legacy of "most efficient usenet downloader" would remain :)

[zotabee]

There is also https://github.com/salami-ch/nzbget-win64

[luckedea]

@zotabee Well, we've set up our own build pipeline too, successfully covering win32 and win64 and multiple other platforms, so it's safe to assume we include the changes from designed to be in https://github.com/salami-ch/nzbget-win64 already

[paul-chambers]

I like that nzbget is moving to a cross-platform build tool. It's just too easy to accidentally break stuff in other platforms if you have one build mechanism per platform.

It's rare to find a good developer that fully groks all the differences between the platforms nzbget is built for.