incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Reicher <danreic...@gmail.com>
Subject Commit process for new component (non-committer)
Date Wed, 07 Mar 2012 22:47:31 GMT
Maybe I'm just thick but I'm trying to understand the process for trying to
add a component to the SDK. There seems to be a lot of discussion with
multiple paths. Perhaps I'm one of those "learn by doing" types. So, in the
interest of trying to figure out the best way to navigate this process as a
non-committer (you folks can just drop it in a whiteboard and go about your
day) what is the process? In an effort to figure it out, I took an
afternoon and created a component along with web and mobile skins for it. I
stuck with current SDK conventions as much as possible.

So, I've got this shiny new component (a "toast" notification or something
similar to a growl for you apple folk). Its a first class component in the
Android SDK and while it can certainly be composited in Flex, there is IMO
sufficient benefit in componentizing it. So, code in hand (or .zip as it
were) here are my questions:

1. Where does the code go? In different discussions, there has been talk of
attaching it to a message in the list, put it on a jira and some ethereal
"commit" area of the repository (which I couldn't do anyway) for proposed
inclusion.

2. What level of discussion should be taking place? Do I kick off a new
thread on the list? Is it labeled [PROPOSAL] or something else - or nothing
at all?

3. There are questions that need to be dealt with about the component
itself: does this belong in the SDK, is the code good enough to warrant
inclusion, should this be a mobile-only component, etc.?

4. What to do about "other" files that need to be updated in the SDK? The
...Classes.as files, manifest files, default.css files in the themes, etc.
all need to be dealt with at some point, but the current process for
setting up the SDK in FB leaves a lot to be desired (again, could be my
thickness). Also, creating a patch with changes in the SDK seems
presumptuous at this stage.

5. Are things like this really going to be held out of the SDK until 5.0 (
https://cwiki.apache.org/confluence/display/FLEX/Decisions+so+far)? Without
concrete timelines from Adobe on their work for 4.7/4.8 is gating on that
really the best strategy to keep momentum in the Flex community.

Any guidance is appreciated and hopefully this will make it more
straightforward for people in the future.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message