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
