Gatsby: Add a maintainers.yaml to root of repo that automatically gives maintainers rights to publish packages on NPM they maintain

[KyleAMathews]

As Gatsby grows, we need more maintainers to help keep all the nooks and crannies and roads and buildings of our far flung empire in robust shape.

AKA Kyle doesn't scale very far.

I think the main thing that needs done here is to just give y'all who are already helping maintain things more power and that let you and others who want to take different parts of Gatsby and run with them the ability to do so.

Anything else we need to do at this stage of things?

/cc @gatsbyjs/gatsby-core-maintainers @jquense @sebastienfi @fk @nicholaswyoung @jbolda @Khaledgarbaya and many others I'm not remembering at this time of night :-)

[Khaledgarbaya]

@KyleAMathews I love the idea and would be more than happy to continue helping

[secretfader]

This is an issue I've noticed across several monorepo projects, and a pattern I'd like to see implemented.

Do we need a formal process for releases? Does such a process already exist? Just to keep us from stepping on each other's toes, since more releases raise the potential for errors.

Also: I'm guilty of not doing all I can to ensure plugin functionality. To that end, I'd like to properly test and build sites with my plugins, but not just in dev: the ability to look at Netlify (which I think is on your radar, @KyleAMathews) would be huge.

[KyleAMathews]

@nicholaswyoung perhaps eventually we'd want a formal process (or just centralize releases on a release server) but for now, releases are uncommon enough that just announcing you're doing a release should be enough (and doing a git pull before hand). Lerna (our monorepo tool) is smart and figures out what packages need releases and what don't so even if someone tries to release something a second time, all that'll happen is Lerna will say a release isn't needed.

Also we need to modify the publish npm script so it only tries to release the packages a maintainer is maintaining.

[jbolda]

One other consideration, releases in each disparate part/non-core package seem to fit into the umbrella of at least one of the using-x examples. It may be worth considering having additional branches possible to cover each. Not only to @nicholaswyoung's point about stepping on toes, but it might make the CI more efficient. We currently only build Gatsbygram on every commit in appveyor. As Gatsby had developed, that footprint does not cover every package. We also build multiple examples on tag/release (actually this is broken, and really having a hard time getting it to work efficiently). This is rather inefficient as we miss things broken in packages that aren't touched by Gatsbygram, and may only be checked after a release. It seems crazy to build all the examples on every commit, but with multiple branches I know I could get appveyor to work nicely were we build everything on, say, a staging branch and only build the example of concern on each example branch.

Obviously the con is all the branching overhead. With development and release frequency decreasing and becoming more directed, it might be worth the pros to avoid broken releases. I suspect there is a happy medium worth exploring. In the context of maintainers, it might be easier to make clear to the users who is the "designated" maintainer of a thing rather then just pinging @KyleAMathews all the time.

[Khaledgarbaya]

👋
Releasing packages IMO is the hardest part and in my previous experiences was never 100% solved.
@KyleAMathews is releasing going to be time-based or feature based?

[0x80]

Just a quick note to say that I've been absent lately because of a client project with a pretty ambitious target 😞. I can't handle much else at the moment. I plan to get back involved halfway October 💪. Keep up the awesome work! ❤️

[KyleAMathews]

So I had a better idea. We should just setup a service which auto publishes packages on every merge to master. That's basically what I do anyways. And this way we wouldn't have to worry about giving npm rights and so on. Just merge rights.

And as this very nice article and anything else you read about continuous deployment will tell you, instant releases push you to continually make automated testing better and better which is what we want.

[Khaledgarbaya]

To automate the release we need to agree on a convention for commit messages, the most used one is the angular format, like feat(scope):..., chore(scope):...
I personally use that in combination with sematic-release and it's been working great for me.

But maybe I am old school and there is a better approach.

[secretfader]

I like @KyleAMathews CI suggestion, especially if it includes CD to npm. +1 also to @Khaledgarbaya's tip on semantic-release. It looks like a useful tool for standardizing commit messages that could possibly do even more for us.

[KyleAMathews]

I was referring automating publishing to NPM but agree automating releases announcements (on Github) + standardizing our commit messages would be really helpful. I was doing it manually but gave it up cause it was a ton of work.

@Khaledgarbaya can you describe the process to adopting semantic-release? Anyone else have experience using it?

[Khaledgarbaya]

The process using semantic release is very simple.
Every new features/fix etc is a separate branch after it gets reviewed, you rebase -i and clean up the history using the conventional commit messages. When the branch gets merged to master semantic release will check the diff and based on the commit messages will determine the next version automatically also it will generate a GitHub release, something like this .
Setup is very easy also
There is a nice video explaining the workflow.
https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release

[jbolda]

@Khaledgarbaya how does this work in the context of Github PRs? Do non-maintainers still just submit a PR to the main branch generally? (I haven't had a chance to watch the video yet.)

Speaking of branches, I think it may be worth considering having multiple branches (that could coincide with release tags). We could have branches such as stable, canary and future. It seems that CI/CD tend to have better support on a branch basis. We could run (and possibly prioritize builds) based on branches. Not that I want to use appveyor for releases, but I know it would make builds easier to breakdown there.

If we have a release tag, it might make it easier to test out core changes on a canary branch that people opt into using a canary tag. We partially do that now, but the canary tag isn't nearly as linear and is much more temporary/ethereal. Browser "nightly" builds are the model I'm thinking of.

[KyleAMathews]

Canary releases only make sense if you can get very quick feedback before rolling it out to production. I'd rather just publish changes immediately and continue to invest in our testing to make releases more and more reliable rather than introduce delays in moving improvements into production.

[Khaledgarbaya]

@jbolda we can limit the release to happen only in the master or production branch. so other contributors can submit a PR and once it is merged to master a new version will be released.

I think we can automate this in a way that it releases an RC when the code is merged to master and final release when the code is merged to production.

We can do this in two steps:

1. add the necessary configs to the repo which I can submit in a PR.
2. @KyleAMathews needs to add the GH_TOKEN and 'NPM_TOKEN' to Travis ci.

[KyleAMathews]

Let's try this! @Khaledgarbaya could you put together a PR setting this up for master and v2? V2 should be doing Lerna-style canary releases until we're ready to switch over.

This will be a huge improvement!

[KyleAMathews]

Oh we need to use this I believe actually https://github.com/atlassian/lerna-semantic-release

[KyleAMathews]

We've more-or-less solved this by giving @m-allanson & @pieh publish rights. Publishing to NPM is kinda fragile so we've decided to keep in manual for now.