On 2 August 2012 08:11, Ewan Mellor <ewan.mel...@eu.citrix.com> wrote:
> > > The problem with that is that entire features that are not developed > > within the project have a different process for inclusion. > > Particularly when they are features that multiple people have > > collaborated on externally. > > Could you define "within the project"? git is designed for a workflow > where someone takes a branch, collaborates for a bit on it, and then comes > back with the finished changes. This is exactly what has happened here, > and it's the kind of thing that happens in the Linux kernel (for example) > all the time. > At Apache we have a saying... "if it didn't happen on the dev@ list, it didn't happen". The Linux kernel has a very different model for development than an Apache project. Acceptance of code here is based on consensus of people on this list, and for that to happen, those working on the code need to engage on dev@ early, and regularly. What should happen is that as features are proposed for Apache CloudStack, they are brought up here, and all the committers can decide where they will land in git, which release they might suit, etc. If a group of people who are not currently committers need a place to work, then the project can figure out how to address that. I don't like the phrase "the ASF branch of CloudStack". If I may be a little blunt: for this project to be successful, Citrix will need to stop thinking of Apache CloudStack as a downstream destination for features, and instead as an upstream for their future releases. This is a pretty huge shift in the mental model for developing features, but incredibly valuable for growing a community around them. I understand getting a first release out here will make that easier, but that's not a blocker to starting to do it now. As far as how work like this gets accepted, I had a draft last week when David beat me to it and wrote this summary to the list: http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201207.mbox/%3CCAKprHVZvxjbNC3vXb2GeTwhjGusbWYAOKuzBmCYP2VY1LwMFBg%40mail.gmail.com%3E Everyone participates as an individual, regardless of their affiliation. Committers need to comply by sections 5 and 7 of their ICLA ( http://www.apache.org/licenses/icla.txt). If there is work being submitted by multiple people, then all ASF projects fill out an IP clearance form for each work to record its origin. It isn't necessarily an onerous process, but it's not one that should be the normal way of doing work. This isn't just to establish provenance, but also to ensure development is happening within the Apache CloudStack community and giving everyone a chance to participate. At the very least, there needs to be some discussion here about the process for accepting it, and consensus that it should be accepted. It is also important that all the people involved in working on these features are visible to cloudstack-dev so that they can be considered as committers in future. If groups work in private branches or semi-private branches, then someone gets excluded - that'll either be the rest of the CloudStack community, or those that worked in private if they later find their work doesn't get accepted. More than licensing and release issues, building a diverse community, and working out how everyone here works together is the key issue for this community to sort out before graduation (and was recognised as such in the initial proposal). This technology moves so fast that technical issues are going to come and go - but a solid community that works well together will be able to meet future challenges and conflict. I know everyone is interested in making that happen, and it will happen - for now it's just going to take some time, and moving out of some "comfort zones". Hope that makes sense! Cheers, Brett -- Brett Porter http://brettporter.wordpress.com/
