Add MAINTAINERS file, a user guide to code subsystems #7005

jgarzik commented at 3:33 PM on November 13, 2015: contributor

This is a guide to steering contributions to specific maintained areas of the codebase.

It is also useful as a status list of various code areas - in the future, we'll see maintainers disappear, code go unmaintained, newbies arrive and pick up code, etc.

Add MAINTAINERS file for specific subsystems and areas of code. 41657b4505

in MAINTAINERS:None in 41657b4505

   9 | +1.	Always _test_ your changes, however small.
  10 | +
  11 | +2.	Try to release a few ALPHA test versions to the net. Announce
  12 | +	them onto the bitcoin-dev channel and await results.
  13 | +
  14 | +3.	Make sure your changes compile correctly in multiple

jonasschnelli commented at 3:41 PM on November 13, 2015:

Maybe add something that it's possible and trivial to enable Travis on the users bitcoin-repository fork, so one can test the changes over Travis even before open a PR on bitcoin/bitcoin?

paveljanik commented at 4:14 PM on November 13, 2015: contributor

Well, I think something like this is needed but maybe not that verbose. On the contrary Qt GUI entry looks good to me ;-)

I think there is no need to mention explicitly the Git/whatever tree type etc. Maintainers should work on GitHub. Patches should be PRed not published to mailing list (if you want to "publish them" first, lets mail the link to the branch) etc. The workflow is GitHub centric... If there is anything specific about particular maintained area, lets describe it, but...

Or do want e.g. Jonas to create its own maintained Qt GUI tree and then him to PR the changes (like @theuni 's trivial tree)?

paveljanik commented at 4:15 PM on November 13, 2015: contributor

I miss the list of GitHub tags for the specific area (helps with the area identification in the PR and Issues).

laanwj added the label Docs and Output on Nov 13, 2015

in MAINTAINERS:None in 41657b4505

  22 | +
  23 | +	PLEASE check your patch with the automated style checker
  24 | +	(clang-format) to catch trivial style violations.
  25 | +	See doc/developer-notes.md for guidance here.
  26 | +
  27 | +	PLEASE CC: the maintainers and mailing list on your changes.

luke-jr commented at 10:30 PM on November 13, 2015:

I don't think we need a mailing list post for every merge request... especially considering the ML is for Bitcoin, not Bitcoin Core.

in MAINTAINERS:None in 41657b4505

  69 | +
  70 | +Maintainers List (try to look for most precise areas first)
  71 | +
  72 | +		-----------------------------------
  73 | +
  74 | +QT GUI

luke-jr commented at 10:31 PM on November 13, 2015:

Qt is not uppercased.

luke-jr commented at 10:31 PM on November 13, 2015: member

Shouldn't we add the rest of the maintainers to the initial list?

jgarzik commented at 12:01 AM on November 14, 2015: contributor

Thanks for the comments. Agree with almost all from @luke-jr @jonasschnelli @paveljanik. Will revise.

RE @luke-jr "Add the rest" -- this list is for specific areas of where people are proactively making a commitment to maintain.

luke-jr commented at 1:53 AM on November 14, 2015: member

@jgarzik Yes, for example, I maintain the Mining area. I'm not sure who else maintains what, but I would be surprised if it was just Jonas and I.

jgarzik commented at 2:00 AM on November 14, 2015: contributor

@luke-jr Awesome -- and I would propose to merge this as-is, and request that you submit a pull request to add that section - crypto-volunteerism that creates a nice audit trail along the way.

That's what should happen moving forward -- patch MAINTAINERS -- and it's better than continually revising this PR.

laanwj commented at 6:40 AM on November 14, 2015: member

Concept ACK, but yes remove mention of the mailing list. We have no mailing list for submitting patches, and using bitcoin-dev for this would not be appreciated. In cae of security critical issues it's better to mail the maintainer directly.

ACK on mentioning @luke-jr as mining maintainer. He's always been one of the few miners actively involved with development. Also needs @theuni as Build system Maintainer.

Edit: it should also mention src/univalue, src/leveldb, which fall outside maintenance of this repository, and refer to the upstream repositories.

gmaxwell commented at 8:41 AM on November 16, 2015: contributor

re @laanwj 's edit: and src/secp256k1

sipa commented at 1:14 PM on November 28, 2015: member

Concept ACK, but I think it can be more tailored to our workflow.

laanwj commented at 2:42 PM on January 21, 2016: member

I like the idea of listing maintainers, but right now this file seems directly copied from Linux and is not applicable to Bitcoin Core development workflow as it is.

Closing this due to inactivity. Please reopen if you're going to work on this again.

laanwj closed this on Jan 21, 2016

btcdrak commented at 2:44 PM on January 21, 2016: contributor

I was going to say, this is better in CONTRIBUTING.md and much of the content is duplicated there already, I'll open a PR.

DrahtBot locked this on Sep 8, 2021