Hey John, -----Original Message-----
From: John Sirois <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Thursday, April 25, 2013 9:31 PM To: "[email protected]" <[email protected]> Subject: Re: svn commit: r1471710 - /incubator/mesos/trunk/support/release.sh >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!). Totally understood. That said, you have to realize that Apache Mesos (Incubating) != Twitter. When the project came to the ASF it became larger than a single company. So developers coding hot and heavy, that happen to be co-located within a time zone, that's fine, but there are social "isms" that are in play here that aren't technical, they are human oriented. So yes, hard to code up into an expert system but maybe if I get some spare time ~_^ > >My suggestion would be to encode things like review process in a doc so a >new project can read about whats expected upfront. Yeah I guess I'm getting "meta" here but bear with me. To me things like release process, easily put into a wiki/doc (in fact, I will try to do this as I try and make an 0.11.0 rc2 for Mesos -- wish me luck, heh). However, review process is not something I think is easily encodable in a doc -- it's encoded in knowledge passed down on mailing lists, knowledge and best practices that were part of some of the "managy" issues you called out above and that I linked too (funny part -- not a manager wrote them, 99% of people here are devs, even the managers once were :) ). Formalizing review process puts folks into a slippery slope of thinking that if they don't follow the "rules" or "steps" that are part of that process they are doing wrong. For example my CTR versus RTC illustration. I purposefully didn't call it a "rule" b/c I honestly go back and forth on it (depending on situation, who I'm working with, what project I'm working on, and the dynamics [social] of the community). BTW, I'm a trained engineer, and computer Scientist, but I don't want to be classified as either ;) This causes trouble for me sometimes b/c I can wear both hats. Heh. However, folks that don't follow the process, or rules, in the review process I don't think should be punished -- they should be flexible, adaptable, etc., so those types of situations and dynamics (inputs/observations) based on the situation as I mentioned. The same isn't typically said in an engineering sense for "release" processes and other things that can be scripted. If I mess up on a step in the Apache Mesos 0.11.0 rc2 release process, I messed up. I'll need to fix it/undo it, or run it over again. Typically more "engineering-y" and black/white. > 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. Heh, I'm pretty scalable. Just kidding. Well not really, but oh well. LOL. Anyways, besides that, tooling "social" norms takes the "care"/interaction out of a project and the passing down of tribal knowledge that is sometimes hard to codify in a rule/tool/hook. I would be scared of mattmann-post-commit-hook. Would probably take forever to write and contradict itself half or more of the time. > >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. NP. The more of these things you participate in, I'm sure the less ad-hoc it will become. I'm sorry if I sound like I'm preaching or rule making. I'm not. My #1 rule is for Apache Mesos (incubating) to graduate from the Incubator and to be a TLP. But to do that, I need the Apache Mesos (incubating) folks to see some of these social norms, and to continue them on as an ASF project when it gets there. I think for the most part, the PPMC does a great job, and I'm really just trying to help/refine minor things and hope I can be helpful. > >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. Anytime thanks for speaking up on the Apache lists, and sending an email that's NOT a Review Board email. We need more of these discussions on these lists by human beings. It's great to talk with you about this and looking forward to continuing to do so. Thanks for listening John. 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 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
