IMO (and seems to be confirmed by the voting guide [1], "Votes on
Package Releases") what is important here is not a single -1 (a
release is a majority vote, and can not be vetoed), but a consensus,
formal or informal, to suspend the release vote to address a serious
technical issue. So delaying the release, unlike publishing it, is
more about a consensus than formality (unless it becomes contentious,
which I hope it doesn't), as the former has no ASF and contributor
related legal consequences, while the later does.
Andrus
[1] http://apache.org/foundation/voting.html
On Dec 7, 2008, at 9:30 PM, Kevin Menard wrote:
Mike can weigh in a bit more on procedure. I think what should really
happen is someone cast a -1 to veto and then we retry the process.
--
Kevin
On Sun, Dec 7, 2008 at 11:26 AM, Andrus Adamchik <[EMAIL PROTECTED]
> wrote:
Tore, I committed a fix (essentially undoing ~60% of CAY-1138) to
both trunk
and M5 tag. Could you please try it out before we create the new
artifacts?
As a formality, I'd like to suspend the vote until this is
resolved, and
then start a new vote on new artifacts, as this issue is very
serious, and
we definitely can't release it like that.
Andrus
P.S. Going to push another trunk snapshot with this fix
P.P.S. Our tags have an extra "cayenne" subfolder that make them
unmergeable
with trunk via git... For M6 we should get rid of that subfolder.
On Dec 7, 2008, at 2:25 PM, Andrus Adamchik wrote:
Couldn't reproduce it with Tore's mapping, but now I started
seeing a
similar behavior in my own production code... Since I can run that
in
debugger, I hope to nail it down now.
Andrus
On Dec 5, 2008, at 4:13 PM, Tore Halset wrote:
On Dec 5, 2008, at 15:03 , Andrus Adamchik wrote:
Hmm... actually looking closer at the stack, this has nothing to
do with
initialization of descriptors. This is some circular object
faulting. Still
a DataMap would help.
Okay and thanks for looking into it. I have sent the mapping to you
outside of the list.
- Tore.
