incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <s9tpep...@apache.org>
Subject Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Date Tue, 13 Mar 2012 00:41:06 GMT
On Mon, Mar 12, 2012 at 5:22 PM, Justin Mclean <justin@classsoftware.com>wrote:

> Hi,
>
> BTW I don't think that in order to be submitted that code must address
> 100% of the list we not want the bar too high. People can apply patch after
> code is submitted to fill in gaps etc. but it still useful to document what
> work may still be required to have a first class component.
>

Yea I agree here. Maybe the naming of the topic doesn't reflect the intent
of the list so well, I think this is a list to check off once you've had
your code submitted or worked on and changed from feedback etc on the
mailing list and you're ready to start the process of seeing if it should
end up in the SDK. The list could help to define what would be the minimum
things that the new component contribution would need to do so it can be
included in the SDK as an official component in a release. I think adding
code to whiteboards/github repos, getting feedback on mailing list etc
should all happen freely on the mailing list. This will get code in early
and if the original author can't invest the time to "finish it off" and get
the final details on then we can queue it up in the JIRA list of things the
community wants included in an SDK, etc.


>
> Perhaps we need to keep a list of donated components and colour code them
> to how "complete" they are and what coudl be done to improve them? Someting
> like http://caniuse.com/#feat=websockets but on the wiki?
>

That's a good idea, maybe we can make a template so whenever we have a new
component that's in the process of being set up to be included in the SDK
we can make a new checklist.


> > One question I do have, what is the criteria to answer your #1?  For
> example
> > Michael pointed out he tried to talk Adobe out of HGroup.
> I have to say I (respectfully) disagree with Michael here. There's is a
> portion of Flex SDK users that were helped by HGroup and VGroup (as they
> were use to the old way of doing things). Not all users of the SDK are
> expert developers. Expert developers can choice to ignore features like
> that if they want to, and other than a small increase to SDK size there's
> no penalty for not using them. I actually find I still use VGroup and
> HGroup even though I know I can use Group, but then I wouldn't be too upset
> if they didn't exist.
>
> Thanks,
> Justin


I agree with you, HGroup and VGroup are helpful for people just migrating
to Flex 4 and they help illustrate proper use of new framework paradigms.
But I wouldn't be opposed at all to moving these kind of composed
convenience classes in their own SWC, I don't think they need to be moved
from their packages as that just creates unnecessary breakages, just would
be nicer to have in a SWC and optionally include them in your project.


-- 
Omar Gonzalez
s9tpepper@apache.org

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