You never called them rules - totally agreed, what I'd love is clear ones or machine enforced ones or even - simplest - the weaker rules of thumb written out. None of the documents you referenced lay this out - they tend to address managy issue and not day to day dev issues. As developers coding hot and heavy on a project - we care less about the larger project rules mentioned in those docs. The closest to home rule talked about was onboarding and offboarding comitters - thats a relatively rare event compared to code commits (we hope!).
My suggestion would be to encode things like review process in a doc so a new project can read about whats expected upfront. Even better would be repo hooks that knew the TZs of committers and rejected commits with no ship its from all listed reviewers when still under the time window. A --tbr (to be reviewed) flag to bypass when reasonable, etc. My focus here is on tooling, development, and transparency upfront on the rules of thumb. It doesn't scale well to have someone like you have to spend time re-iterating rules of thumb when a doc could encode them or a server hook could enforce them. In the end - I'd prefer my projects to be on the incubator because it has more rules and structure, but I'm turned away a bit by the ad-hoc feeling of some of these rules and rules of thumb - I'd prefer them be known from day one. I say all this with full realization that the writing of the rules of thumb docs for day to day dev takes time and effort, svn/git hooks take the same, and apache is volunteer. Thanks for fielding some shots from left field. On Thu, Apr 25, 2013 at 10:14 PM, Mattmann, Chris A (398J) < [email protected]> wrote: > Hi John, > > -----Original Message----- > > From: John Sirois <[email protected]> > Reply-To: "[email protected]" <[email protected] > > > Date: Thursday, April 25, 2013 8:48 PM > To: "[email protected]" <[email protected]> > Subject: Re: svn commit: r1471710 - > /incubator/mesos/trunk/support/release.sh > > >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. > > Please name to me the explicit Apache rules I'm citing? I believe I started > out with: "My general rule of thumb" [sic] > > The only Apache rules are those that define the organizational structure of > projects, and the foundation and you can read all about them here: > > http://apache.org/foundation/bylaws.html > > > The Incubator has a Podling Project Management Committee (PPMC) structure > for its podlings, documentation here: > > http://incubator.apache.org/guides/ppmc.html > > > When graduated, the project is an official "Top Level Project" (TLP) and > has a Project Management Committee (PMC), info here: > > http://www.apache.org/dev/pmc.html > > > The foundation works like this: > > http://www.apache.org/foundation/how-it-works.html > > > Happy to hear specific suggestions on improvements to any of those docs. > As are the other members of the Foundation or Incubator folks, etc. > > > 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. > > Again, where did I call them rules? > > Let's review: > > 1. There was a Review Board issue posted (which generally indicates a > desire for feedback from others. I was named as one of those others). > > 2. A few hours later, the Review Board was closed after a commit was > made. > > > 3. #2 doesn't scale to open source organizations. In fact, this > doesn't scale to distributed organizations, that involve people in > different time zones, different schedules, etc. This isn't a very > consensus building practice. I noted these things in an email > suggesting best practices not just for Apache but for open source > (I participate in a # of OSS foundations, have contributed patches > to PHP, OSGeo projects, etc.) > > Many times solutions to #3 including windows of time to allow others > on the committee to review/comment. A good "rule of thumb" is to > give specific time windows, or assume a general 72 hour one that > gives people the ability to review. I again suggested these. > > That's about it. > > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > >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?re > >>>v > >>> >> >>= > >>> >> >> >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 > > -- John Sirois 303-512-3301
