incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: where features are developed was: Review Request: Merge Kelven's VPC code for Vmware into asf vpc branch
Date Fri, 03 Aug 2012 02:53:59 GMT
Hi Ewan,

On 03/08/2012, at 1:57 AM, Ewan Mellor <Ewan.Mellor@eu.citrix.com> wrote:

> 
> We are precisely trying to make Apache the upstream.  This code is something that we're
trying to submit to the project for exactly that reason -- so that 4.0 can be the upstream.
 Nobody at Citrix wants ASF to be the downstream.
> 
> We are going through a transition period here where code was held out of the master branch
because of all these policy issues that weren't resolved.  Now that we know what we're doing
with our code and where it's going, we want to get it into 4.0 so that we can make a clean
break and have all the code in one place at Apache.

I completely understand that, sorry if I didn't make it clear enough from my mail. I'm not
intending to beat anyone up here!

My concern is that if that process happens during the transition, it may happen the next time
there is some sort of time pressure that is mismatched. I think it's important that the pattern
is established correctly right now, rather than after the release. I'm sure if there are any
difficulties about making contributions, we can work through that openly at the start of any
piece of development. I understand that for the work in question, contributions are being
handled the right way after the initial commit, which is great - we just need to ensure it
is clear that there aren't any more of those in future.

> 
> ICLAs we can do.  I will make sure that everyone who has worked on this branch has signed
the ICLA.
> 
> However, we do need to work out a process for accepting changesets with multiple authors.
 It is very normal for two people to work on something and for this to turn into a single
changeset ready for review.  This is inevitable in cases where people are buddy-coding, or
where junior staff are having their work checked internally, or where it's talking to something
on the far side (NetScaler 10 in this case) that is being developed in parallel.  It is also
very common when working with foreign teams (I have seen it a lot when working with Japan)
because most developers inside those teams can't speak English and can't engage in the review
process.  We absolutely have to be prepared for someone to show up with a patch who says "I
am submitting this on behalf of X, Y, and Z".


(Apologies if my cluelessness about the technology shows through here, but hopefully you still
get the point).

What happens if there's a rockstar NetScaler developer lurking here - how do they get involved
in that? What if the people buddy-coding are working on the same feature as someone that doesn't
work with them - how will they collaborate?

There's a difference between working closely together and working privately. If it's intended
to be included in CloudStack, then the project needs to have oversight over the work, and
anyone needs to have the ability to participate. A single committer can regularly apply multiple
separate contributions, but they should never commit a completed work that has been going
on for weeks without any incremental review. That is a recipe for building frustration among
other committers that will build up over time - no one should ever feel like they're in that
position here.

I agree in that you've raised some real issues that do need to be addressed. How do non-committers
who work full time on the project involve themselves? Lots of discussion on this and reviewboard
recently that seems to be firming up the right pattern. How do people who can't easily communicate
with the list participate? Perhaps we do need a designated point-person in such cases that
can make it as transparently as possible. How does the project deal with its size and that
very few people can be across everything that is happening? There was a bit about the maintainer
model early in discussions, but I'm not sure if that fully addressed that question.

I'd love to hear from committers on how they feel this is faring, and how these issues might
be addressed in a way that remains inclusive of everyone wishing to participate.

Cheers,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter






Mime
View raw message