On Fri, Nov 11, 2011 at 1:12 AM, Paolo Castagna <[email protected]> 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 people.apache.org/~leosimons/, 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 *it*. 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. cheers, Leo [1] The only reason this mechanism doesn't work well in incubation is you need to get votes from the incubator PMC.
