Re: [DISCUSS] Pre-Apache Flume dev processes - RTC vs CTR

[Jonathan Hsieh <jo...@cloudera.com>]

[I dodnt' realize I didn't send this -- this has been in my drafts box for a
while]

Thanks for the comments and  advice.  I really appreciate the perspective.
 It sounds like it boils down to trusting folks to do the right thing, to
know when to ask for advice, and to have a sense of when something would be
contentious.

More notes below.

On Sun, Jun 26, 2011 at 2:07 PM, Ralph Goers <ra...@dslextreme.com>wrote:

>
> On Jun 26, 2011, at 9:50 AM, Jonathan Hsieh wrote:
>
> > Ralph,
> >
> > The link and its transitive links makes some interesting points -- here's
> my
> > tl;dr version.
> > * It is basically up to the PMC of the project and doesn't affect
> incubation
> > graduation.
> > * Most Apache projects are CTR for committers' patches
> > * CTR guarantees progress.  RTC can lead to Benevolent Dictator which
> could
> > block progress and cause community dysfunction.
> > * CTR seems more "inclusive" and RTC is more "exclusive".  Apache wants
> to
> > be inclusive.
> > * RTC guarantees that someone else has seen code before it goes into the
> > codebase and can guarantee some level of quality.
>
> All the above are true, although I would argue that CTR doesn't imply that
> quality suffers.  In the end the PMC must vote on a release. That is what
> the ASF considers to be the guarantee for some level of quality.
>
> Noted.


> >
> > I have only worked on CTR projects and am fairly biased by this.   I
> don't
> > have much of a basis for my preference except for that it is a "what I'm
> > used to thing".  That said I a aware of some of RTC's negatives and
> > positives. I am interested in hearing more about how RTC projects "work"
> and
> > its pros and cons.
>
> I assume this is backwards - i.e. you have only worked on RTC projects?
>
> You are correct, I flipped this.  I've only worked on RTC and am interested
in CTR and its pros and cons.


> > * I'm assuming that patches from non-committer contributors always go
> > through a committer's RTC. Is this true?
>
> All patches from non-committers go through Jira. A committer will either
> apply the patch unaltered or modify it as necessary. Not every Jira issue
> that has a patch will have it applied. Sometimes committers either aren't
> interested in the problem or don't like the patch. Ideally, Jira issues with
> patches should get resolved one way or another but that isn't always
> possible.
>
>
Do all committers' patches go through jira as well?


>  > * There are some situations, even if we were CTR where I'd want someone
> to
> > review my patch before I commit.  ex:  I'm not a maven expert and I'd
> want
> > someone more versed in that to double check that changes there was sane.
> I
> > guess CTR doesn't preclude a self-imposed RTC.
>
> That is absolutely true. You would create a branch in subversion for the
> work you want to do. However, my experience tells me that the longer the
> branch stays open the harder it will be to merge it back.
>
> We've done this a few times using git, and in a few cases this has easy
(hbase plugin) but in others it was non-trivial (maven).  There are likely a
few in the pipeline that will be non-trivial (zk backend 2.0, and possibly
the ack rerouting)


> > * How do you deal with a situations where there is a dispute about a
> patch?
> > (ex: backwards compatibility requirements, or algorithm choices).
>
> See http://www.apache.org/foundation/voting.html - in particular the
> section on code modifications. Anyone can express a -1 on a code change. A
> -1 by a PMC member is a veto and the change must be reverted and should be
> done asap by the person who did the commit. The person vetoing the change
> should rarely, if ever, revert the change on their own. I would also
> recommend that a -1 by a committer also be considered a veto. A -1 from a
> non-committer is advisory but should strongly be considered.  Anyone voting
> -1 on a change must state the technical reasons their vote is based on.
>  Best practice is to revert the change and then have a healthy discussion on
> the list to try to resolve the issue.
>
> From the read of the voting for code modifications -- it seems like 3 +1s
are required for an RTC change.  Thus far, we've looser RTC projects I've
workd on required one +1 but could be vetoed by any -1.


> > The Cassandra discussion seems to be boiled down to "common sense should
> > win" and the community seems to have settled on a "relaxed" RTC.  Are
> there
> > projects that have a hybrid between CTR and RTC?  Are most RTC projects
> > "relaxed"?  What are some other examples of relaxations?
>
> I don't work on any RTC based projects so I really couldn't say. However,
> as you pointed out, most projects are a hybrid in the sense that all
> contributions from non-committers must be reviewed by at least one committer
> before being applied.  As you also mentioned, it is not uncommon for a
> committer to create a branch when they are working on something that they
> really aren't sure how it will turn out or suspect it is going to be
> controversial.  So in that sense all CTR projects have some RTC aspects to
> them, but it is usually done either by necessity or common sense, not
> dictated by the process.
>
> >
> > Here are some potential relaxed RTC variations (multiple of these could
> be
> > used):
> > - patches by committers that have have nits (spelling, formatting,
> function
> > naming or other nearly trivial fixes) get +1 on condition of fixes.  (ex:
> a
> > patch is functionally correct and tested but has typos or a badly named
> > function. +1 review on patch, no need for re-review once nits addressed)
>
> OK - but with subversion it is typically easier to just fix them in trunk.
>  Remember, after a commit is performed you are going to get an email with
> the full set of changes just as you should have from git. Reviewing that is
> very similar to reviewing a patch file.
>
>
> > - patches by committers that are essentially trivial (spelling,
> formatting,
> > comments) can be CTR.
>
> OK.
>
> > - patches by committers can be committed if there is no review or
> comments
> > after some time period (72 hours, or a week).   Silence is a +0.
>
> OK - but then the patch has to be applied. If you assume your committers
> know what they are doing than 90+% of the time that is extra work and it is
> simpler to commit to trunk and either fix problems as they are caught or
> revert the few changes that have problems.
>
> > - CTR a trunk/dev branch and RTC on a release branch.  This ideally would
> > make it easy for changes on dev branches.
>
> A lot of projects don't use release branches. The Maven release plugin will
> take care of changing the version numbers by removing the SNAPSHOT from the
> version, tagging, deploying and then changing the version numbers to the
> next SNAPSHOT version. Once you have a tag you can create a branch from that
> if it is ever needed.  Most projects only create a "version" branch - i.e.
> when you go from version 1.x to version 2.x, version 2 will stay on trunk
> and version 1 will be branched so further maintenance can be performed. Of
> course, version changes only occur when something significant requires it.
>
> I'm thinking that there will be some components that are being redesigned
and may incur a significant change in the next few months.  My thought is
that it would be good to shield a release branch from potentially
destabilizing patches while allowing potentially destabilizing patches to
work their way in.  Branching may be another approach for dealing with this.


> I do want to emphasize that the development processes followed by the
> project are up to each project community to decide. I see my job as a mentor
> as letting you know what has been determined to be "best practice" but not
> to tell you that it has to be done a certain way.  Whatever process is
> decided upon it should be documented on either the project web site or the
> project wiki.  I will also point out that while using the Maven release
> plugin is not required, their is a release process at the ASF that needs to
> be followed to some degree and the release plugin helps in that.  If it is
> desired I can find various pages on how to do a release from various
> projects and I believe both the incubator and either infrastructure or one
> of the main ASF pages also have information on that.  Again, this is
> something that the project will want to carefully document so that any PMC
> member who has a signing key can do it.
>
> Ralph
>
>


-- 
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com