Migrating to `env-logger-rs` GitHub org

[KodrAus]

In #159 we brought up the possibility of moving env_logger into a dedicated GitHub org. I've gone ahead and created one at https://github.com/env-logger-rs

Let's use this issue to track the things we need to do to get the migration ball rolling.

TODO

• Move the repository into the new organization
• Add a Code of Conduct (I usually use the one from the Rust project)
• Migrate CI to GitHub Actions
• Create a team with publish rights to crates.io
• Decide on triage / merge procedures
• Publish a new release with updated repository links and CI badges
• Set up any app integrations we'd like (bors?)
• Invite collaborators who might be interested in helping support the project

[jplatte]

I'd be happy to help maintain the project :)

Migrate CI to GitHub Actions

Why?

[mainrs]

@jplatte From my personal point of view, I do like that it is closer integrated into GitHub as other CI services. It doesn't require additional rights management or hacks like some other CI that do not pick up on the owner group of repositories. Publishing artifacts does require workarounds on same CI platforms. Less setup is required (like generating tokens for all kind of services you access). GA provides one by default that you can use.

CI is mostly done in #164. There are some open points left though.

[jplatte]

closer integrated into GitHub as other CI services

This is pretty much one of the reasons I don't like it 😅 It increases vendor lock-in.

It doesn't require additional rights management or hacks like some other CI that do not pick up on the owner group of repositories. Publishing artifacts does require workarounds on same CI platforms. Less setup is required (like generating tokens for all kind of services you access). GA provides one by default that you can use.

All of this seems irrelevant for env_logger. Am I missing something?

[mainrs]

This is pretty much one of the reasons I don't like it 😅 It increases vendor lock-in.

I totally get that. In a perfect world I'd be hosting my own git servers and CI runners using GitLab for example. But I do think that it makes collaboration easier. These are my two cents:

A lot of new projects just use GA as it's provided by the same people, the integration is nicer and tighter that way. Newer people will probably learn GA first before using something like Travis or Appveyor nowadays. And for exactly those people collaboration is way easier that way, which is one of the goals I try to reach with open source software.

All of this seems irrelevant for env_logger. Am I missing something?

I wouldn't say irrelevant. Back when I used Travis before moving to GitLab only the owner of the repository could do stuff over there for example. And each change to the configuration (adding new environment variables for example) has to be done through the owner itself.

This is just one example though that happened to me often enough to be annoying. Especially when the owner isn't active anymore but other people have push rights. There are probably pro and cons in both directions :)

I also do use GA for all my GitHub projects. It's just easier, more convenient and writing custom actions is A LOT easier in my opinion than writing some weird bash scripts like I did during my GitLab days.

[KodrAus]

@jplatte That's a fair question. My motivations for GitHub actions are:

• To be closer to the CI used by rust-lang projects.
• So that we can test on Windows and other platforms using a single CI service.
• So that collaborators automatically have permission to change CI itself (this isn't the case with AppVeyor unfortunately, CI the account runs under is owned by an individual).

It's always nice to be mindful of vendor-lock-in, but since all CI does is run cargo commands I'm not personally worried about it.

[jplatte]

It's just easier, more convenient and writing custom actions is A LOT easier in my opinion than writing some weird bash scripts

I feel exactly the opposite way. From my perspective GA is overengineered, under-documented, and I've generally had a bad time using it. Bash is not a perfect language by any means, but at least you can easily run it locally and there's tons of resources about it.

So that we can test on Windows and other platforms using a single CI service.

I thought travis also supported Windows now?

Anyway, I think I'm clearly on the loosing side of this here with the amount of projects switching to GA already and both of you wanting the switch, so carry on. I'm still interested in helping with CI-unrelated maintenance tasks :D

[mainrs]

@jplatte Are you still interested in maintaining the crate with us? I can send an invite over in that case :)

[jplatte]

@sirwindfield KodrAus already invited me on Monday ;)

[mainrs]

Btw, maybe a logo might be cool to have! Anything is probably better looking than the default GitHub one 😄 I did one in Affinity, if you guys like it I can add it to the organization.

Just an idea though :p

[mainrs]

Interest in bors? Might be overkill tbh, because the CI runs again when you rebase the PR. But on the other hand, we doun't have to rebase ourselves then.

I can setup badges and clean the readme a little bit. I will add issue templates as well (bug/feature) so people can choose one when they create an issue. Out of experience however, 99% of the people just ctrl-a delete it so 🤷

Edit: #176 #175

[mainrs]

Concerning PR merges. I’d like to propose that each pr is reviewed by one of the maintainers. Meaning that no one merges without a review of another one (not like i did today :( )

[mainrs]

The publish rights for crates is probably have to be provided by the original maintainer to us. Not sure if you already have some @KodrAus

[KodrAus]

So it turns out I'm not actually an individual owner of the crate so can't add our Publishers team to it.

@sebasmagri when you have a chance would you be able to run:

cargo owner --add github:env-logger-rs:publishers

in the repo to give the team publish rights?

[jyn514]

ping @sebasmagri :) it would be great to have a new release of env_logger.