We use this at Twitter, Google uses it and I'd like to use it in our github open source projects. What makes me bring it up as an observer on this list is that it feels like there are a whole lot of implicit apache rules and it would be nice if they were made explicit via tooling. I'd think this would be a boon for onboarding of new projects and new folks. Opinon:wWe're engineers and generally like to be able to find things out by reading. It's suboptimal to find out by explanation of quasi rules.
On Thu, Apr 25, 2013 at 9:43 PM, John Sirois <[email protected]> wrote: > To be clear - the idea is sign-off, not perms to commit. In other words - > anyone can commit to any dir, they just must get sign off from at least 1 > OWNER. OWNERS can be specialized to subdirs if thats the bit they know and > have proved themselves on. You get in OWNERS via meritocracy by sending a > review that adds yourself to an OWNERS you think you belong in and other > OWNERS at that level or higher approve. > > > On Thu, Apr 25, 2013 at 9:35 PM, Mattmann, Chris A (398J) < > [email protected]> wrote: > >> Hi John, >> >> In general, Apache simple provide group level authentication for >> committers, based on Project Management Committees (PMCs) for >> top level projects and Podling Project Management Committees (PPMCs) >> for incubating efforts. >> >> The base svn-authorization-file is used for both SVN and Git >> authentication, >> and it can be path based that are mapped to LDAP groups, or specific >> committer >> IDs, etc. That's the technical side of things. >> >> Apache encourages social inclusivity though -- they don't encourage >> hard limits on members of the same committee, and that's correct IMO >> since projects that include lots and lots of rules of who can commit >> where, etc., don't make it very fun to be around a community/project. >> >> As a mentor, I wouldn't encourage any project to have those sorts of >> rules (e.g., certain committers/PMC members can commit to /this/path, >> whilst others can commit to /this/other/path). That is indicative of >> an umbrella community (e.g., a community that actually contains distinct >> sub communities inside of it). That generally leads to a "governing >> body" that has binding VOTEs on new committers/PMC members and releases >> but no merit in those sub communities, which doesn't make the people >> in those sub communities too happy. >> >> HTH. >> >> Cheers, >> Chris >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Chris Mattmann, Ph.D. >> Senior Computer Scientist >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >> Office: 171-266B, Mailstop: 171-246 >> Email: [email protected] >> WWW: http://sunset.usc.edu/~mattmann/ >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Adjunct Assistant Professor, Computer Science Department >> University of Southern California, Los Angeles, CA 90089 USA >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> >> >> >> >> -----Original Message----- >> From: John Sirois <[email protected]> >> Reply-To: "[email protected]" < >> [email protected]> >> Date: Thursday, April 25, 2013 8:28 PM >> To: "[email protected]" <[email protected]> >> Subject: Re: svn commit: r1471710 - >> /incubator/mesos/trunk/support/release.sh >> >> >Has apache thought about OWNERS controls? Ie: an OWNERS file in a dir >> >that >> >lists OWNERS who must sign-off and then perhaps if none recurse to >> parents >> >and collect higher level uber-owners? This removes alot of ambiguity, >> >ensure process, and well - its clear and transparent. Granted it >> requires >> >some tooling. >> > >> > >> >On Thu, Apr 25, 2013 at 9:21 PM, Mattmann, Chris A (398J) < >> >[email protected]> wrote: >> > >> >> Yep totally understood. Review's can be an FYI, for sure. >> >> >> >> My general rule of thumb: >> >> >> >> 1. if code is worked on in an area of the tree that *you* are the only >> >> one familiar with, and the change isn't uber significant, go into CTR >> >> (commit-then-review) mode, and commit it (that's what version control >> >> is for :) ). >> >> >> >> 2. if code is in an area of code that multiple people are really >> looking >> >> at, and that you want consensus (which is the point of community), then >> >> I may throw up a Review Board requesting feedback from the other >> >>stewards >> >> of those portions of the code, looking for their feedback, etc. In >> those >> >> cases, give them 24-48-72 hours to review, and then get that feedback, >> >> and consensus. This is "review then commit" (RTC) mode. >> >> >> >> 3. if it's a new feature, I may do either CTR or RTC depending on >> >>feelings >> >> about the social nature of the area of the code/architecture. >> >> >> >> I generally think CTR is always the way to go, and do so, but will >> >> fall back to RTC when I want to gain consensus. >> >> >> >> HTH. >> >> >> >> Cheers, >> >> Chris >> >> >> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> Chris Mattmann, Ph.D. >> >> Senior Computer Scientist >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >> >> Office: 171-266B, Mailstop: 171-246 >> >> Email: [email protected] >> >> WWW: http://sunset.usc.edu/~mattmann/ >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> Adjunct Assistant Professor, Computer Science Department >> >> University of Southern California, Los Angeles, CA 90089 USA >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Benjamin Hindman <[email protected]> >> >> Reply-To: "[email protected]" >> >><[email protected] >> >> > >> >> Date: Thursday, April 25, 2013 8:16 PM >> >> To: mesos <[email protected]> >> >> Subject: Re: svn commit: r1471710 - >> >> /incubator/mesos/trunk/support/release.sh >> >> >> >> >Makes sense. Sometimes we throw people on reviews more as an FYI >> (i.e., >> >> >"check this out"). It would be swell if Review Board could distinguish >> >> >between the different intentions, but I agree that it's nice to let a >> >> >reviewer have time to review. >> >> > >> >> > >> >> >On Thu, Apr 25, 2013 at 8:06 PM, Mattmann, Chris A (398J) < >> >> >[email protected]> wrote: >> >> > >> >> >> Hi Ben, >> >> >> >> >> >> Just a general note. I had a total of a few hours to look at this >> >> >> before you committed it. That really isn't enough time. Typically >> >> >> projects give folks at least between 24-72 hours to let folks scope >> >> >> something out (or declare otherwise upfront). Apologies I didn't >> >> >> get to look at this until now (and I sent in a comment), I've been >> >> >> underwater in meetings, etc. >> >> >> >> >> >> But it would be good in the future to allow others to have a chance >> >> >> to take a look. I see you got 2 ship its (1 from vinod, and another >> >> >> from benm), which is great, I was on the review too and would have >> >> >> liked to scope it too before committing. >> >> >> >> >> >> No biggie, just wanted to raise this b/c it's a community issue, >> >> >> especially for scaling out the project to diverse committers in >> >> >> multiple organizations, etc., since they'll need time to review >> >>things. >> >> >> >> >> >> Cheers, >> >> >> Chris >> >> >> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> Chris Mattmann, Ph.D. >> >> >> Senior Computer Scientist >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >> >> >> Office: 171-266B, Mailstop: 171-246 >> >> >> Email: [email protected] >> >> >> WWW: http://sunset.usc.edu/~mattmann/ >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> Adjunct Assistant Professor, Computer Science Department >> >> >> University of Southern California, Los Angeles, CA 90089 USA >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: "[email protected]" <[email protected]> >> >> >> Reply-To: "[email protected]" >> >> >><[email protected] >> >> >> > >> >> >> Date: Wednesday, April 24, 2013 2:52 PM >> >> >> To: "[email protected]" >> >> >> <[email protected]> >> >> >> Subject: svn commit: r1471710 - >> >> >>/incubator/mesos/trunk/support/release.sh >> >> >> >> >> >> >Author: benh >> >> >> >Date: Wed Apr 24 21:52:42 2013 >> >> >> >New Revision: 1471710 >> >> >> > >> >> >> >URL: http://svn.apache.org/r1471710 >> >> >> >Log: >> >> >> >Fixed bug creating SVN tag in release.sh. >> >> >> > >> >> >> >Review: https://reviews.apache.org/r/10767 >> >> >> > >> >> >> >Modified: >> >> >> > incubator/mesos/trunk/support/release.sh >> >> >> > >> >> >> >Modified: incubator/mesos/trunk/support/release.sh >> >> >> >URL: >> >> >> > >> >> >> >> >> >> >> >> >> >> >> http://svn.apache.org/viewvc/incubator/mesos/trunk/support/release.sh?rev >> >> >>= >> >> >> >1471710&r1=1471709&r2=1471710&view=diff >> >> >> >> >> >> >> >>>>>====================================================================== >> >>>>>== >> >> >>>== >> >> >> >==== >> >> >> >--- incubator/mesos/trunk/support/release.sh (original) >> >> >> >+++ incubator/mesos/trunk/support/release.sh Wed Apr 24 21:52:42 >> >>2013 >> >> >> >@@ -60,7 +60,7 @@ echo "${GREEN}Finally, we'll create an S >> >> >> > >> >> >> > MESSAGE="Tag for release-${VERSION}-incubating-RC${CANDIDATE}." >> >> >> > >> >> >> >-git svn branch -n --tag -m ${MESSAGE} \ >> >> >> >+git svn branch --tag -m ${MESSAGE} \ >> >> >> > release-${VERSION}-incubating-RC${CANDIDATE} || \ >> >> >> > { echo "${RED}Failed to create SVN tag/branch${NORMAL}"; exit 1; >> >>} >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> > >> >-- >> >John Sirois >> >303-512-3301 >> >> > > > -- > John Sirois > 303-512-3301 > > > > > > -- John Sirois 303-512-3301
