subject:"\[Openstack\] A possible alternative to Gerrit ..."

Thanks for the reply Monty.

The major argument I've heard to date about using something other than Gerrit 
is the effort gone into tying into the CI system. I buy those arguments and 
support not reinventing the wheel. Roundabout seemed like the logical point of 
integration for hubcap, but if there are other efforts that get us further for 
less work, I'm completely open to that.

All your issues about single state and status pages are what Hubcap intended to 
resolve.

The other arguments about parsing comments from github pull requests are less 
convincing to me than:
1. the error-prone Change-ID mechanism that Gerrit uses
2. the gerrit UI that opens 30 tabs when you want to do a review
3. the gerrit UI that loses your review data randomly
4. the environment variables you have to remember to set in each project
5. the 'git review' mechanism that prevents me from using 'git push' as 
expected.
6. the git dances that have to be performed when something goes wrong
7. the gerrit remotes that have to be set up that break your mental model of 
how git remotes work
8. complete re-votes required after a re-review (unless that was intentional?)

... and that's only from my first few days using Gerrit. 

Moreso, as was stated before, why are we even using github in this case? Why 
not just stand up a git server? 
Right now it feels like bubble-gum and binder twine.

We're talking simple string parsing here. The last keyword from a user is that 
users vote. Multiple pull requests would be equally easy to support with a 
!new_vote command (or some such thing).

I'm sure I'm missing some critical piece of data here. 

Thanks again,
Sandy




From: Monty Taylor [mord...@inaugust.com]
Sent: Tuesday, September 06, 2011 11:31 PM
To: Sandy Walsh
Cc: Stefano Maffulli; openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible alternative to Gerrit ...

Hi everybody!

I understand some of you are not comfortable with Gerrit and the
workflow I and others are working to implement. While this may be a
problem for some, it was never our intention to make life hard for
anybody here. Let me try to explain why and how we got to this decision
and make a proposal on how to move forward.

OpenStack is already a large project with tons of contributors, and it
aims to continue to be larger over time. This is one of the reasons for
all of the developer automation and controls that we put in back at the
very beginning - what works well for a team of 5 doesn't necessarily
work well for teams of 100+, especially when many of those 100+ may be
corporate contributors only hacking on the code because they are being
paid to. We have many corporate partners in this project, and over time
the number of devs that fit that profile is very likely going to increase.

The CI team led the analysis of a move to git and github and found
several deficiences in github pull requests, mainly in the area of
failure conditions and scale. They work GREAT for handling the simple
case, when they're just used as a basis for code reviews, or when every
thing works perfectly the first time. One major limitation, for example,
is that things get quickly complex when code needs to get re-reviewed as
part of normal process. Another is that github does not provide a
project-management oriented overview of pull request states.

With pull requests, it is impossible to see the current state of a
review, because there IS no current state of a review other than open or
closed. As far as we can tell, the general practice with pull requests
in this regard is to close the pull request on rejection and open a new
one when the review has been addressed and a new review is desired. The
problem with that is the loss of historical context for reviews. When
you have tons of reviewers and reviews, knowing that someone is just
fixing a review comment and that the entire change doesn't need to be
re-reviewed from scratch is helpful.  This feature is very important for
the Project Tech Leads.

We asked for months and months for conversations with github
about adding an overall status field and were told that the folks at
github were not interested in doing this.

A meta system can be hacked in to overload pull request comments in a
way that systems like roundabout can use, but this ends up again being
excellent for the simple case of approval or denial, but becomes baroque
when a pull request is sent back for review several times.

We couldn't find a convenient way to overcome this limitation without
adding complicated steps and extra knowledge for developers.

We looked at roundabout- quite strongly, in fact. It was, indeed, our
first choice when considering how to integrate github with our developer
systems. It's a great tool and I've recommended it to other people given
their workflow needs. However, in addition to the fact that it's based
on magical text in github pull request comments as I mentioned above, it
also does not have

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Soren Hansen

2011/9/7 Sandy Walsh sandy.wa...@rackspace.com:
 We're talking simple string parsing here. The last keyword from a user is 
 that users vote. Multiple pull requests would be equally easy to support with 
 a !new_vote command (or some such thing).

The critical point has never been whether we could reliably detect
people's votes (even though I really dislike parsing free-form text to
extract critical information like this). Even though Launchpad offers
voting information in a structured manner, we *intentionally* don't
auto-approve things there as soon as they have +2.

Sometimes there are simply reasons why things shouldn't get merged
even though they have two approves. If there's already one +1, but
someone specific (someone with domain specific knowledge, a release
team member, etc) needs to sign off on it as well,  I still want to be
able to say that I've reviewed it and approve of it, without causing
it to get merged. We also want to be able to review features and vote
on them even during freeze times without causing them to get merged.

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

Good points Soren ... I completely understand those use cases.

I think LP does that stuff very well. Since the motive from the last summit was 
to go Github, my immediate (developer) reaction is to think of how Hubcap would 
handle them.

But standing back, it brings us back to the debate of why not LP?

We know that the LP team has been very responsive to our needs (certainly more 
than github) ... perhaps there is no advantage to standing up our own gerrit as 
Thierry suggests?

If I had to decide between developing/growing/maintaining gerrit or hubcap, I'd 
vote hubcap. 
If I had to decide between growing our own (in any form) and simply using LP, 
I'd vote LP.

-S



From: Soren Hansen [so...@linux2go.dk]
Sent: Wednesday, September 07, 2011 8:54 AM
To: Sandy Walsh
Cc: Monty Taylor; openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible alternative to Gerrit ...

2011/9/7 Sandy Walsh sandy.wa...@rackspace.com:
 We're talking simple string parsing here. The last keyword from a user is 
 that users vote. Multiple pull requests would be equally easy to support with 
 a !new_vote command (or some such thing).

The critical point has never been whether we could reliably detect
people's votes (even though I really dislike parsing free-form text to
extract critical information like this). Even though Launchpad offers
voting information in a structured manner, we *intentionally* don't
auto-approve things there as soon as they have +2.

Sometimes there are simply reasons why things shouldn't get merged
even though they have two approves. If there's already one +1, but
someone specific (someone with domain specific knowledge, a release
team member, etc) needs to sign off on it as well,  I still want to be
able to say that I've reviewed it and approve of it, without causing
it to get merged. We also want to be able to review features and vote
on them even during freeze times without causing them to get merged.

--
Soren Hansen| http://linux2go.dk/
Ubuntu Developer| http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/
This email may include confidential information. If you received it in error, 
please delete it.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Josh Kearney

On Wed, Sep 7, 2011 at 6:54 AM, Soren Hansen so...@linux2go.dk wrote:

The critical point has never been whether we could reliably detect
 people's votes (even though I really dislike parsing free-form text to
 extract critical information like this). Even though Launchpad offers
 voting information in a structured manner, we *intentionally* don't
 auto-approve things there as soon as they have +2.


 Sometimes there are simply reasons why things shouldn't get merged
 even though they have two approves. If there's already one +1, but
 someone specific (someone with domain specific knowledge, a release
 team member, etc) needs to sign off on it as well,  I still want to be
 able to say that I've reviewed it and approve of it, without causing
 it to get merged. We also want to be able to review features and vote
 on them even during freeze times without causing them to get merged.


Couldn't we just add an extra keyword like '!approved' that Hubcap would
only acknowledge from Core members? Unless that keyword is present, no
matter how many '!lgtm's are there, Hubcap will not attempt a merge.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

Yup, if you look at
http://www.darksecretsoftware.com/static/hubcap.html
you'll see there's a slot there for core  non-core approvals. We get the core 
approvers from the repos teams.

I like the idea of another keyword than !lgtm for cores to say I approve, but 
don't consider this the +2 ... perhaps just lgtm (no !) heh

-S

PS Notice the funky new stylings thanks to Jake Dahn!


From: Josh Kearney [j...@jk0.org]
Sent: Wednesday, September 07, 2011 12:05 PM
To: Soren Hansen
Cc: Sandy Walsh; openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 6:54 AM, Soren Hansen 
so...@linux2go.dkmailto:so...@linux2go.dk wrote:

The critical point has never been whether we could reliably detect
people's votes (even though I really dislike parsing free-form text to
extract critical information like this). Even though Launchpad offers
voting information in a structured manner, we *intentionally* don't
auto-approve things there as soon as they have +2.

Sometimes there are simply reasons why things shouldn't get merged
even though they have two approves. If there's already one +1, but
someone specific (someone with domain specific knowledge, a release
team member, etc) needs to sign off on it as well,  I still want to be
able to say that I've reviewed it and approve of it, without causing
it to get merged. We also want to be able to review features and vote
on them even during freeze times without causing them to get merged.

Couldn't we just add an extra keyword like '!approved' that Hubcap would only 
acknowledge from Core members? Unless that keyword is present, no matter how 
many '!lgtm's are there, Hubcap will not attempt a merge.

This email may include confidential information. If you received it in error, 
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 11:18 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
 Yup, if you look at
 http://www.darksecretsoftware.com/static/hubcap.html
 you'll see there's a slot there for core  non-core approvals. We get the
 core approvers from the repos teams.

And where are the comments in
https://github.com/rackspace/python-novaclient/pull/108?

Where are the reviews?

In addition, this doesn't prevent anyone on the core team from doing a
straight close and merge of the pull request into trunk, potentially
breaking trunk.

Where are the hooks into Jenkins? Where can I see the output of the
Jenkins test jobs that executed against a proposed branch?

-jay

 I like the idea of another keyword than !lgtm for cores to say I approve,
 but don't consider this the +2 ... perhaps just lgtm (no !) heh
 -S
 PS Notice the funky new stylings thanks to Jake Dahn!
 
 From: Josh Kearney [j...@jk0.org]
 Sent: Wednesday, September 07, 2011 12:05 PM
 To: Soren Hansen
 Cc: Sandy Walsh; openstack@lists.launchpad.net
 Subject: Re: [Openstack] A possible alternative to Gerrit ...

 On Wed, Sep 7, 2011 at 6:54 AM, Soren Hansen so...@linux2go.dk wrote:

 The critical point has never been whether we could reliably detect
 people's votes (even though I really dislike parsing free-form text to
 extract critical information like this). Even though Launchpad offers
 voting information in a structured manner, we *intentionally* don't
 auto-approve things there as soon as they have +2.

 Sometimes there are simply reasons why things shouldn't get merged
 even though they have two approves. If there's already one +1, but
 someone specific (someone with domain specific knowledge, a release
 team member, etc) needs to sign off on it as well,  I still want to be
 able to say that I've reviewed it and approve of it, without causing
 it to get merged. We also want to be able to review features and vote
 on them even during freeze times without causing them to get merged.

 Couldn't we just add an extra keyword like '!approved' that Hubcap would
 only acknowledge from Core members? Unless that keyword is present, no
 matter how many '!lgtm's are there, Hubcap will not attempt a merge.

 This email may include confidential information. If you received it in
 error, please delete it.
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to     : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 11:42 AM, Kevin L. Mitchell
kevin.mitch...@rackspace.com wrote:
 On Wed, 2011-09-07 at 11:24 -0400, Jay Pipes wrote:
 In addition, this doesn't prevent anyone on the core team from doing a
 straight close and merge of the pull request into trunk, potentially
 breaking trunk.

 So far as I know, there's no requirement that someone have merge
 authority on a project in order to comment on pull requests.  Do cores
 have direct access to the openstack repos right now, and if they do,
 what's to stop them from merging pull requests into trunk?

No. Gerrit and Jenkins own the canonical repos, and that's the whole point.

  I think
 cores are smart enough to follow the procedures laid down, and if they
 can't, well, they need to not be cores.

I repeat my previous statement about humans being poor gatekeepers
compared to automated enforceable policies.

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Kevin L. Mitchell

On Wed, 2011-09-07 at 11:24 -0400, Jay Pipes wrote:
 In addition, this doesn't prevent anyone on the core team from doing a
 straight close and merge of the pull request into trunk, potentially
 breaking trunk.

So far as I know, there's no requirement that someone have merge
authority on a project in order to comment on pull requests.  Do cores
have direct access to the openstack repos right now, and if they do,
what's to stop them from merging pull requests into trunk?  I think
cores are smart enough to follow the procedures laid down, and if they
can't, well, they need to not be cores.
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com

This email may include confidential information. If you received it in error, 
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
 But yes, there is a risk that a core member could just hit merge and close 
 and break trunk. That's perhaps the only real con I can think of.

That's the entire point of gerrit and a gated trunk, Sandy :)

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

Heh. Like I mentioned at the top of the thread, it's just a hack. We're 
currently merging with Roundabout to handle the Jenkins integration and make 
roundabout's workflow strategies pluggable.

So, right now only the pull request and core members are real, the votes are 
faked out.

The output from jenkins would be exactly the same as what we get from Gerrit (a 
new comment added to the pull request with the test results) ... only easier to 
find ;)

But yes, there is a risk that a core member could just hit merge and close 
and break trunk. That's perhaps the only real con I can think of.

-S


From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, September 07, 2011 12:24 PM
To: Sandy Walsh
Cc: Josh Kearney; Soren Hansen; openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 11:18 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
 Yup, if you look at
 http://www.darksecretsoftware.com/static/hubcap.html
 you'll see there's a slot there for core  non-core approvals. We get the
 core approvers from the repos teams.

And where are the comments in
https://github.com/rackspace/python-novaclient/pull/108?

Where are the reviews?

In addition, this doesn't prevent anyone on the core team from doing a
straight close and merge of the pull request into trunk, potentially
breaking trunk.

Where are the hooks into Jenkins? Where can I see the output of the
Jenkins test jobs that executed against a proposed branch?

-jay

 I like the idea of another keyword than !lgtm for cores to say I approve,
 but don't consider this the +2 ... perhaps just lgtm (no !) heh
 -S
 PS Notice the funky new stylings thanks to Jake Dahn!
 
 From: Josh Kearney [j...@jk0.org]
 Sent: Wednesday, September 07, 2011 12:05 PM
 To: Soren Hansen
 Cc: Sandy Walsh; openstack@lists.launchpad.net
 Subject: Re: [Openstack] A possible alternative to Gerrit ...

 On Wed, Sep 7, 2011 at 6:54 AM, Soren Hansen so...@linux2go.dk wrote:

 The critical point has never been whether we could reliably detect
 people's votes (even though I really dislike parsing free-form text to
 extract critical information like this). Even though Launchpad offers
 voting information in a structured manner, we *intentionally* don't
 auto-approve things there as soon as they have +2.

 Sometimes there are simply reasons why things shouldn't get merged
 even though they have two approves. If there's already one +1, but
 someone specific (someone with domain specific knowledge, a release
 team member, etc) needs to sign off on it as well,  I still want to be
 able to say that I've reviewed it and approve of it, without causing
 it to get merged. We also want to be able to review features and vote
 on them even during freeze times without causing them to get merged.

 Couldn't we just add an extra keyword like '!approved' that Hubcap would
 only acknowledge from Core members? Unless that keyword is present, no
 matter how many '!lgtm's are there, Hubcap will not attempt a merge.

 This email may include confidential information. If you received it in
 error, please delete it.
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


This email may include confidential information. If you received it in error, 
please delete it.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Josh Kearney

On Wed, Sep 7, 2011 at 10:59 AM, Jay Pipes jaypi...@gmail.com wrote:

 On Wed, Sep 7, 2011 at 11:42 AM, Kevin L. Mitchell
 kevin.mitch...@rackspace.com wrote:
  On Wed, 2011-09-07 at 11:24 -0400, Jay Pipes wrote:
  In addition, this doesn't prevent anyone on the core team from doing a
  straight close and merge of the pull request into trunk, potentially
  breaking trunk.
 
  So far as I know, there's no requirement that someone have merge
  authority on a project in order to comment on pull requests.  Do cores
  have direct access to the openstack repos right now, and if they do,
  what's to stop them from merging pull requests into trunk?

 No. Gerrit and Jenkins own the canonical repos, and that's the whole point.

   I think
  cores are smart enough to follow the procedures laid down, and if they
  can't, well, they need to not be cores.

 I repeat my previous statement about humans being poor gatekeepers
 compared to automated enforceable policies.

 -jay


Could make the default branch on github 'develop' so all Pull Requests would
default to there, and let Hubcap/RoundAbout be the gatekeeper of master?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Kevin L. Mitchell

On Wed, 2011-09-07 at 11:59 -0400, Jay Pipes wrote:
  So far as I know, there's no requirement that someone have merge
  authority on a project in order to comment on pull requests.  Do cores
  have direct access to the openstack repos right now, and if they do,
  what's to stop them from merging pull requests into trunk?
 
 No. Gerrit and Jenkins own the canonical repos, and that's the whole point.

And, as long as anyone can comment on the pull requests, there's no need
for this to change—you have hubcap/jenkins owning the canonical repo
instead of gerrit/jenkins.  So what's the problem?

   I think
  cores are smart enough to follow the procedures laid down, and if they
  can't, well, they need to not be cores.
 
 I repeat my previous statement about humans being poor gatekeepers
 compared to automated enforceable policies.

But if they're not regularly pulling those levers, the chances of them
accidentally pulling those levers fall drastically.  And if they don't
have to be owners of the repo in order to comment on pull requests, the
chances fall to nil, because that lever isn't there to pull.
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com

This email may include confidential information. If you received it in error, 
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 12:13 PM, Kevin L. Mitchell
kevin.mitch...@rackspace.com wrote:
 On Wed, 2011-09-07 at 11:59 -0400, Jay Pipes wrote:
  So far as I know, there's no requirement that someone have merge
  authority on a project in order to comment on pull requests.  Do cores
  have direct access to the openstack repos right now, and if they do,
  what's to stop them from merging pull requests into trunk?

 No. Gerrit and Jenkins own the canonical repos, and that's the whole point.

 And, as long as anyone can comment on the pull requests, there's no need
 for this to change—you have hubcap/jenkins owning the canonical repo
 instead of gerrit/jenkins.  So what's the problem?

The problem is that instead of spending time coding on features and
bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
spending time working on an alternate solution to what has already
been decided by the PPB, discussed publicly, and coded on for months
by my team.

Frankly, this whole situation hearkens back to when everyone except a
few folks on the Titan team was griping about Launchpad and Bazaar,
saying that they couldn't get anything done with these tools, except
for some on the Titan team which just adapted and ended up being very
productive using LP and Bazaar. If you guys would give Gerrit a chance
and try to work with the toolset, instead of constantly going off and
trying to make everything just GitHub, I think we'd actually be able
to get more done.

Just my two cents. You can probably tell I am quite frustrated with
this debate going on *yet again*.

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
 On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh sandy.wa...@rackspace.com 
 wrote:
  But yes, there is a risk that a core member could just hit merge and 
  close and break trunk. That's perhaps the only real con I can think of.
 
 That's the entire point of gerrit and a gated trunk, Sandy :)

Why do core members have that merge and close option? Wouldn't it make
more sense to restrict that to the Jenkins account?

I still think you can do a gated trunk, even with github pull requests.

JE


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 12:38 PM, Monsyne Dragon mdra...@rackspace.com wrote:
 This is basically what gerrit and our current LP setup do.  it's just a 
 matter of permissions.

Couldn't have said it better myself! Thanks, Monsyne!
-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Monsyne Dragon


On Sep 7, 2011, at 10:34 AM, Sandy Walsh wrote:

 Heh. Like I mentioned at the top of the thread, it's just a hack. We're 
 currently merging with Roundabout to handle the Jenkins integration and make 
 roundabout's workflow strategies pluggable.
 
 So, right now only the pull request and core members are real, the votes are 
 faked out.
 
 The output from jenkins would be exactly the same as what we get from Gerrit 
 (a new comment added to the pull request with the test results) ... only 
 easier to find ;)
 
 But yes, there is a risk that a core member could just hit merge and close 
 and break trunk. That's perhaps the only real con I can think of.

Only if they actually own the branch in github.  Presumably if you implement a 
gated trunk with Github/roundabout/hubcap, the canonical repo is set such that 
only the user the roundabout 'bot is using can actually merge a pull request. 
The 'core members' are just members of  a random team that the bot looks at to 
determine who to listen to for votes.   This is basically what gerrit and our 
current LP setup do.  it's just a matter of permissions. 


--
Monsyne M. Dragon
OpenStack/Nova 
cell 210-441-0965
work x 5014190

This email may include confidential information. If you received it in error, 
please delete it.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt johan...@erdfelt.com wrote:
 On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
 On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh sandy.wa...@rackspace.com 
 wrote:
  But yes, there is a risk that a core member could just hit merge and 
  close and break trunk. That's perhaps the only real con I can think of.

 That's the entire point of gerrit and a gated trunk, Sandy :)

 Why do core members have that merge and close option? Wouldn't it make
 more sense to restrict that to the Jenkins account?

 I still think you can do a gated trunk, even with github pull requests.

Please show me a project on GitHub that does.

Thanks,
jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Monty Taylor

 variables you have to remember to set in each project

I set no environment variables in each project. In fact, I don't set
anything up per-project. I'm very curious about what you're needing to
do here.

Unless... it's possible we have something unclear in the docs.

The docs for the initial setup commands list things like:

USERNAME=foo

which we did just to make the docs more readable. (If you're setting up
a git remote, and the username on the remote host is different than the
username on your local machine, you're going to need to add a username
into the ssh connection string. Thus, $USERNAME.)

If this is what you're talking about - I'll certainly see if we can't
clarify the docs.

 5. the 'git review' mechanism that prevents me from using 'git push' as 
 expected.

You can use git push. What is it you are expecting to be able to do
here? What can you not do?

 6. the git dances that have to be performed when something goes wrong

This is true of any git workflow with a large enough set of people that
is attempting to maintain a trunk with clean history. git is an
amazingly powerful tool and anybody using the system is going to need to
understand git, git history and git rebasing in order to do anything
tricky. The same would ultimately be true of github, the problem would
just show up later in the cycle.

 7. the gerrit remotes that have to be set up that break your mental model of 
 how git remotes work

Again, I'm going to ask you to be explicit on explaining your mental
model of how git remotes work.

 8. complete re-votes required after a re-review (unless that was intentional?)

That is intentional. After new changes are pushed, the code is, in fact,
new, and needs to be reviewed. However, the old reviews are still there
for reference.

 ... and that's only from my first few days using Gerrit. 

I should point out that there are several things we have in place to
simplify the simple case. It's possible you are the type of person who
would like to know more. It is entirely possible to use gerrit without
the git review alias. It's all based on git push, actually ... you just
have a to learn a couple of things. Would you be interested in looking
at the man behind the curtain? It's entirely possible we've made
incorrect assumptions about which bits should be hidden, and I'd love
feedback on that.

 Moreso, as was stated before, why are we even using github in this case? Why 
 not just stand up a git server? 
 Right now it feels like bubble-gum and binder twine.

github is simply a mirror of the canonical git repository, which is
maintained by gerrit. We mirror the code to github to make it easy for
people to discover and fork. We had several discussions with the PPB
about not mirroring to github, but it was decided that it was nicer for
people if we mirrored.

You can, however, COMPLETELY use this system without ever a single time
touching github.

 We're talking simple string parsing here. The last keyword from a user is 
 that users vote. Multiple pull requests would be equally easy to support with 
 a !new_vote command (or some such thing).
 
 I'm sure I'm missing some critical piece of data here. 

I don't want to extend any false senses here. We are no longer examining
roundabout or hubcap as possibilities. Transitioning workflow tooling
for a project like OpenStack is a huge and caustic endeavor. When the
PPB voted that projects would all use consistent tooling and that the
tooling would be git/gerrit for code hosting/review, the understanding
was that we were uninterested in re-addressing the question every time a
dev had a new idea of how we could do things. As you said in another
email, currently the code is just a hack (it's a nice hack, but it's
just a start) in order to even begin to conceive of using it in
production for all of openstack, it would have to be finished. Then we'd
have to work through how we'd organize and run things, how we'd
transition. We'd have to write docs. We'd have to do testing. We'd have
to work on the surrounding tooling.

Then, we'd have to go get buy in from the bazillion different
stakeholders in this project. We did, in fact, just recently, get
everyone's buy in on gerrit - including some folks who prefer
bzr/launchpad. (In fact, I was one of the people, if you'll remember,
who preferred bzr/launchpad. Life is about compromise)

So, with all due respect - work on hubcap if you like it as a project
and feel like hacking on it. I'm sure it will provide joy for some
projects out there just as roundabout has - but please understand that
OpenStack is not considering using it.

We _are_, on the other hand, quite strongly interested in bugs and/or
patches from folks addressing the current system.

Thanks!
Monty

 
 From: Monty Taylor [mord...@inaugust.com]
 Sent: Tuesday, September 06, 2011 11:31 PM
 To: Sandy Walsh
 Cc: Stefano Maffulli; openstack@lists.launchpad.net
 Subject: Re: [Openstack] A possible alternative to Gerrit

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
 On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt johan...@erdfelt.com 
 wrote:
  Why do core members have that merge and close option? Wouldn't it make
  more sense to restrict that to the Jenkins account?
 
  I still think you can do a gated trunk, even with github pull requests.
 
 Please show me a project on GitHub that does.

This is a weak argument. Even if no one has done it yet doesn't make it
a poor choice.

If a requirement is a gated trunk (which I think is a perfectly
reasonable requirement), then you only need to restrict pushes to
Jenkins.

I can certainly comment on pull requests that I can't push to on github.
The documentation says you can setup permissions to only allow pull and
not push.

So I'll turn this around on you and ask you to show me why this won't
work.

JE


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
 The problem is that instead of spending time coding on features and
 bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
 spending time working on an alternate solution to what has already
 been decided by the PPB, discussed publicly, and coded on for months
 by my team.

I understand you want people to get code done.

I completely agree, which is why *I'm* frustrated that it took hours to
get Gerrit working and then later ended up having to spend a few more
hours fighting with it after it changed silently.

Tools should be making our lives easier. Github/Gerrit should be easier
than LP/Bazaar, but that isn't the case right now.

I can understand your frustration and hopefully you can understand my
frustration.

Then hopefully we can figure out a way to avoid inflicting frustration
on others that will run into the same problems.

JE


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Ziad Sawalha

 busy on the project.

With this many devs, there will NEVER (and I cannot stress that word
never enough is a textual email) be full agreement on developer tooling.
However, what we can do is take in the input of everyone's needs and do
our best to design a system that meets those needs in a way that serves
the project as a whole. That this inevitably means that the needs or
preferences of individual developers may not be stroked is merely a
given with a project of this size.

My suggestion is that folks send feedback on specific issues you have
with the current git/gerrit/jenkins setup and we'll be happy to do what
we can to address them.

Thanks!
Monty

On 09/05/2011 10:14 AM, Sandy Walsh wrote:
 Absolutely. It's a holiday here (I'm just checking in periodically).
 
 Enjoy your day y'all!
 
 -S
 
 
 *From:* openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
 [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on
 behalf of Stefano Maffulli [smaffu...@gmail.com]
 *Sent:* Monday, September 05, 2011 12:35 PM
 *To:* openstack@lists.launchpad.net
 *Subject:* Re: [Openstack] A possible alternative to Gerrit ...
 
 2011/9/5 Sandy Walsh sandy.wa...@rackspace.com
 mailto:sandy.wa...@rackspace.com
 
 That said, whether we use roundabout or use the code that has
 already been created for the gerrit/jenkins integration is perhaps
 worthy of a discussion?
 
 
 I believe it is worth a discussion. Since today is a holiday in the US
 and many developers are offline I propose we pause this discussion for
 the rest of the day. I'll talk to Jay, Monty and Jim tomorrow and will
 come back with a plan to address the concerns raised on the list. Would
 that work for you?
 
 /stef
 This email may include confidential information. If you received it in
 error, please delete it.
 
 
 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, 
please delete it.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 1:03 PM, Johannes Erdfelt johan...@erdfelt.com wrote:
 On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
 On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt johan...@erdfelt.com 
 wrote:
  Why do core members have that merge and close option? Wouldn't it make
  more sense to restrict that to the Jenkins account?
 
  I still think you can do a gated trunk, even with github pull requests.

 Please show me a project on GitHub that does.

 This is a weak argument. Even if no one has done it yet doesn't make it
 a poor choice.

 If a requirement is a gated trunk (which I think is a perfectly
 reasonable requirement), then you only need to restrict pushes to
 Jenkins.

 I can certainly comment on pull requests that I can't push to on github.
 The documentation says you can setup permissions to only allow pull and
 not push.

 So I'll turn this around on you and ask you to show me why this won't
 work.

I never said that it couldn't work. I said that the system we have
also works, is already in place, and IMHO this entire discussion is
irrelevant until someone can convince the PPB to bring this matter up
again.

Use the tools that are provided and supported.

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 1:19 PM, Johannes Erdfelt johan...@erdfelt.com wrote:
 On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
 The problem is that instead of spending time coding on features and
 bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
 spending time working on an alternate solution to what has already
 been decided by the PPB, discussed publicly, and coded on for months
 by my team.

 I understand you want people to get code done.

 I completely agree, which is why *I'm* frustrated that it took hours to
 get Gerrit working and then later ended up having to spend a few more
 hours fighting with it after it changed silently.

Have these frustrations been resolved? If not, please ask jeblair and
mtaylor on IRC for help resolving them. I apologize for the
inconvenience it caused you.

 Tools should be making our lives easier. Github/Gerrit should be easier
 than LP/Bazaar, but that isn't the case right now.

I actually find the Gerrit review process both easier to use than LP
(no need to do a merge request, just git review and your done). I've
been using the system for 3-4 weeks now, and I am now comfortable with
it. Had a few growing pains in transitioning, but I've done dozens of
reviews and pushes now, and I'm satisfied it is a more robust system
than LP and Tarmac.

 I can understand your frustration and hopefully you can understand my
 frustration.

 Then hopefully we can figure out a way to avoid inflicting frustration
 on others that will run into the same problems.

That is certainly what Monty and Jim are trying to do, and why they
take seriously the input on hiccups and suggestions for improvement to
the Gerrit system in place. It is also why they are not considering
moving to another system and going through all of this all over again.

Thanks, and I appreciate your feedback.

-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

2011-09-07 Thread Chris Behrens


On Sep 7, 2011, at 9:21 AM, Jay Pipes wrote:
 The problem is that instead of spending time coding on features and
 bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
 spending time working on an alternate solution to what has already
 been decided by the PPB, discussed publicly, and coded on for months
 by my team.
 

It was not discussed publicly, unless I've somehow not received a ton of email. 
 There was no announcement that I can find to the list that 'Gerrit' was 
decided by the PPB.  There was no discussion about how we might want to modify 
it to fit our needs.  The development all happened mostly in the private as far 
as I can tell.  Not a lot of room for complaints until it was implemented for a 
repo that a fair amount of people use.  So, now there's complaints.

 Frankly, this whole situation hearkens back to when everyone except a
 few folks on the Titan team was griping about Launchpad and Bazaar,
 saying that they couldn't get anything done with these tools, except
 for some on the Titan team which just adapted and ended up being very
 productive using LP and Bazaar. If you guys would give Gerrit a chance
 and try to work with the toolset, instead of constantly going off and
 trying to make everything just GitHub, I think we'd actually be able
 to get more done.
 
 Just my two cents. You can probably tell I am quite frustrated with
 this debate going on *yet again*.

I understand your frustration.  I would be too if it were my team that had done 
months of development on it.  But I feel some of it could have been avoided if 
there actually public discussion up front.

That said, Sandy just provided a list of annoyances.  Johannes has provided 
some as well.  I haven't seen any comments, yet, on if any of those can be 
addressed.

- Chris


This email may include confidential information. If you received it in error, 
please delete it.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 7, 2011 at 2:19 PM, Chris Behrens
chris.behr...@rackspace.com wrote:

On Sep 7, 2011, at 9:21 AM, Jay Pipes wrote:
The problem is that instead of spending time coding on features and
bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
spending time working on an alternate solution to what has already
been decided by the PPB, discussed publicly, and coded on for months
by my team.

It was not discussed publicly, unless I've somehow not received a ton of
email. There was no announcement that I can find to the list that 'Gerrit'
was decided by the PPB.

False.
https://lists.launchpad.net/openstack/msg03493.html
http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-09-20.00.log.html

There was no discussion about how we might want to modify it to fit our needs.

False. There was lots of discussion on it.

Some conversations about GitHub, project autonomy, and migration going
back to June:

http://www.mail-archive.com/openstack-poc@lists.launchpad.net/msg00176.html
https://lists.launchpad.net/openstack-poc/msg00150.html
http://osdir.com/ml/openstack-cloud-computing/2011-08/msg00077.html

The development all happened mostly in the private as far as I can tell.

False. Not a single thing about the CI environment or the automated
patch queue management has been in private. It is all on GitHub, in
public repos, and documented publically:

https://github.com/openstack/openstack-ci
http://ci.openstack.org
http://wiki.openstack.org/GerritWorkflow

That said, Sandy just provided a list of annoyances. Johannes has provided
some as well. I haven't seen any comments, yet, on if any of those can be
addressed.

Refresh your email. LP's mailing lists are slow today. There's been
responses to all lists of annoyances, Chris.
-jay

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...

On Wed, Sep 07, 2011, Monty Taylor mord...@inaugust.com wrote:
 Part of this also comes from a semantic difference in how github and
 gerrit view the world. On github, you develop on your personal fork, and
 then you submit one of the branches in your fork to be pulled - so the
 unit of review is the branch- meaning that amended changes can be
 tracked. The thing you lose, though, is that you have to switch from
 your dev environment to your web browser to submit a change for review.

As a minor point of clarification, Github does have an API to create pull
requests. It's not required to go to a web browser.

http://develop.github.com/p/pulls.html

JE


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A possible alternative to Gerrit ...