On Mon, Mar 12, 2012 at 5:22 PM, Justin Mclean <jus...@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 s9tpep...@apache.org
