mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sirois <jsir...@twitter.com>
Subject Re: svn commit: r1471710 - /incubator/mesos/trunk/support/release.sh
Date Fri, 26 Apr 2013 04:31:40 GMT
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) <
chris.a.mattmann@jpl.nasa.gov> wrote:

> Hi John,
>
> -----Original Message-----
>
> From: John Sirois <jsirois@twitter.com>
> Reply-To: "mesos-dev@incubator.apache.org" <mesos-dev@incubator.apache.org
> >
> Date: Thursday, April 25, 2013 8:48 PM
> To: "mesos-dev@incubator.apache.org" <mesos-dev@incubator.apache.org>
> 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: chris.a.mattmann@nasa.gov
> 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 <jsirois@twitter.com> 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) <
> >> chris.a.mattmann@jpl.nasa.gov> 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: chris.a.mattmann@nasa.gov
> >>> 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 <jsirois@twitter.com>
> >>> Reply-To: "mesos-dev@incubator.apache.org" <
> >>> mesos-dev@incubator.apache.org>
> >>> Date: Thursday, April 25, 2013 8:28 PM
> >>> To: "mesos-dev@incubator.apache.org" <mesos-dev@incubator.apache.org>
> >>> 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) <
> >>> >chris.a.mattmann@jpl.nasa.gov> 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: chris.a.mattmann@nasa.gov
> >>> >> 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 <benh@eecs.berkeley.edu>
> >>> >> Reply-To: "mesos-dev@incubator.apache.org"
> >>> >><mesos-dev@incubator.apache.org
> >>> >> >
> >>> >> Date: Thursday, April 25, 2013 8:16 PM
> >>> >> To: mesos <mesos-dev@incubator.apache.org>
> >>> >> 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) <
> >>> >> >chris.a.mattmann@jpl.nasa.gov> 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: chris.a.mattmann@nasa.gov
> >>> >> >> WWW:  http://sunset.usc.edu/~mattmann/
> >>> >> >>
> >>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>> >> >> Adjunct Assistant Professor, Computer Science Department
> >>> >> >> University of Southern California, Los Angeles, CA 90089
USA
> >>> >> >>
> >>>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >>
> >>> >> >> -----Original Message-----
> >>> >> >> From: "benh@apache.org" <benh@apache.org>
> >>> >> >> Reply-To: "mesos-dev@incubator.apache.org"
> >>> >> >><mesos-dev@incubator.apache.org
> >>> >> >> >
> >>> >> >> Date: Wednesday, April 24, 2013 2:52 PM
> >>> >> >> To: "mesos-commits@incubator.apache.org"
> >>> >> >> <mesos-commits@incubator.apache.org>
> >>> >> >> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message