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.child...@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.mel...@eu.citrix.com> wrote: > >> -----Original Message----- > >> From: Brett Porter [mailto:br...@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.mel...@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. > > > >
