Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of omarg.developer@gmail.com
 designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
Sender: omarg.developer@gmail.com
Date: Mon, 12 Mar 2012 16:58:07 -0700
Message-ID: 
 <CAEFz_vujqE1xoBnSZTh_w6cGzLHuLSxnYmf_YLw04AMv+yJ-8Q@mail.gmail.com>
Subject: SDK Inclusion Process (was re: [OT] What are we doing here?)
From: Omar Gonzalez <s9tpepper@apache.org>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d04451a158c527a04bb148313

--f46d04451a158c527a04bb148313
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 12, 2012 at 4:41 PM, Justin Mclean <justin@classsoftware.com>wrote:

> Hi,
>
> > We probably need a list of requirements, such as does it have ASDoc,
> comments, unit tests, Mustella
> > tests, etc.
>
> Here's a list I've been working on - it still needs more work.
>
> 1. Does the submitted code fill a need for users of the SDK?
> Could the code better exist as an optional component? Ask yourself does it
> need to be part of the SDK at all?
>
> 2. Can the code be legally donated?
> Any there any IP issues with the code? eg If it was contributed by a full
> time employee do you have permission to donation the code?
> Has the contributor signed a CLR?
>
> 3. Is it backward compatible with the existing SDK.
> If not what are the reasons and is there a clear well documented migration
> path?
>
> 4. Has the code been reviewed?
> Is the code at least the same quality as existing code in the SDK?
> Has feedback been provided on the mailing list?
> Have any outstanding concerns or issues been resolved?
> Has a consensus been reached?
> Any outstanding structural or architectural issues? Have these been
> documented?
>
> 5. Are there any performance issues with the code?
> Is performance measurably better or worse?
>
> 6. Is the code formatted according to the Flex SDK code style?
> Do all files have the Apache header?
>
> 7. Are all of the properties and methods documented in same way as methods
> and properties in the Flex SDK?
> Can ASdocs be generated from the code?
>
> 6. Can the classes be easily extended if needed?
>
> 5. Does the code work on desktop, browser and mobile?
>
> 8. Are there working examples showing how the code can be used?
>
> 9. Is the code fully unit tested and can those tests be easily run?
>
> 10. Have all locale and globalisation issues been addressed?
> Has the code been localised to the standard set of Flex SDK locales?
>
> 12. Do the class names and name spaces fit in with the he existing SDK?
> Should the code use an existing package name or a new package name?
> What framework project should the code be added to?
>
> 13. Have the manifest and build scrips been updated?
>
> Probably need something added about accessibility, events, styles and
> skins to the above.
>
> What do we put for Flash player and Flex version  numbers in method
> headers? Do with go with 10.2 and Apache Flex 4.8 or something else?
>
> Thanks,
> Justin
>
>
I think this is a really good start to creating a sort of checklist in
order to get a new SDK component included in a release.

Would this be tracked best using JIRA so the contributor can submit the
details about a donation? I think what would be good to is if we could come
up with some links to info we put in the wiki for each of the questions we
include in the checklist that gives information about getting that step
accomplished.

I think Alex and Carol's feedback on this checklist would be greatly
appreciated as well given their experience with the SDK.

One question I do have, what is the criteria to answer your #1? Recently we
had a lot of discussion around the framework and whether something like
s:TileList or s:HorizontalList belong in the SDK. I'm not sure that really
came to any kind of consensus, just a lot of good points on the size and
flexibility of the framework and keeping it to a minimum. For example
Michael pointed out he tried to talk Adobe out of HGroup. There was a
suggestion that seemed to get some positive feedback about creating some
sort of optional part of the library that's compiled into a separate SWC
that's not part of the core of the framework. I like that idea, but I think
it all ties into how do we determine the answer for #1?


Thanks,

-- 
Omar Gonzalez
s9tpepper@apache.org

--f46d04451a158c527a04bb148313--