If this thread has anything clear to me at all, it's that adding
*more* people to this discussion isn't going to bring us any closer to
an agreement.
Here's a thought:
How about we appoint (formally, informally, whatever, it's beside the
point) someone (3-4 people tops) to come up with a set of
Sure, I agree with the below. I tend to think the PPB is the place for the
decision for the reasons you state below (though that's more than 3-4 people
tops). But whether it's the PPB or some other small group of people, I'd want
to see everybody have a chance to provide enough feedback for
Instead of a mailing list full of political posturing around our
toolset, how about someone post a concrete problem with gerrit, and
we'll pretend to be a bunch of engineers and solve it.
-Dolph
On 09/08/2011 04:27 AM, Chris Behrens wrote:
Sure, I agree with the below. I tend to think the
On Sep 8, 2011, at 2:27 AM, Chris Behrens wrote:
I say this for future decisions. At the moment, Gerrit is what was chosen
and I'm just interested in seeing if we can alleviate some of the pain my
team is having working with it.
I still believe that we can get the best of all worlds by
@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Vishvananda Ishaya [vishvana...@gmail.com]
Sent: Thursday, September 08, 2011 9:18 AM
To: Chris Behrens
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible alternative to Gerrit
Sandy,
I'm sorry that your suggestion unfortunately got caught up in the
general frustration about how the git/gerrit decision came about.
Hopefully future decisions can be debated/discussed more before they
are made rather than after they are implemented. This should be a
lesson learned by
On 09/08/2011 05:18 AM, Vishvananda Ishaya wrote:
On Sep 8, 2011, at 2:27 AM, Chris Behrens wrote:
I say this for future decisions. At the moment, Gerrit is what was
chosen and I'm just interested in seeing if we can alleviate some
of the pain my team is having working with it.
I
On 09/08/2011 02:27 AM, Chris Behrens wrote:
Sure, I agree with the below. I tend to think the PPB is the place
for the decision for the reasons you state below (though that's more
than 3-4 people tops). But whether it's the PPB or some other small
group of people, I'd want to see
Monty Taylor wrote:
I understand some of you are not comfortable with Gerrit [...]
Thanks for this explanation.
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
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
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
] 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
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
... 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
!
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
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.
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
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
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
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
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
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
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
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:
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
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
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
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
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,
@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
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
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
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
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
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
On Wed, Sep 07, 2011, Sandy Walsh sandy.wa...@rackspace.com wrote:
... and that's only from my first few days using Gerrit.
I'd also like to add that the when merges fail, it's not easy to figure
out why.
I had a proposed branch the was approved and then failed to merge. I
received a handful
On Sep 7, 2011, at 11:46 AM, Jay Pipes wrote:
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
Johannes Erdfelt johan...@erdfelt.com writes:
On Wed, Sep 07, 2011, Sandy Walsh sandy.wa...@rackspace.com wrote:
... and that's only from my first few days using Gerrit.
I'd also like to add that the when merges fail, it's not easy to figure
out why.
I had a proposed branch the was
Hi Chris,
2011/9/7 Chris Behrens chris.behr...@rackspace.com
Thanks. I see them. It's not that I didn't think there would be responses.
I'm just trying to keep us on track to trying to resolve the issues while I
still complain that *I* feel we should have had some more/earlier/better
, 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
Monty,
Is there a published list of work flow requirements for an/the
OpenStack project? Not really based on any specific implementation
or tool.
These is the closest thing I could find.
For bzr there are http://wiki.openstack.org/BzrPerfectWorkflow
Chris Behrens wrote:
But leaving aside whether I like it or dislike it, what really bothers me is
that there was discussion about moving things to github. And, I was 'ok'
with that decision to do so despite preferring bzr and LP. My 'ok' was based
on knowing how git, github pull requests,
] A possible alternative to Gerrit ...
Taking a bit of a step back, it seems to me that the biggest thing
that prevents us from using a pure github workflow is the absolute
requirement of a gated trunk. Perhaps a better question to ask
weather or not this should be an absolute requirement. For me
] on behalf of
Ewan Mellor [ewan.mel...@eu.citrix.com]
Sent: Monday, September 05, 2011 6:38 AM
To: Chuck Thier; Josh Kearney
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible alternative to Gerrit ...
I think a gated trunk is very important. We're going to have some pretty
subtle bugs
2011/9/5 Sandy Walsh 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
[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.commailto:sandy.wa...@rackspace.com
That said, whether we use roundabout or use the code
On Sep 5, 2011, at 5:12 AM, Thierry Carrez wrote:
Chris Behrens wrote:
But leaving aside whether I like it or dislike it, what really bothers me is
that there was discussion about moving things to github. And, I was 'ok'
with that decision to do so despite preferring bzr and LP. My 'ok'
Taking a bit of a step back, it seems to me that the biggest thing
that prevents us from using a pure github workflow is the absolute
requirement of a gated trunk. Perhaps a better question to ask
weather or not this should be an absolute requirement. For me, it is
a nice to have, but shouldn't
: [Openstack] A possible alternative to Gerrit ...
Sandy Walsh wrote:
Last night I did some hacking on HubCap. HubCap is a simple script that
monitors Pull Requests in GitHub. It spits out a static HTML page of the
requests workflow status.
[...]
I won't speak on behalf of Monty Taylor, Jim
On Sun, Sep 4, 2011 at 12:39 PM, Chuck Thier cth...@gmail.com wrote:
Taking a bit of a step back, it seems to me that the biggest thing
that prevents us from using a pure github workflow is the absolute
requirement of a gated trunk.
I think the big step backwards would be not having a gated
The coarse status granularity of GitHub's pull request is a
non-starter for automated patch queue management and a gated trunk.
Period. Solutions such as roundabout and hubcap must use hacks such as
looking in review comments for one or more lgtms to determine if a
commit is approved to be
Jay,
On Sep 4, 2011, at 10:52 AM, Jay Pipes wrote:
I actually didn't plan on responding all that much on this
conversation. We had months of discussion and debate about this, weeks
upon weeks of discussion in the PPB about project autonomy and
tooling, and the decision has been made.
I
Sandy,
Thanks for bring this up. I think it's an interesting idea and plan
on looking into it when I have some free time.
Thierry,
Seriously? while this anti-Gerrit revolt is being sent on the ML
Can we dial down the drama a bit?It's things like this that will
discourage people from
Jay Payne wrote:
Can we dial down the drama a bit?It's things like this that will
discourage people from submitting new ideas. Calling just the
introduction of a new idea a revolt is a diservice to the community.
Well, maybe revolt is not the best term, but this is about resisting
the
I don't intend to fan the fumes here, but I think the point we are trying to
make is that the decision to use Gerrit was made before most of the community
was even aware of it -- much less having a chance to come up with a solution
like Sandy did (which, IMHO, is far more practical than the
Subject: Re: [Openstack] A possible alternative to Gerrit ...
Sandy Walsh wrote:
Last night I did some hacking on HubCap. HubCap is a simple script that
monitors Pull Requests in GitHub. It spits out a static HTML page of the
requests workflow status.
[...]
I won't speak on behalf of Monty Taylor
56 matches
Mail list logo
