Mark McLoughlin wrote:
>> * Subsystem branches with area experts are used wherever possible. The
>> subsystem maintainer should maintain this branch so that it can directly
>> be merged into master when "ready" (all or nothing). Subsystem
>> maintainers are allowed to propose a merge commit to mast
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.
>
>
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
On Fri, 2012-05-11 at 17:22 -0700, Vishvananda Ishaya wrote:
> On May 11, 2012, at 2:04 PM, Mark McLoughlin wrote:
> >
> > I'm guessing we could easily flick a switch in gerrit to cause it to
> > rebase instead of merge.
> >
> > I don't remember any debate about it, but I'm also guessing there ar
On Fri, 2012-05-11 at 17:44 -0700, James E. Blair wrote:
> On 05/11/2012 02:04 PM, Mark McLoughlin wrote:
> > On Fri, 2012-05-11 at 13:57 -0700, David Lutterkort wrote:
> >> On Fri, 2012-05-11 at 12:37 +0100, Mark McLoughlin wrote:
> >>>- Our history is far from "clean history", it's pretty dis
On 05/11/2012 02:04 PM, Mark McLoughlin wrote:
On Fri, 2012-05-11 at 13:57 -0700, David Lutterkort wrote:
On Fri, 2012-05-11 at 12:37 +0100, Mark McLoughlin wrote:
- Our history is far from "clean history", it's pretty disgusting
really. The ratio of interesting commits to merge commits
On May 11, 2012, at 2:04 PM, Mark McLoughlin wrote:
>
> I'm guessing we could easily flick a switch in gerrit to cause it to
> rebase instead of merge.
>
> I don't remember any debate about it, but I'm also guessing there aren't
> any hugely strong opinions in OpenStack about which is better.
>
On Fri, 2012-05-11 at 13:57 -0700, David Lutterkort wrote:
> On Fri, 2012-05-11 at 12:37 +0100, Mark McLoughlin wrote:
> > - Our history is far from "clean history", it's pretty disgusting
> > really. The ratio of interesting commits to merge commits is
> > roughly 3:2, which is pretty
On Fri, 2012-05-11 at 13:40 -0700, James E. Blair wrote:
> Mark McLoughlin 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 the
Mark McLoughlin 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, Jenkins r
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 a
Hi James,
On Tue, 2012-05-08 at 14:03 -0700, James E. Blair wrote:
> Mark McLoughlin 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 w
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 a
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 re
Mark McLoughlin 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 slightly differ
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
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
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 m
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-
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 y
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 obj
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
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 understa
23 matches
Mail list logo
