Hey,
Hi On Mon, 2012-05-14 at 14:51 +0200, Thierry Carrez wrote:
James E. Blair wrote:
Vish, Thierry, and I spent some time together this week at UDS trying to
reconcile their needs and your suggestions. I believe Thierry is going
to write that up and send it to the list soon.
While at
--
From: Thierry Carrez thie...@openstack.org
Date: Mon, May 14, 2012 at 7:51 AM
Subject: Re: [Openstack] Nova subsystem branches and feature branches
To: openst...@lists.launchpad.net
James E. Blair wrote:
Vish, Thierry, and I spent some time together this week at UDS trying to
reconcile
James E. Blair wrote:
Vish, Thierry, and I spent some time together this week at UDS trying to
reconcile their needs and your suggestions. I believe Thierry is going
to write that up and send it to the list soon.
While at UDS we took some time to discuss a subsystem branch models that
would
Hey,
cdub sent on these interesting links:
http://lwn.net/Articles/328438/
https://lkml.org/lkml/2012/3/22/489
tl;dr on those is that you're likely to be flamed as a f*cking moron by
Linus unless you manage to understand every little nuance about how he
thinks git should be used :-)
It's
On Fri, 2012-05-04 at 17:11 -0700, Chris Wright wrote:
* Mark McLoughlin (mar...@redhat.com) wrote:
- Subsystem branches would not rebase unless the project dictator
outright rejects a merge request from the subsystem branch (i.e.
I'm not merging commit abcdef0! Fix it and
Hi James,
On Tue, 2012-05-08 at 14:03 -0700, James E. Blair wrote:
Mark McLoughlin mar...@redhat.com writes:
Hey,
We discussed this during the baking area for features design summit
session. I found that discussion fairly frustrating because there were
so many of us involved and we
Hey,
So, one thing came really stuck out to me when comparing our process to
the kernel process:
In the kernel process, maintainers are responsible for running
'git-merge' and they see it as their job to resolve conflicts.
In our process, Jenkins runs 'git-merge' and runs away screaming
Mark McLoughlin mar...@redhat.com writes:
Hey,
So, one thing came really stuck out to me when comparing our process to
the kernel process:
In the kernel process, maintainers are responsible for running
'git-merge' and they see it as their job to resolve conflicts.
In our process,
On Fri, 2012-05-04 at 12:28 -0700, Vishvananda Ishaya wrote:
Apologies for top posting. Just wanted to say +1
This all makes sense to me.
Great, thanks.
We should start trying to do some of this. One thing to figure out is
what our first subsystem branch should be? What we choose isn't so
Mark McLoughlin mar...@redhat.com writes:
Hey,
We discussed this during the baking area for features design summit
session. I found that discussion fairly frustrating because there were
so many of us involved and we all were either wanting to discuss
slightly different things or had a
Apologies for top posting. Just wanted to say +1
This all makes sense to me.
Vish
On May 3, 2012, at 4:08 AM, Mark McLoughlin wrote:
Hey,
We discussed this during the baking area for features design summit
session. I found that discussion fairly frustrating because there were
so many of
Overall, I think you've described problem and solutions well. A few
thoughts below.
* Mark McLoughlin (mar...@redhat.com) wrote:
Firstly, problem definition:
- Nova is big, complex and has a fairly massive rate of churn. While
the nova-core team is big, there isn't enough careful
Hey,
We discussed this during the baking area for features design summit
session. I found that discussion fairly frustrating because there were
so many of us involved and we all were either wanting to discuss
slightly different things or had a slightly different understanding of
what we were
Mark McLoughlin wrote:
We discussed this during the baking area for features design summit
session. I found that discussion fairly frustrating because there were
so many of us involved and we all were either wanting to discuss
slightly different things or had a slightly different understanding
On 05/03/2012 05:24 AM, Thierry Carrez wrote:
(snip things I pretty much agree with)
(I'm not sure gerrit is right for this. Why not just do it in
folk's github forks? I think all people are looking for is for
people to be more aware of feature branches. How about if you put
Hey,
On Thu, 2012-05-03 at 14:24 +0200, Thierry Carrez wrote:
Mark McLoughlin wrote:
Ok, what are subsystem branches and how would they work?
[...]
- It would be up to the project dictators to help drive patches
through the right subsystem branches - e.g. they might object if
On Thu, 2012-05-03 at 16:46 +0100, Mark McLoughlin wrote:
Hey,
On Thu, 2012-05-03 at 14:24 +0200, Thierry Carrez wrote:
Mark McLoughlin wrote:
And how about feature branches?
- Feature branches are relatively short-lived (i.e. weeks or months
rather than years) branches
On 05/03/2012 08:50 AM, Mark McLoughlin wrote:
On Thu, 2012-05-03 at 16:46 +0100, Mark McLoughlin wrote:
Hey,
On Thu, 2012-05-03 at 14:24 +0200, Thierry Carrez wrote:
Mark McLoughlin wrote:
And how about feature branches?
- Feature branches are relatively short-lived (i.e. weeks or
18 matches
Mail list logo
