incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ewan Mellor <Ewan.Mel...@eu.citrix.com>
Subject RE: where features are developed was: Review Request: Merge Kelven's VPC code for Vmware into asf vpc branch
Date Tue, 07 Aug 2012 20:59:00 GMT
That makes a lot of sense to me, thanks Chip.

For those public repos for non-committers, I presume that they can't use Apache infrastructure,
so Github would be the natural choice.  We have a mirror there now (as of last week) so people
can clone and work there.  How does that sound?

Regarding the third point, I don't know what the ASF requires in terms of authorship indicators
in commit messages.  We obviously need all authors to have signed the ICLA, but other than
that I don't know of a written policy.  Unless there's something contradictory, putting the
Author names in the commit message seems reasonable to me.

Cheers,

Ewan.


> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, August 06, 2012 8:26 AM
> To: 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
> 
> 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