cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Riou <>
Subject Releases, snapshots, nightlies and all that stuff
Date Thu, 13 Aug 2009 16:24:49 GMT
Hi guys,

Release practices seem to be getting more and more painful for you so I hope
to clarify as much as possible here. Or at least start a good flame war,
huh, discussion ;)

So Apache has its root in a group of people developing in the open a piece
of software that became massively popular. That came with all sort of good
sides but with a really bad side as well, opening the door to litigation.
And clearly, that wasn't something they were just making up. When you're a
BigCo making millions selling a piece of IP (which software is) and all of a
sudden a bunch of hippies release a free product that's better than yours,
it's horribly tempting to put one of those lawyers of yours to work. So said
hippies incorporated the ASF to provide an umbrella, avoid the possibility
of being sued personally and develop a legal framework to develop open
source code. The Apache License, ICLAs committers sign (which I'm sure you
all read), code grants, all that stuff is part of it.

Now fast forward to 2009, the ASF is this big thing with many more projects
developed by an awful lot of mostly nice people. To be able to handle that
lot without too much pain and again mitigate risks, the ASF had to put in
place oversight and frankly, I think it's still quite light. You have the
board, taking care of the whole foundation, top level projects with their
chair acting as contact point and the Project Management Committee (I know,
quite a mouthful) doing the actual project oversight. And the committers
which, really, have the best role.

Now the incubator is a little special in the sense that its aim is not to
develop code directly but to grow external, pre-existing projects into
ASF-style governance and communities (and lobotomize all of them, HA HA HA).
Being a classic top level project, the incubator has a PMC and it is that
PMC that exercises its oversight on incubating projects. To facilitate
contact with each project, the IPMC asks a few of its members to volunteer
mentoring newcomers until they graduate and that, my friends, can be a hard

So now that it's all clarified, it's time to come to the part we all love to
hate: policies! And because all sorts of different projects come to the
incubator, it has to have a lot of rules to rein in all that creativity a
bit. And more often than not, those rules are pretty fuzzy. And that's often
by design. Mind torture. Actually not, the idea is to try to carry the
intent and not the means, so that projects aren't artificially restricted
and the rules don't need to be rewritten every month. I know it's often
frustrating, especially for us developers, because you don't always know
where to stand and we (the IPMC) could do a better job at that. My advice is
when you're not sure, look what other TLPs are doing.

Now specifically, releases are very important because they're the main
interface between to project and the outside world. And that's what ends up
in people codebases. Policy on releases is here: I'll quote Ant here who's much
better than I am at summing it up:

- Releases are, by definition, anything that is published outside of the dev
list. If the general public is being instructed to download a package, then
that package has been released.

- Each PMC MUST obey the ASF requirements on approving any release.

- Do not include any links on the project website that might encourage
non-developers to download and use nightly builds, snapshots, release
candidates, or any other similar package.

- Under no circumstances are unapproved builds a substitute for releases.

In the above, developers are people developing on the project, not any
developer. You could say committers but that's often a little too
restrictive. The intent is to make sure people don't mistake a random build
for an official release when it's not IP-cleared (say it includes LGPL code)
and then freak out. People have grown accustomed to the Apache License and
the fact that they're not bound to any additional term and have high
expectations (which is really good in my opinion, open source IP is murky

So the idea is that if you want to publish something without having to worry
about its use, make an official release. There's more rubber stamping
involved (especially in the incubator) but that's for good reasons and down
the road it makes your like easier. For anything else, be extra careful.

Hope this helps a bit.


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