Re: testing M5 - StackOverflowError during context.deleteObject()

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Mon Dec 08 2008 - 01:07:31 EST

  • Next message: Andrus Adamchik: "Re: testing M5 - StackOverflowError during context.deleteObject()"

    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 <andru..bjectstyle.org
    > > 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.
    >>>>
    >>>>
    >>>
    >>>
    >>
    >>
    >



    This archive was generated by hypermail 2.0.0 : Mon Dec 08 2008 - 01:08:12 EST