Chip , thanks for this proposal, I like 1 and 2. On #3, are you assuming that in the event a team of committers and non-committers are working on a large feature, the changesets for the feature will be applied incrementally into the Apache repo by one of the committers? If that is the case then could we not set author for that commit as the actual author rather than the whole team?
-kevin > -----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. > > > >
