You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Leo Simons <ma...@leosimons.com> on 2011/11/11 12:24:12 UTC
How to decide to release (was: Re: JIRA issues and "Fix Version/s"...)
On Fri, Nov 11, 2011 at 1:12 AM, Paolo Castagna
<ca...@googlemail.com> 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.
Re: How to decide to release (was: Re: JIRA issues and "Fix Version/s"...)
Posted by Paolo Castagna <ca...@googlemail.com>.
Andy Seaborne wrote:
> JENA-110
> Decide on doc/ (/me don't put in the downloads)
+1 on removing doc/ entirely
The official documentation is on the website.
Paolo
Re: How to decide to release (was: Re: JIRA issues and "Fix Version/s"...)
Posted by Andy Seaborne <an...@apache.org>.
Oh - and answering user questions, incoming non-committer contributions
and even some technical work as well!
Andy
On 11/11/11 12:34, Andy Seaborne wrote:
> Actual progress is being made!
>
> Ian has been porting the documentation to the Apache website.
>
> This has been a huge amount of work.
>
> Dave and Ian have cleaned and checked code where there was BSD
> contributions.
>
> Other things done:
>
> + putting all the required files and content in place
> + sorting out BSD contributions by removing, rewriting
> or getting software grants for the contribution
> + updating the source code headers
> + adjusting the zip builds
> + Trying out -Papache-release
> + testing and breaking things
>
>
> A *lot* more checking needs to be done, not by me who sees what should
> be there and not what is there, especially checking the contents of zip
> files.
>
> I'm assuming an RC cycle after (IRI/Jena/ARQ)
>
> JENA-110
> Decide on doc/ (/me don't put in the downloads)
>
> but that's just me.
>
>
> There are TDB-isms but they are not blocks on the rest of IRI/Jena/ARQ.
>
>
> According to cloc(1):
>
> Module files blank comment Java
> ---------------------------------------------------------------
> Jena2 1324 29574 79048 127164
> ARQ 1428 24715 41481 124612
> LARQ 39 700 1004 2850
> IRI 56 3894 9168 8418
> TDB 384 7478 11343 30159
> Fuseki 84 1450 2997 6495
> SDB 350 4592 8215 17986
>
>
> Andy
Re: How to decide to release (was: Re: JIRA issues and "Fix Version/s"...)
Posted by Andy Seaborne <an...@apache.org>.
Actual progress is being made!
Ian has been porting the documentation to the Apache website.
This has been a huge amount of work.
Dave and Ian have cleaned and checked code where there was BSD
contributions.
Other things done:
+ putting all the required files and content in place
+ sorting out BSD contributions by removing, rewriting
or getting software grants for the contribution
+ updating the source code headers
+ adjusting the zip builds
+ Trying out -Papache-release
+ testing and breaking things
A *lot* more checking needs to be done, not by me who sees what should
be there and not what is there, especially checking the contents of zip
files.
I'm assuming an RC cycle after (IRI/Jena/ARQ)
JENA-110
Decide on doc/ (/me don't put in the downloads)
but that's just me.
There are TDB-isms but they are not blocks on the rest of IRI/Jena/ARQ.
According to cloc(1):
Module files blank comment Java
---------------------------------------------------------------
Jena2 1324 29574 79048 127164
ARQ 1428 24715 41481 124612
LARQ 39 700 1004 2850
IRI 56 3894 9168 8418
TDB 384 7478 11343 30159
Fuseki 84 1450 2997 6495
SDB 350 4592 8215 17986
Andy