cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: where features are developed was: Review Request: Merge Kelven's VPC code for Vmware into asf vpc branch
Date Thu, 02 Aug 2012 01:08:28 GMT
On 2 August 2012 08:11, Ewan Mellor <> 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:

Everyone participates as an individual, regardless of their
affiliation. Committers need to comply by sections 5 and 7 of their ICLA ( 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!


Brett Porter

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message