On 15 November 2016 at 23:19, Oliver Bestwalter <[email protected]> wrote: > Hi, > > will this be a "sorta kinda C4" then or do we want to implement the whole > thing as described in https://rfc.zeromq.org/spec:42/C4/ ?
Probably not, upon re-reading this I'm not actually a massive fan of the document in it's entirety despite it having many good intentions, e.g. 2.3.1 (must use real names) ranks pretty high on my scale for a bad idea. But I'm not going to dissect the whole thing here. > I ask because what you describe Floris is an interesting idea but I do not > see the parallel to C4 as that process clearly has maintainers who merge PRs > of others, which I think of as a Good Thing. I mean this part of the > protocol: > > A "Contributor" is a person who wishes to provide a patch, being a set of > commits that solve some clearly identified problem. > A "Maintainer" is a person who merges patches to the project. Maintainers > are not developers; their job is to enforce process. > Contributors SHALL NOT have commit access to the repository unless they are > also Maintainers. > Maintainers SHALL have commit access to the repository. So upon re-reading of C4.1 I'm just interested in formalising how one gets to be a Maintainer. C4.1 itself leaves this pretty vague while I'd like to give Contributors a clear expectation. > I also like the whole Problem -> Solution idea as basis for development of > the project (section 2.3). Sure, C4.1 has many good ideas quite a few which we already follow more or less. > Giving everybody commit rights who successfully merged a PR is a different > idea that could be experimented with, but I would not call it C4. You're right, there is virtually no overlap between my proposal and C4.1. It had been a very long time since I read C4.1 so honestly I didn't really remember what exactly it contained. Floris _______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
