cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: where features are developed was: Review Request: Merge Kelven's VPC code for Vmware into asf vpc branch
Date Mon, 06 Aug 2012 15:26:27 GMT
Ewan / Brett,

I've been watching this thread closely, but holding off on commenting
until I was able to get some thoughts straightened out in my own head
over the weekend.  This is a critical discussion for the community,
since there are going to be an increasing number of
organization-sponsored developers wanting to contribute to the
project.  I don't see this as a "Citrix-only" issue at all, although
it's the first group to run into the problem here.

I tend to look for "first principals" in any discussion like this.
IMO, our goals should be to (1) apply the "Apache Way" to the ongoing
development of CloudStack (including fostering an environment where
individuals collaborate, are given rights based on merit, discuss work
transparently with the rest of the community, etc...), and (2) to
enable organization-sponsored development teams to meaningfully
contribute to the project's evolution.  We are also constrained a bit
by ASF process: specifically around commit rights to the repo for
contributors.

Given those goals, I'd like to float a proposal for the community's
consideration:

1 - Decisions and collaboration is always done "on list", including
discussions between contributors that are not currently committers.
To me, this is the most important part of this proposal...  focused on
building the community.
2 - Groups of developers that include non-committers should be
encouraged to use a public git repo for their work (and share the
location with the dev list).  This provides transparency for the rest
of the community.
3 - Work coming into the project from one of these collaborative
projects will be credited to all developers that were part of the
collaboration.  This can be done by asking that group of collaborators
to take their "clean patches" through the review board process.
Whichever committer applies them into the ASF repo would include the
names of all contributors in the commit message.

I'm not sure if this approach solves all of the issues, but can we use
it as a starting point to work towards an agreement?  Does it cover
the ASF policy requirements?

-chip


On Sun, Aug 5, 2012 at 11:17 PM, Ewan Mellor <Ewan.Mellor@eu.citrix.com> wrote:
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett Porter
>> Sent: 05 August 2012 05:35
>> To: cloudstack-dev@incubator.apache.org
>> Cc: cloudstack-dev@incubator.apache.org
>> Subject: Re: where features are developed was: Review Request: Merge
>> Kelven's VPC code for Vmware into asf vpc branch
>>
>>
>>
>> On 04/08/2012, at 12:16 PM, Ewan Mellor <Ewan.Mellor@eu.citrix.com>
>> wrote:
>>
>> >> 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?
>> >
>> > My point wasn't that people won't be collaborating.  My point was that by
>> the time things land in master, they may have multiple authors associated
>> with them.  The people working on this branch have been prototyping,
>> making mistakes along the way, and keeping up with changes in the systems
>> that they're talking to.  And while all that has been going on, master has been
>> moving forward at a great lick.
>>
>> But where will they collaborate, in an inclusive manner, if not in the ASF repo
>> and list, with the usual project patch submission mechanism?
>
> They'll be collaborating in private branches.  Most people working on CloudStack aren't
committers, so this will be the only way it can work.  Your proposal implies that either:
> 1. Developers can't commit regularly and often (bad),
> 2. Non-committers are allowed to commit to feature branches (currently not allowed),
or
> 3. We have committers review patches to unfinished feature branches as well as master
(obviously not workable).
>
> Are you proposing that we change one of those?
>
>> >
>> > By the time the feature lands in master, we're not going to see all those
>> prototypes and mistakes, because it would be impossible to merge them all
>> by now, and we certainly don't want to review changes that are wrong.
>> We're going to see a small number of clean changesets that apply against
>> HEAD.  That's what we will be reviewing for submission into master.
>>
>> That's part of the problem I see with this - the thought processes, prototypes
>> and even mistakes are helpful for others to understand why something
>> ended up the way it did. Early review is far more effective than reviewing a
>> large final commit if you have suggestions, especially if they are fundamental
>> to the change. All that information is useful to keep in the ASF repository
>> history.
>
> It's arguable whether that history is useful to anyone, but anyway that's not the point.
 The issue is whether people have to perform peer-review on those mistakes.  The mistakes
might be useful for historical reasons, but they certainly aren't something that we want our
committers to be peer-reviewing.  By the time it's ready for review, those changesets have
to be collapsed into a logical, consistent, and mistake-free set, otherwise they're impossible
to review.
>
>> > The consequence of that is that a single changeset will have multiple
>> authors.  This is what happened to Vijay B the other day -- he turned up with
>> a sanitized, ready-for-merge changeset, and he got shouted at for submitting
>> someone else's code.  We have to figure out how to handle this.  Telling him
>> to go away isn't going to work.
>>
>> Let's be clear - no one is being shouted at, and no one is being told to go
>> away - quite the opposite. I certainly apologise if I've come off that way.
>
> No, you weren't coming off that way at all.  Other people on this list were, though.
>
> Cheers,
>
> Ewan.
>
>

Mime
View raw message