On 11/6/14, 4:06 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:

>Hi,
>
>> Seems like if we drop 3rd-party support, we should remove 3rdparty.xml
>> from the source package and update the RELEASE_NOTES.
>
>-1 to that we would have to revert about a dozen fixes (via cherry
>picking) to remove 3rd party example support for Tour De Flex.

I think removing 3rdparty.xml and updating the RELEASE_NOTES would be
sufficient.

>
>>  To say in the RELEASE_NOTES that there is support and then not support
>>it on the
>> flex.a.o version doesn’t feel right to me.
>
>It does support it we just not showing any 3rd party examples in the
>public Tour De Flex web site. I was trying to make a compromise to get
>the release out the door, but seems fairly clear that is not possible.
>
>>  Or at minimum, mention in RELEASE_NOTES that 3rd-party support isn’t
>>fully implemented.
>
>This sounds like bike shedding to me.

IMO, suggesting the documentation of a known defect in the RELEASE_NOTES
does not turn this discussion into a “bike shed” topic.  I think that’s
one of the things RELEASE_NOTES are for.

>
>> In the “no RC” process we’re practicing, there is no new RC to cut and
>> upload to dist, or VOTE to cancel until this discussion reaches the
>>point
>> where it is pretty clear there are enough PMC votes to ship.
>
>Which currently seem impossible so at this point I think I'm just going
>to give up on releasing it. Sorry to the 15,000 + users who use this and
>the 3rd party contributors who were waiting on the new release.
>
>The whole point of the release process is not to have consensus of the
>entire PMC, but to only have enough people who will vote +1, following
>this new no RC process I can't see how this point can be reached.
>
>Currently we have PMC members who are effectively blocking the release or
>a vote on it but are unwilling to help out in fixing with they see as
>issues. If we have these issues on a simple release like this I can't
>imagine this process working for the installer or the SDK.

We haven’t heard from folks who thought it was a minor issue before my
report on the root cause, so maybe we should confirm their thoughts.
Plus, we now have more options for them to consider.  IMO, the several
options are:

1) Ship the current source without documenting a known defect, which is
that third party content may not position and size correctly, and/or
despite the RELEASE_NOTES mentioning 3rd party support, there won’t be 3rd
party examples on the flex.a.o TDF site.
2) Document the known defect
3) Remove/hide the 3rd party feature and remove its mention from the
RELEASE_NOTES and JIRA.
3) Wait a bit longer and decide on how to properly load 3rd party SWFs
then implement it
4) Change the implementation to link to 3rd party sites instead of loading
their SWFs.

IMO, shipping a known defect without documenting it will cost the
community more time in answering questions about why it isn’t sizing and
positioning correctly, and why there aren’t any 3rd party examples on the
flex.a.o version of TDF than it will to change the RELEASE_NOTES and an
XML file before we vote.  And I don’t see any major hurry to ship TDF 1.2,
so I’m also content to wait and engage the 3rd party contributors and
decide on a proper strategy for loading their content.

-Alex

Reply via email to