On 27/03/2016 Patricia Shanahan wrote:
On 3/26/2016 10:37 AM, Andrea Pescetti wrote:
3) We recognize that http://svn.apache.org/viewvc/openoffice/ has
different areas, and that not all of them should be subject to the same
policy. Just like I don't call a release vote when I change a web page
(the full site is hosted under that tree, so technically I am making a
"website release" every time I update a page), we could recognize that
everything in devtools/ is just a set of tools that we can make
available with lazy consensus and no need for a formal release. This is
my favorite option.
This option does not appear to me to conform to
http://www.apache.org/dev/release.html.
Then all of us are violating the policy every time we update the
website. It's a matter of interpreting things correctly. Trunk,
branches, tags are for sure subject to the standard release policy. The
website is for sure not subject to it (no human with a grain of salt can
imagine a release vote for a typo fix on a web page, right?). The rest
is... well, in between.
That suggests that a good enough justification for a deviation could get
"prior, explicit board approval". How about asking the board for approval?
We can ask the board for advice, why not. But my recommendation is: get
three PMC members to commit to voting on this release before we explore
the "real release" option. Once we know that at least three PMC members
will vote, then this discussion make sense. There will be quite a few
arrangements to do since (for example) we don't want to break our
release tree layout, which was the subject of endless discussions in the
past, but if three PMC members are available and willing to do a formal
release we have the basic steps done. And actually... if we have three
volunteers then we can get it done even without asking the Board!
I thought about examples but I can't find anything similar. Solr is
released by Lucene, see
https://dist.apache.org/repos/dist/release/lucene/ but those are real
end-user software packages in themselves, while here we are discussing a
development tool.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
