incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject How to decide to release (was: Re: JIRA issues and "Fix Version/s"...)
Date Fri, 11 Nov 2011 11:24:12 GMT
On Fri, Nov 11, 2011 at 1:12 AM, Paolo Castagna
<> wrote:
>> In other words, do things pretty much like jena has always done
>> them...but hey, you asked ;-)
> Ok, I'll take the advice and remove the "Fix Version/s" when used in
> forward looking/planning mode. But, I'll leave them in when an issue
> is closed pointing to the version when the issue has been fixed.
> I still thing there is some value in communicating (closer to a release
> what's still missing so that people who want to help out knows where
> they can help).

You are completely right of course. Communicating = good.

However, I'm not quite going to let go, since I still think your
mental model could deserve a bit more skew towards radicalism :-D

At this point I would like to introduce a new (well...) and radical
anti-bureaucratic apache concept: in any not-incubation [1] apache
project, at any point, anyone, committer or not (thought it would be
extremely weird if they weren't), can decide that it's time for a
release, roll a release candidate build, and ask for a vote on the
mailing list. If they get 3 +1, and more +1s than -1s, that release
candidate becomes an official release.

For example, I could, right now, build some jena tarballs, label that
version 3.0, and stick them on, and call
for a vote. If I do get enough votes (not that I would...), that's a
release. No matter whether jira says there's outstanding issues,
whether any particular company has a corporate roadmap that ties into
a jena release plan. The project has voted, it has decided, that is

This is a core meritocratic concept. If you step up to do the work
(whatever the work is, including releasing...), you get to do it.

OTOH, since consensus-based working is our other core concept, it's
very very VERY rare to actually see things go down like this. Releases
are usually pretty frictionless events.

Yet, this approach is what the original apache group and then later
apache httpd followed and they have followed it ever since. It can be
quite useful at times. If you work like this, trunk (or stable or
whatever branch) is implied to always be in a release-able state, and
no-one gets to hold the project "hostage" (along the lines of "I will
-1 the release until the bug _I_ care about is fixed").

> Long email threads do not work so well as a list of issues on JIRA
> grouped by a future release version. I am not saying we do this for
> medium-long term stuff (I'll remove what I did on JIRA), but I do not
> see what are the cons in the short term.

I see no particular cons either, I'm absolutely +1 on having decent
organization, and I applaud you for trying to put organization and
focus into jira.

But I replied anyway, just to make sure you keep in mind how the
decisions are actually made (by people stepping up to do the work and
voting with their feet), and communicate that, too! :). In particular,
I don't want you to feel bad when you invest a lot in all this
roadmapping work, and then jena as a community votes to release
anyway, ignoring the fact there's some outstanding issues you felt
should have been part of the release.



[1] The only reason this mechanism doesn't work well in incubation is
you need to get votes from the incubator PMC.

View raw message