I think that in practical terms, these patches would be module by module, not author by author. Ex: API changes as 1 patch, and UI changes as another. I think that approach works better for the committers too, since we've already broken the CS modules into areas of "maintainer responsibility". IMO, it allows larger features to be cleanly reviewed / integrated by those best suited to review each portion of the work.
-chip On Tue, Aug 7, 2012 at 7:42 PM, Kevin Kluge <kevin.kl...@citrix.com> wrote: > 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. >> > >> > >
