Packages needing a maintainer

[Arcanemagus]

The following packages appear to not have an active maintainer, we would welcome people to step up if interested and would gladly help with any questions you may have 😉:

• linter-bootlint
• linter-scalac
• linter-erb
• linter-puppet-lint
• linter-shellcheck
• linter-lua
• linter-jshint

[Arcanemagus]

@dhagerty9009 are you still interested in maintaining linter-reek?

[Arcanemagus]

@jschroeder9000 are you still interested in maintaining linter-haml?

[Arcanemagus]

@jarig and @ndobson are either of you still interested in maintaining linter-foodcritic?

[Arcanemagus]

@kavu are you still interested in maintaining linter-golinter?

[dathagerty]

I am still interested in maintaining linter-reek.

[Arcanemagus]

Cool, thanks!

[kavu]

@Arcanemagus I am interested, but I am not sure I could keep up with current AtomLinter development, its change APIs and concepts. So, I will be glad if someone will keep an eye on the Go linters. I hope my contributions will be still welcomed.

[steelbrain]

@kavu Just a side note that there has not been any API breaking change in the last six months. We would love to keep you all involved in this, the purpose of this thread is to find repositories who have inactivate maintainers so we can put them up for grab by other people interested in them.

[Arcanemagus]

@kavu of course! Just was tagging people listed as maintainers with greenkeeper PR's that haven't been dealt with in 5 days 😉.

[kavu]

@Arcanemagus oh yeah! Greenkeeper is bothering me a lot, to be honest 😃 Especially when I am not sure if it will really break package, or not 😆

[Arcanemagus]

If you add specs and enable CI builds it virtually disappears. It only puts up a PR if one of the following conditions are met:

• The build is broken due to the updated dependency
• A dependency published a version outside your currently allowed range
• I has no specs telling it whether the build is successful or not

Right now your package is falling into the last category, since it doesn't know whether the update still works for your package it sends in a PR telling you something needs your attention since it could be broken.

If you want help implementing specs just say something, I can try throwing some basic ones on there for you if you need it.

[kavu]

@Arcanemagus yeah, it will be great! Also, could you reference me a magnum ops linter specs. Maybe not the most complex one, but proper.

[Arcanemagus]

@kavu linter-eslint is probably one of the most complete specs that I know of, simple stuff like linter-erb is enough to get the basics covered though.

[ndobson]

@Arcanemagus yes I'm still interested in maintaining linter-foodcritic. I'll look into the pr's and adding specs asap

[Arcanemagus]

@ndobson When you get a chance is fine, just hadn't seen any activity in a while 😉.

[Arcanemagus]

@park9140 are you still interested in maintaining linter-tslint?

[park9140]

@Arcanemagus, interested, occasionally. Have time? No not really.

[Arcanemagus]

@park9140 Perfectly understandable, for now I'll put it on the list but leave you listed 😉.

[Arcanemagus]

@trevershick are you still interested in maintaining linter-clojure?

[Arcanemagus]

@artoale are you still interested in maintaining linter-gjslint?

[artoale]

Yup, sorry - just been very busy catching up with work after the winter
period - will start writing specs soon!

On Tue, Jan 26, 2016, 00:37 Landon Abney notifications@github.com wrote:

@artoale https://github.com/artoale are you still interested in
maintaining linter-gjslint https://github.com/AtomLinter/linter-gjslint?

—
Reply to this email directly or view it on GitHub
#10 (comment).

[Arcanemagus]

@artoale No problem, just checking on the listed maintainers to see who is still active 😉.

[artoale]

Eheh - sure thing! I've been pretty quiet lately, it only makes sense to
check!

On Tue, Jan 26, 2016, 00:40 Landon Abney notifications@github.com wrote:

@artoale https://github.com/artoale No problem, just checking on the
listed maintainers to see who is still active [image: 😉].

—
Reply to this email directly or view it on GitHub
#10 (comment).

[Arcanemagus]

@florianb are you still interested in maintaining linter-javac?

[trevershick]

Yep.

[Arcanemagus]

@trevershick Cool, if you want help implementing specs so the greenkeeper PR's aren't as noisy just say something and I'll throw some basic ones up there 😉.

[jschroeder9000]

@Arcanemagus

Yes, I am still interested in maintaining linter-haml. :)

I'll admit I've been doing a pretty poor job of it lately. :(

I also have to admit I have mixed feelings about greenkeeper. The chore prefix that it adds to commits seems aptly named... it seems to have created a lot of busywork. My understanding is that with ci/specs implemented it will not create a PR and just automatically push a commit that updates the dependency version. But that adds a ton of noise to the commit history. If I understand further, that can be somewhat mitigated by specifying looser dependency version ranges.

I don't mind a kick in the rear to get things up to snuff (no question I should add ci/specs), but I'm not entirely sold on the idea of greenkeeper. Best case scenario my specs are able to catch any possible regression or breaking change in dependencies and nothing breaks. My experience is that usually specs do catch such things (if done well), but not always. The benefit is... not getting left behind? Not missing security updates? End user isn't stuck with dozens of versions of the same dependency? I don't hate the idea, but I'm not really loving it, either. If I can get it to not generate commits for every patch release of every dependency then I guess I can live with it.

Back to specs, I am aware #11 has a few packages checked off that have implemented specs and I will take a look at linter-eslint and linter-erb as well. If there's anything else I should look at for examples of good practices, I'd appreciate being pointed in that direction.

Thanks for checking in. :)

[Arcanemagus]

@jschroeder9000

Greenkeeper doesn't automatically push anything to master. From what I have seen of how it works this is it's process:

• Grab a list of a project's dependencies when enabled
• When first enabled check the currently allowed versions and see if there are newer ones available, if so create an "Update all" branch to bring the project current and send in a PR from that branch to master.
• Monitor the list of dependencies for any updates
• When an update comes in for a dependency create a branch for that update:
  • If the version is outside the allowed range create a PR to master for the update
  • If the project doesn't have CI builds enabled, create a PR to master for the update since it has no way of knowing if the update breaks things or not.
  • If the project has CI builds enabled, fire off a build of this branch, if the build succeeds do nothing further (This is the ideal end point, and where most updates end up, unfortunately it seems to leave this branch around for now with no notification it is created)
  • If the build fails for any reason, send in a PR to master stating it breaks the build.

As for the benefit, it depends: At it's most basic this just ensures that your allowed ranges of dependencies includes the latest version, and that users shouldn't be getting a broken package when they install it due to a newer version being potentially broken for your package. Overall more comes into play: Keeping most things current on the version(s) of atom-linter that are installed on a system comes to mind.

As I've said a few times earlier, this is mainly just a ping to see what's up and weed out people from the list of "active" maintainers that haven't been on in months, so you are doing fine 😉.

[jschroeder9000]

Thanks for your explanation, @Arcanemagus, that's really helpful. I hadn't considered that with a looser version range greenkeeper could test newer versions within that range and do nothing if the specs pass, but warn you if they do. That's actually pretty cool and leans me a little more in its favor. It's a shame it leaves dead branches, though.

[Arcanemagus]

It's odd, sometimes it deletes those "success" branches, sometimes it doesn't.

[Arcanemagus]

@jemerick are you still interested in maintaining linter-pep8?

[florianb]

@Arcanemagus: thanks for getting back to me, some time has gone since my last contribution and as far as i can tell after a quick look, a lot has changed.

I'd like to give it another try and maintain https://github.com/AtomLinter/linter-javac again.

Is there a Gitter/Slack channel for the maintainers?

[Arcanemagus]

@florianb Yep, we have #linter-plugin-dev on Atom's Slack 😄.

[jeffwidman]

@Arcanemagus if you still need a maintainer for linter-pep8 I'd be fine helping out occasionally. Not so much as lead maintainer, but more as someone on the team who can help triage issues and review/merge PRs as they come in. I primarily use linter-flake8 myself, but happy to help with any python-related linters.

[Arcanemagus]

@jeffwidman Thanks, I'll add you as a collaborator!

[ricardograca]

@Arcanemagus I think you can cross linter-erb off that list now.

[Arcanemagus]

This whole list needs reworking, thanks for reminding me though!