Hi Ewan, On 03/08/2012, at 1:57 AM, Ewan Mellor <ewan.mel...@eu.citrix.com> wrote:
> > We are precisely trying to make Apache the upstream. This code is something > that we're trying to submit to the project for exactly that reason -- so that > 4.0 can be the upstream. Nobody at Citrix wants ASF to be the downstream. > > We are going through a transition period here where code was held out of the > master branch because of all these policy issues that weren't resolved. Now > that we know what we're doing with our code and where it's going, we want to > get it into 4.0 so that we can make a clean break and have all the code in > one place at Apache. I completely understand that, sorry if I didn't make it clear enough from my mail. I'm not intending to beat anyone up here! My concern is that if that process happens during the transition, it may happen the next time there is some sort of time pressure that is mismatched. I think it's important that the pattern is established correctly right now, rather than after the release. I'm sure if there are any difficulties about making contributions, we can work through that openly at the start of any piece of development. I understand that for the work in question, contributions are being handled the right way after the initial commit, which is great - we just need to ensure it is clear that there aren't any more of those in future. > > ICLAs we can do. I will make sure that everyone who has worked on this > branch has signed the ICLA. > > However, we do need to work out a process for accepting changesets with > multiple authors. It is very normal for two people to work on something and > for this to turn into a single changeset ready for review. This is > inevitable in cases where people are buddy-coding, or where junior staff are > having their work checked internally, or where it's talking to something on > the far side (NetScaler 10 in this case) that is being developed in parallel. > It is also very common when working with foreign teams (I have seen it a lot > when working with Japan) because most developers inside those teams can't > speak English and can't engage in the review process. We absolutely have to > be prepared for someone to show up with a patch who says "I am submitting > this on behalf of X, Y, and Z". (Apologies if my cluelessness about the technology shows through here, but hopefully you still get the point). 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? There's a difference between working closely together and working privately. If it's intended to be included in CloudStack, then the project needs to have oversight over the work, and anyone needs to have the ability to participate. A single committer can regularly apply multiple separate contributions, but they should never commit a completed work that has been going on for weeks without any incremental review. That is a recipe for building frustration among other committers that will build up over time - no one should ever feel like they're in that position here. I agree in that you've raised some real issues that do need to be addressed. How do non-committers who work full time on the project involve themselves? Lots of discussion on this and reviewboard recently that seems to be firming up the right pattern. How do people who can't easily communicate with the list participate? Perhaps we do need a designated point-person in such cases that can make it as transparently as possible. How does the project deal with its size and that very few people can be across everything that is happening? There was a bit about the maintainer model early in discussions, but I'm not sure if that fully addressed that question. I'd love to hear from committers on how they feel this is faring, and how these issues might be addressed in a way that remains inclusive of everyone wishing to participate. Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
