State of project

[silverbucket]

Hi Marty, I was wondering what the state of this project is? It's a great little module and I'd love to see it more feature complete. There are several pull requests but no activity for 3 months.

Perhaps there are people who've submitted pull requests who be willing to help maintain the package if you're too busy?

[jfhbrook]

I'd support getting an outside maintainer as well. If I wasn't already behind on my own project maintenance I'd totally throw my hat into the ring.

[silverbucket]

Me too, I'm quite busy at the moment, but might be able to help review pull requests at the very least, so we get some of these pending contributions merged.

I'd be worried about regressions though, as there seem to be tons of pull requests pending.

[jfhbrook]

We can mitigate regressions by beefing up the test suite.

[osslate]

I would be interested in taking charge of the project, though I have a slightly different idea as to how it should work. Keeping in with what a lot of libraries are doing now (and something I quite like), separating socket handling (which should be done by the user) and handling (which should be done by the library) is something I'd start off doing.

I've already started creating modules - if something isn't done with node-irc, I'll most likely start writing my own library. I already have the best implementation of a message parser in JavaScript, adding handling logic isn't very hard. ;)

[silverbucket]

@martynsmith would you be willing to create an org account to move the repository under? I'm happy to have @expr take over maintenance and help out where I can.

If not I guess we can just use @expr's new library, but it would be nice to build off the existing work, and maintain somewhat of the same API. @expr would that be possible with your new internals?

[osslate]

It would be somewhat possible... I guess we could iterate fast and change the API, or create a branch for version 2.x.x.

I might take a stab at implementing a client library to see how simple it is.

[jfhbrook]

I don't think we need an org, just added collaborator(s).

[martynsmith]

Yeah, I think realistically although I keep having the best of intentions
with regards to catching up, I tend to burst every 6 months or so to clear
the backlog, then things fall in to disrepair again.

It's not really a sustainable model.

The problem I have is that I have no sane way to vet people or choose a
co-maintainer. I'm open to suggestions though (and volunteers).

Martyn

On Wed, Dec 11, 2013 at 8:40 AM, Joshua Holbrook
[email protected]:

I don't think we need an org, just added collaborator(s).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/213#issuecomment-30260498
.

[osslate]

I'll definitely volunteer to help maintain the project. I know a lot of people that use this module, it's not ideal for it to be left in the dust for so long.

[jfhbrook]

Martyn, do interviews!

On Tue, Dec 10, 2013 at 12:45 PM, Fionn Kelleher
[email protected]:

I'll definitely volunteer to help maintain the project. I know a lot of
people that use this module, it's not ideal for it to be left in the dust
for so long.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/213#issuecomment-30260932
.

[silverbucket]

@martynsmith - just want to ping you to hopefully get a fire going on this. I think if @expr is willing to co-maintain this and @jesusabdullah and myself willing to help out when we can, we could hopefully make some steady progress.

I propose an incremental approach to improving the library without causing backward incompatibility. The first step would be to review all the pull requests and merge in @expr 's messaging library to work under the hood. Then if @expr can think about the parts he'd like to re-write / improve while maintaining backward compatibility I think that'd be superb.

What do you think? I'd really like to see this library snap back to life. It's not good when there are tons of forks with changes that aren't being merged back, and no single replacement either. I'd like to stick with this one if possible and at the very least accept pull requests to keep up to date with the forks.

[osslate]

I'll probably write my own IRC library sometime. There are people more equipped to maintain node-irc than I am; I also have school, exams etc.

[silverbucket]

@expr - ah, that's too bad, but I look forward to seeing what you create. Ping me when there's a repo to watch.

@jesusabdullah - what do you think about co-maintaining? even if it's just pull request review and merging? I could help out as well. @martynsmith would that be OK with you?

[cyrusdavid]

Does someone have a fork of this project which is actively maintained? 24 pull requests pending.

[silverbucket]

@vohof I haven't been able to find a definitive, active, fork - seems there are a lot of forks, each with their own needed fixes made, but none of them share their fixes or are merged back here. So there's really no clear replacement. I'd really like to see this project get another maintainer to merge pull requests, as this library needs some love at the moment.

[Havvy]

I can vouch for jesusabdullah and expr as responsible programmers. I don't know who silverbucket is, so I can't vouch for him.

[jfhbrook]

I'll take whatever votes of confidence I can get.

[katanacrimson]

Whoever's going to step up, just fork it and start looking at PRs, try merging them out and demonstrate that you're capable and can get the job done anyways. No votes or vouchers or crap, just prove that you're able.

[silverbucket]

Hey guys, just as an aside note, I've since switched to the newly developed irc-factory which is working great for me.
https://github.com/ircanywhere/irc-factory

[folletto]

Unfortunately irc-factory has shifted to an interface that's too cumbersome. Multiple clients? Forks? IDs? hookEvent? eww

I'm using node-irc because it has a clear and uniform API, and it doesn't seem to me that any of the other forks I've seen is trying to keep this principle in mind... given also that this very principle is what made this library successful in the first place makes moving away a lot of rework. ;)

@martynsmith if I can give an advice: get a couple of people (the two mentioned above?) and make them work on a separate "future" branch, so when you have that burst of time you can review. Working on a branch will keep the community up-to-date and the project running, while at the same time giving you enough space to build the trust with the added maintainers. It's a win-win scenario. :)

[silverbucket]

@folletto you don't have to use any of those additional features, I don't, in which case it behaves quite similar to node-irc.

[folletto]

I'm not sure. The tutorial there already has factory, create client, an "id" all in the first three lines of it and then uses hookEvent() with that same id (but didn't I create a client object?). If that's not the basic, it's definitely confusing and unnecessary complicated. :)

Is there a simpler way to do things more in line with node-irc?

[silverbucket]

@folletto we probably shouldn't spam this thread with discussion about irc-factory but it's quite simple to get started with just createClient hook/unhookEvent (which is basically like add/remoteListener). You can see that here:
https://github.com/sockethub/sockethub/blob/master/lib/platforms/irc.js#L576-L589

[folletto]

@silverbucket Well not really... ;) ...Ok, I won't proceed further. I feel this exchange has been valuable still to get a reasoning of why node-irc is valuable to be maintained tho. ;)

—

The suggestion of adding maintainers on a separate branch to build the necessary trust stills stands. ;)

[seiyria]

I, too, would be in favor of having any activity at all on this repo. I'm currently using it in a project but was initially skeptical to use it due to the backlog. Unfortunately or not, this was the overall best library that node had for what I needed.

[katanacrimson]

Again, do a fork and work on it there, get a branch in working order, call it stable and open a PR with this repo to have it merged in for a full release - until @martynsmith can merge it, just publish it under a different package name or something, or just have people use the git repo itself as a npm dep.

[folletto]

@damianb Yes. The risk is that if he doesn't find time, we'll just get another fork. Again. As all the others out there.
So it's clear why people would like some kind of endorsement and keep coming back with this questions.

Now, I agree with you that working on the code and doing PR helps demonstrating the technical skill and that the person alignment of philosophy, but that alone is just half of the game. We really need @martynsmith endorsement to move things. Hence the requests. :)

Opensource is as much code as it is trust. :)

[seiyria]

@damianb Any issue I currently have is already addressed in another pull request or issue; creating another fork and sending my own fix would solve nothing and create another problem. I'd rather not put that burden on @martynsmith -- he appears to have a lot on his plate already.

[rickihastings]

I know this discussion is pretty much dead, but just stepping in to address the comments @folletto had on irc-factory, it's really not designed to be a replacement for node-irc. You can use it with single clients sure, but it's goal is to be, an IRC client factory. node-irc becomes a nightmare when you're handling more than one client, keeping track of them, and handling some of the more annoying tasks - booting hundreds of client up in an IRCCloud fashion, and list pagination.

But to not fully digress, I think a rewrite from scratch would be a better idea using similar design goals and patterns, with a full test suite implemented.

[cyrusdavid]

It looks like slate/slate-irc is a more actively maintained and developed IRC module alternative.

[folletto]

Thanks @rickihastings, that's precisely what I meant. ;)

Thanks @vohof, I'll check that. :)

[seiyria]

Another alternative is being developed currently as well: rahatarmanahmed/node-irc-client.

[osslate]

Sorry to have to bump this issue. As I have a ton more time over the next year or so, I'd love to boot back up this project.

I emailed @martynsmith a few months back with no reply, hopefully he can reply here. My plan is to sift through each open issue and release a series of backwards-compatible bug fix releases for node-irc in it's current state, whilst also working on a separate branch to rewrite the entire library, with the aims of:

• Creating a cleaner interface to deal with IRC, using newer node APIs wherever applicable (including Streams).
• Making IRCv3 support a first class citizen. As an active member of the IRCv3 working group, my knowledge of the specifications are extensive, and with every major and modern IRCd supporting IRCv3, developers can avail of new features straight away.
• Making sure the library is well-tested. Only 100% test coverage will do. There seems to be a lot of bugs in the current release judging by the issues, and whilst keeping in mind that IRC is at times an unreliable protocol to deal with, testing removes a lot of possible errors.
• Staying on top of pull requests and issues, so the project doesn't experience half year bursts to clear the pile. This isn't an effective way to manage any open source project.
• Modularising chunks of the library when possible to fit in with Node's ecosystem. I've already written (possibly) the most efficient IRC parser in JavaScript with IRCv3 message-tags support, irc-message, and this can be thrown into applications wherever it suits. If it's possible to split out the library into other modules in a logical way, go for it.

This library is way too popular for it to be neglected, something needs to be done. It's still the go-to IRC library for node, even though great alternatives exist. If people are interested in this happening, and @martynsmith is fine with giving me push access and what have you, I'm totally up for it. Assuming my idea went ahead, I'd love to have other people on the team, too.

[martynsmith]

Okay, I've been completely useless over the past year or so.

I always have the best of intentions to get back in to things, but realistically I don't see it happening.

@expr - I'll give you push access to the project, it sounds like you're keen to get things moving again.

I'm always happy to help out where I can, but really, I just don't have time to sift through everything that's built up :-(

@expr - If you wanna chat, I'm Ned on irc.dollyfish.net.nz or Ned_ on freenode.

[alxgnon]

I'd love to see this project grow new wings, and I'll be sure to help out! Monkey patching the library to suit my needs works, but I'd rather see it be feature-complete by default. Also, 100% coverage would be really great.

[osslate]

For anyone still interested in the library, please check out issue #238.