Move to papertrail org?

[kenperkins]

So the reality is I don't have much dev bandwidth at this point, and I worry it's impacting users of Papertrail. So I'm wondering if we should entertain moving this to the Papertrail org so they can more directly solicit maintainers. @troy what do you think?

[matteocontrini]

There's just one thing to do now: publish the current repo to npm. I've been waiting for months with multiple applications crashing and skipping error reports. I know that I can pull the repository but the npm module is there for a reason!
I've also been planning to switch away from Papertrail, because I expect to have a tool that "just works" and that I'm sure to have support for it, considering that Papertrail is also a paid product.

[troy]

@matteocontrini Yes, this will get published to npm, probably very soon. The goal of waiting this last month was to ensure no new bugs were introduced.

Regarding support, speaking for Papertrail, we walk a fine line between (a) wanting to support everything because we all like to help, and (b) realizing that since Papertrail uses an open protocol (remote syslog), there will always be log senders we can't support (and sometimes that we've never even heard of).

Choosing the best option is more challenging here because:

• winston has a native syslog transport that works fine with Papertrail (winston-syslog), and
• Node itself works well redirecting stdout to a file or logging to a file, and that's an extremely reliable "IPC" method that Papertrail's remote_syslog2 collector supports really well (and that we put a lot of effort into)

In this case, I think winston-papertrail - or really, Node - has migrated from a small library created by a passionate user to something used by enough people that it needs regular maintenance, if not support. We're adapting, as you can see from my involvement (PR comments and merges) in the last 6 weeks. I don't want to rush it and create a new set of issues.

At the least, we do need a reliable, surprise-free, easy, documented way to send logs from Node, and whether that ends up being winston-papertrail over the long term, we'll do so. Right now, that means letting the release candidate run in lots of different environments. My guess is that a release of master will go to npm later this week or next week.

Finally, thank you for your help with all of this. I really appreciate it.

@kenperkins: please see my email yesterday.

[matteocontrini]

@troy sorry to insist, but it's been months and every time you say "next week". But that week never came...

[troy]

@matteocontrini you don't need to insist. I emailed @kenperkins 2-3 weeks ago for NPM access and he hasn't responded. I don't have permission to push to NPM, so I should have set a lower expectation to you: it'll be released when I can actually push a release.

Otherwise, continue running master. I don't consider it awful or particularly bad to need to run a release from GitHub instead of NPM.

Beyond that, recall that our involvement was trying to help, not because we wrote this module or knew Node's syslog support. That is, I'm doing the best I can as an outside contributor who fell into a new project, just like you :)

[matteocontrini]

@troy sorry, I didn't know about the npm permission "issue".

Anyway it's not a problem of me not wanting to use master. The problem is that the npm module is outdated but downloaded by thousands of people that probably don't know about the recent improvements in mater.

https://npm-stat.com/charts.html?package=winston-papertrail

[troy]

@matteocontrini it's definitely improved, but keep in mind that the vast, vast majority of those thousands of downloaders will never encounter the cases which are improved in master. That's particularly true now that the readme explicitly gives an example how to handle connection failures (like if a machine loses Internet access): https://github.com/kenperkins/winston-papertrail#usage

The impact of the improvements to master is pretty small. They're important because making life easier for even one person is worthwhile (and there's not much left to do - literally just pushing a release), but it's not something that's nag-worthy.

[matteocontrini]

Well, as far as I remember, with the current npm version, this code submits "false" to Papertrail.

logger.error(new Error('hello'));

I know we have different opinions, but when unofficial forks start to appear as "enhanced" or "fix" modules without merging back to the original module you know there's something wrong going on...

https://www.npmjs.com/package/winston-papertrail-enhanced
https://www.npmjs.com/package/winston-papertrail-fix