getting acquainted with ASF methodology

[Adrian Cole <ad...@gmail.com>]

A lot of us are learning as we go what ASF really means to our
project.  While it is definitely a new set of infrastructure and new
people, it is more a new methodology.  I've noticed in email and irc,
people expressing their opinions occasionally as -1 or threats of a -1
(or in -1 defense in my case!).

While we are in the middle of change, we are learning a lot about
Apache and eachother.  We are learning about what people feel strongly
about, and we are also all under more stress while sands shift.  We've
not really voted like this before, too!  I'm not surprised or
concerned about strong feelings, and also believe it is important for
everyone to speak their piece and practice "the apache way".  If we
understand we are all learning, it might follow that sometimes we
stumble on what voting means inside ASF.

What decisions and actions can an individual take without community
buy in?  What sorts of votes are valid?  Even-though we tried to act
as a community prior, ASF methodology is very different that what some
might expect, or how we previously operated as a community.

Particularly, I've found C-T-R vs R-T-C very interesting.

http://www.apache.org/foundation/glossary.html#ReviewThenCommit
http://www.apache.org/foundation/glossary.html#CommitThenReview

In both cases, the concept of a Veto (or -1) is discussed

http://www.apache.org/foundation/glossary.html#Veto

You probably have your own surprises you've found reading this.  I
found it surprising that vetos don't apply to procedural issues such
as releases.  For example, that implies that a veto alone cannot block
a release.

In the case of code, I didn't find it surprising that a veto was only
valid with justification.  That's intuitive.  However, I did find
interesting "Vetos force discussion and, if supported, version control
rollback or appropriate code changes".  In other words, while a
committer can raise a red flag to force discussion, they cannot alone
revert a commit by another.

How vetos work is a very important aspect to keep in mind.  It keeps
us focused on community, while evaluating code.  It removes fear of
arbitrary or justified reverts from a single committer without buy-in
from others.  It removes tension around -1 on procedural votes, as
while they do affect majority rule, they cannot alone block the
outcome.

I hope that underscoring this stuff isn't just interesting, but it
aligns the way we interact.  Mentors, if I've misinterpreted anything
above, please help straighten me out!

Cheers,
-A

Re: getting acquainted with ASF methodology

[David Nalley <da...@gnsa.us>]

On Mon, May 20, 2013 at 11:28 AM, Andrew Bayer <an...@gmail.com> wrote:
> One thing to note is that I'm not 100% sure you can do force-pushes to the
> ASF repo - David, can you confirm that? If you can't do force-pushes, then
> reverting becomes more than just removing a commit from the history.
>
> A.

Force pushes are disabled.

Doesn't mean you can't do git revert $hash and push though. But there
is no such thing as undoing history.

--David

Re: getting acquainted with ASF methodology

[Ignasi <ig...@gmail.com>]

I really like not having the push with force. Rewriting the commit history
is really bad and may cause people to have trouble when updating the forks,
just to say one.

Reverting commits is the cleanest option, IMHO.

In the asf repos we shouldn't have merge commits. If we pull rebasing and
commit applying patches attached to jira issues, we shouldn't be adding
merge commits, and if merging branches when they are properly rebased
shouldn't introduce them. If we take care when commiting, we should have a
clean and linear history.
El 22/05/2013 19:56, "Matt Stephenson" <ma...@apache.org> escribió:

> Revert commits are the way to go, it makes it easy to replay the original
> commit again and undo the revert.  Reverts aren't bad, they're generally
> just for functionality that isn't ready for the branch it was placed on.
>  In the model where force-pushes are disabled, you can always branch from
> the parent commit to the revert commit, giving you a simple way to continue
> working to resolve whatever caused the revert to happen.  Small commits
> make it much easier to merge back in reverted work as well.  I've been on
> several teams that used reverts pretty prolifically.  It can be kinda hard
> to see your work "undone", but in this model, it's only undone on one
> branch.
>
> Removing history from the git tree altogether is really a bad model, though
> I do like to rebase out merge commits if possible from time to time.  It
> sucks that we won't be able to do that anymore.  As a result, committers
> can help keep the history cleaner by doing a pull with rebase prior to
> pushing as opposed to doing a pull by itself and generating a merge commit.
>
> Matt
>
>
> On Mon, May 20, 2013 at 11:17 AM, Andrew Phillips <aphillips@qrmedia.com
> >wrote:
>
> > One thing to note is that I'm not 100% sure you can do force-pushes to
> the
> >> ASF repo - David, can you confirm that? If you can't do force-pushes,
> then
> >> reverting becomes more than just removing a commit from the history.
> >>
> >
> > I guess an explicit "revert commit" makes more sense from a traceability
> > perspective in any case? Even if it's a bit more work.
> >
> > Here's hoping and optimistically presuming this will remain largely a
> > *theoretical* issue... ;-)
> >
> > ap
> >
>

Re: getting acquainted with ASF methodology

[Andrew Phillips <ap...@qrmedia.com>]

> Removing history from the git tree altogether is really a bad model

+1. So far, it seems to me we're just fine with the permissions we  
have now. Seeing Adrian's revert commits from a couple of days ago [1]  
is helpful - it shows we added some functionality and then decided it  
didn't make the cut after all.

ap

[1] https://git-wip-us.apache.org/repos/asf?p=incubator-jclouds.git;a=summary

Re: getting acquainted with ASF methodology

[Matt Stephenson <ma...@apache.org>]

Revert commits are the way to go, it makes it easy to replay the original
commit again and undo the revert.  Reverts aren't bad, they're generally
just for functionality that isn't ready for the branch it was placed on.
 In the model where force-pushes are disabled, you can always branch from
the parent commit to the revert commit, giving you a simple way to continue
working to resolve whatever caused the revert to happen.  Small commits
make it much easier to merge back in reverted work as well.  I've been on
several teams that used reverts pretty prolifically.  It can be kinda hard
to see your work "undone", but in this model, it's only undone on one
branch.

Removing history from the git tree altogether is really a bad model, though
I do like to rebase out merge commits if possible from time to time.  It
sucks that we won't be able to do that anymore.  As a result, committers
can help keep the history cleaner by doing a pull with rebase prior to
pushing as opposed to doing a pull by itself and generating a merge commit.

Matt


On Mon, May 20, 2013 at 11:17 AM, Andrew Phillips <ap...@qrmedia.com>wrote:

> One thing to note is that I'm not 100% sure you can do force-pushes to the
>> ASF repo - David, can you confirm that? If you can't do force-pushes, then
>> reverting becomes more than just removing a commit from the history.
>>
>
> I guess an explicit "revert commit" makes more sense from a traceability
> perspective in any case? Even if it's a bit more work.
>
> Here's hoping and optimistically presuming this will remain largely a
> *theoretical* issue... ;-)
>
> ap
>

Re: getting acquainted with ASF methodology

[Andrew Phillips <ap...@qrmedia.com>]

> One thing to note is that I'm not 100% sure you can do force-pushes to the
> ASF repo - David, can you confirm that? If you can't do force-pushes, then
> reverting becomes more than just removing a commit from the history.

I guess an explicit "revert commit" makes more sense from a  
traceability perspective in any case? Even if it's a bit more work.

Here's hoping and optimistically presuming this will remain largely a  
*theoretical* issue... ;-)

ap

Re: getting acquainted with ASF methodology

[Andrew Bayer <an...@gmail.com>]

One thing to note is that I'm not 100% sure you can do force-pushes to the
ASF repo - David, can you confirm that? If you can't do force-pushes, then
reverting becomes more than just removing a commit from the history.

A.

On Sat, May 18, 2013 at 6:22 PM, Matt Stephenson <ma...@mattstep.net>wrote:

> That sounds great to me.  I like the concept of the andon cord.  In my
> experience reverting commits is generally only done when there are
> technical issues with the commit, a proper review is done and issues are
> found, and the committer refuses to respond to those issues.  Is this the
> type of scenario that makes sense for using such a tool?
>
> Matt
>
>
> On Sat, May 18, 2013 at 12:22 PM, David Nalley <da...@gnsa.us> wrote:
>
> > >
> > > In the case of code, I didn't find it surprising that a veto was only
> > > valid with justification.  That's intuitive.  However, I did find
> > > interesting "Vetos force discussion and, if supported, version control
> > > rollback or appropriate code changes".  In other words, while a
> > > committer can raise a red flag to force discussion, they cannot alone
> > > revert a commit by another.
> > >
> > > How vetos work is a very important aspect to keep in mind.  It keeps
> > > us focused on community, while evaluating code.  It removes fear of
> > > arbitrary or justified reverts from a single committer without buy-in
> > > from others.  It removes tension around -1 on procedural votes, as
> > > while they do affect majority rule, they cannot alone block the
> > > outcome.
> > >
> >
> > So we may be saying the same thing, but let me restate this.
> >
> > First, dissension or disagreement isn't necessarily a veto, regardless
> > of who it comes from. I disagree with lots of things, many of which I
> > remain silent about or voice my disagreement without vetoing.
> >
> > Committers have tremendous responsibility and authority.
> > They get the authority to commit to the repository, and the
> > responsibility of doing so in a manner that meets the expectations of
> > the community.
> > They also get the authority to pull the community Andon cord in the
> > form of a veto for code. Vetos do require a legitimate technical
> > reason behind them. It does mean that someone acting poorly can freeze
> > a community in its tracks, though I would fully expect that a person
> > would lose committer status rapidly if they (ab)used vetos too
> > frequently. But it does mean that anyone who has established merit to
> > the point that they are a committer can ensure that their voice is not
> > ignored. It also requires people, perhaps with differing agendas, to
> > work on getting things done by consensus..
> >
> > Veto's should not be looked at as a forcing function to change
> > behavior or to slow things down until you get a chance to review.
> > Vetos should be rarely used, and should almost never be a tool of
> > first resort. To give you some sense, CloudStack had around 6k commits
> > in the past 12 months, and I think there have only been 4 vetos. 3 of
> > those were feature merges without tests (later rectified and dealt
> > with), one was a feature that would have been essentially outside the
> > control of the project.  We've had _lots_ of disagreements, lots of
> > code reviews, lots of comments like 'this could be better if done in
> > this way' - and even 'this is wrong' that all of the parties worked
> > out to everyone's acceptance.
> >
> > Regardless of vetos, the goal here is to build a vibrant community,
> > the ASF values community over code. I'd almost argue that vetos should
> > be like flood insurance - committers have it just in case they have to
> > use it, but it's a VERY bad situation to begin with if they do.
> >
> > --David
> >
>

Re: getting acquainted with ASF methodology

[Matt Stephenson <ma...@mattstep.net>]

That sounds great to me.  I like the concept of the andon cord.  In my
experience reverting commits is generally only done when there are
technical issues with the commit, a proper review is done and issues are
found, and the committer refuses to respond to those issues.  Is this the
type of scenario that makes sense for using such a tool?

Matt


On Sat, May 18, 2013 at 12:22 PM, David Nalley <da...@gnsa.us> wrote:

> >
> > In the case of code, I didn't find it surprising that a veto was only
> > valid with justification.  That's intuitive.  However, I did find
> > interesting "Vetos force discussion and, if supported, version control
> > rollback or appropriate code changes".  In other words, while a
> > committer can raise a red flag to force discussion, they cannot alone
> > revert a commit by another.
> >
> > How vetos work is a very important aspect to keep in mind.  It keeps
> > us focused on community, while evaluating code.  It removes fear of
> > arbitrary or justified reverts from a single committer without buy-in
> > from others.  It removes tension around -1 on procedural votes, as
> > while they do affect majority rule, they cannot alone block the
> > outcome.
> >
>
> So we may be saying the same thing, but let me restate this.
>
> First, dissension or disagreement isn't necessarily a veto, regardless
> of who it comes from. I disagree with lots of things, many of which I
> remain silent about or voice my disagreement without vetoing.
>
> Committers have tremendous responsibility and authority.
> They get the authority to commit to the repository, and the
> responsibility of doing so in a manner that meets the expectations of
> the community.
> They also get the authority to pull the community Andon cord in the
> form of a veto for code. Vetos do require a legitimate technical
> reason behind them. It does mean that someone acting poorly can freeze
> a community in its tracks, though I would fully expect that a person
> would lose committer status rapidly if they (ab)used vetos too
> frequently. But it does mean that anyone who has established merit to
> the point that they are a committer can ensure that their voice is not
> ignored. It also requires people, perhaps with differing agendas, to
> work on getting things done by consensus..
>
> Veto's should not be looked at as a forcing function to change
> behavior or to slow things down until you get a chance to review.
> Vetos should be rarely used, and should almost never be a tool of
> first resort. To give you some sense, CloudStack had around 6k commits
> in the past 12 months, and I think there have only been 4 vetos. 3 of
> those were feature merges without tests (later rectified and dealt
> with), one was a feature that would have been essentially outside the
> control of the project.  We've had _lots_ of disagreements, lots of
> code reviews, lots of comments like 'this could be better if done in
> this way' - and even 'this is wrong' that all of the parties worked
> out to everyone's acceptance.
>
> Regardless of vetos, the goal here is to build a vibrant community,
> the ASF values community over code. I'd almost argue that vetos should
> be like flood insurance - committers have it just in case they have to
> use it, but it's a VERY bad situation to begin with if they do.
>
> --David
>

Re: getting acquainted with ASF methodology

[David Nalley <da...@gnsa.us>]

>
> In the case of code, I didn't find it surprising that a veto was only
> valid with justification.  That's intuitive.  However, I did find
> interesting "Vetos force discussion and, if supported, version control
> rollback or appropriate code changes".  In other words, while a
> committer can raise a red flag to force discussion, they cannot alone
> revert a commit by another.
>
> How vetos work is a very important aspect to keep in mind.  It keeps
> us focused on community, while evaluating code.  It removes fear of
> arbitrary or justified reverts from a single committer without buy-in
> from others.  It removes tension around -1 on procedural votes, as
> while they do affect majority rule, they cannot alone block the
> outcome.
>

So we may be saying the same thing, but let me restate this.

First, dissension or disagreement isn't necessarily a veto, regardless
of who it comes from. I disagree with lots of things, many of which I
remain silent about or voice my disagreement without vetoing.

Committers have tremendous responsibility and authority.
They get the authority to commit to the repository, and the
responsibility of doing so in a manner that meets the expectations of
the community.
They also get the authority to pull the community Andon cord in the
form of a veto for code. Vetos do require a legitimate technical
reason behind them. It does mean that someone acting poorly can freeze
a community in its tracks, though I would fully expect that a person
would lose committer status rapidly if they (ab)used vetos too
frequently. But it does mean that anyone who has established merit to
the point that they are a committer can ensure that their voice is not
ignored. It also requires people, perhaps with differing agendas, to
work on getting things done by consensus..

Veto's should not be looked at as a forcing function to change
behavior or to slow things down until you get a chance to review.
Vetos should be rarely used, and should almost never be a tool of
first resort. To give you some sense, CloudStack had around 6k commits
in the past 12 months, and I think there have only been 4 vetos. 3 of
those were feature merges without tests (later rectified and dealt
with), one was a feature that would have been essentially outside the
control of the project.  We've had _lots_ of disagreements, lots of
code reviews, lots of comments like 'this could be better if done in
this way' - and even 'this is wrong' that all of the parties worked
out to everyone's acceptance.

Regardless of vetos, the goal here is to build a vibrant community,
the ASF values community over code. I'd almost argue that vetos should
be like flood insurance - committers have it just in case they have to
use it, but it's a VERY bad situation to begin with if they do.

--David

Re: getting acquainted with ASF methodology

[Andrew Phillips <ap...@qrmedia.com>]

Thanks for taking the lead on trying to help those new to the ASF  
interpret all of this!

ap