You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Omar Gonzalez <s9...@apache.org> on 2012/03/13 00:58:07 UTC
SDK Inclusion Process (was re: [OT] What are we doing here?)
On Mon, Mar 12, 2012 at 4:41 PM, Justin Mclean <ju...@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
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> My only concern with that will be refactoring.
Most IDEs have tools that help with that.
> Why not org.apache.component.branch.wherethisbelongs?
I'm not against that either. org.apache.flex.xxxx or is it apache.flex.xxxx?
Thanks,
Justin
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by JP Bader <jp...@zavteq.com>.
My only concern with that will be refactoring. Not that we're looking at a
huge component set being added right now, but still...
Why not org.apache.component.branch.wherethisbelongs?
JP
On Mar 12, 2012 8:31 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> > Looks great, Justin. My only feedback would be (and its purely cosmetic)
> > that #1 become the last step in the list.
> Yep it should be moved down the list.
>
> > I think there is value in having it somewhere in the source tree.
> Perhaps a silly idea but what about using package names for a tiered
> approach. eg all new components go into org.apache.flex.experimental (or
> org.apache.flex.alpha) then (if good enough) progress to
> org.apache.flex.beta or something similar then into the framework?
>
> I guess once we have nightly builds and regular releases it may not be
> needed?
>
> Justin
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Looks great, Justin. My only feedback would be (and its purely cosmetic)
> that #1 become the last step in the list.
Yep it should be moved down the list.
> I think there is value in having it somewhere in the source tree.
Perhaps a silly idea but what about using package names for a tiered approach. eg all new components go into org.apache.flex.experimental (or org.apache.flex.alpha) then (if good enough) progress to org.apache.flex.beta or something similar then into the framework?
I guess once we have nightly builds and regular releases it may not be needed?
Justin
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Daniel Reicher <da...@gmail.com>.
>
>
> 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?
>
>
Looks great, Justin. My only feedback would be (and its purely cosmetic)
that #1 become the last step in the list. Whether a component gets put in
the "holy" component project, a "bonus" components project or some ala
carte component area - if it meets the other criteria and someone is
committed to maintaining it, I think there is value in having it somewhere
in the source tree. If the tiered approach is taken, I would also say they
should try and use the same package structure.
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Omar Gonzalez <s9...@apache.org>.
On Mon, Mar 12, 2012 at 5:22 PM, Justin Mclean <ju...@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
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Justin Mclean <ju...@classsoftware.com>.
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.
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?
> Would this be tracked best using JIRA so the contributor can submit the
> details about a donation?
Great idea. I had not filled out a JIRA enhancement to add the PostCodeValidator to the SDK and probably should do so.
> 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
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Carol Frampton <cf...@adobe.com>.
Alex has said this before but I'll remind people. I think he/we are
proposing that there be 2 or 3 branches with the final branch being trunk.
Trunk becomes the next release of the SDK. So, for example, code could
move from the whiteboard or, or some external source, to the "not quite
polished" branch, for lack of a better name, which would give people a
chance to use it, test it, refine it, etc, and then when it was deemed
"ready" it could be pushed/merged to trunk which would make it part of the
next release.
I think I remember hearing there are several Apache projects that have
this model.
Carol
On 3/13/12 1 :54PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
>On 3/13/12 10:42 AM, "Omar Gonzalez" <s9...@apache.org> wrote:
>
>> There's an awful lot of process described in your response. This is
>>exactly
>> what I'm saying we need to come to an agreement on, finalize a decision
>>and
>> publish this process on the wiki.
>Yes, there is a sequence, but I think it is the same short set of steps in
>iteration. And, I didn't make this up, I believe other Apache projects
>work
>this way.
>
>What is hard is trying to remember however many steps that will eventually
>be on that checklist. What is slow is trying to use that long checklist
>to
>validate promotion or acceptance of a change.
>
>I want this to be simple: Use your own good judgment before promoting
>code
>to the next branch with the higher quality bar. The onus is on you to get
>enough eyes on your stuff before promoting it. That's what the mailing
>list
>and JIRA are for. Within a branch or whiteboard, any commit is good as
>long
>as it is an incremental improvement and doesn't appear to break anything.
>
>I think I can remember that.
>
>--
>Alex Harui
>Flex SDK Team
>Adobe Systems, Inc.
>http://blogs.adobe.com/aharui
>
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Alex Harui <ah...@adobe.com>.
On 3/13/12 10:42 AM, "Omar Gonzalez" <s9...@apache.org> wrote:
> There's an awful lot of process described in your response. This is exactly
> what I'm saying we need to come to an agreement on, finalize a decision and
> publish this process on the wiki.
Yes, there is a sequence, but I think it is the same short set of steps in
iteration. And, I didn't make this up, I believe other Apache projects work
this way.
What is hard is trying to remember however many steps that will eventually
be on that checklist. What is slow is trying to use that long checklist to
validate promotion or acceptance of a change.
I want this to be simple: Use your own good judgment before promoting code
to the next branch with the higher quality bar. The onus is on you to get
enough eyes on your stuff before promoting it. That's what the mailing list
and JIRA are for. Within a branch or whiteboard, any commit is good as long
as it is an incremental improvement and doesn't appear to break anything.
I think I can remember that.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Omar Gonzalez <s9...@apache.org>.
On Tue, Mar 13, 2012 at 10:37 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/13/12 10:12 AM, "Omar Gonzalez" <s9...@apache.org> wrote:
>
>
> >
> > As an example, Tink has his layouts and containers in whiteboard. What
> now?
> As the unit test thread is saying, we're a bit stuck right now. What
> should
> be happening is that Tink and others write some tests to validate that it
> works and folks who actually try it and like it tell him so, report bugs,
> provide patches, make suggestions, etc.
>
> That would then give him the confidence to commit to an interim branch
> which
> would hopefully cause more folks to look at it. After a few more eyes are
> on it, he would feel confident enough to try to commit to trunk.
>
> IMHO, other than the tests, the rest of it can happen now and it could end
> up in the patches branch if we will be using that as the interim branch.
>
> > We have no process to take his contributions and get them in the SDK.
> > Defining a process does not necessarily mean that Tink HAS to perform all
> > those tasks... but _someone_ should, either other committers or the
> > community so that we can put that 'official stamp' on them.
> To me, with commit-then-review, each commit is official by default. They
> can go in unfinished and get improved with a series of actions by the
> community and once someone feels like there is no reason to veto it, it
> moves to the next branch and eventually gets released.
> >
> > Is this a bad thing? Or are we proposing that people just put in any code
> > in any state into the SDK so long as the community votes it in (or some
> > other procedure)?
> I am proposing that folks put code in any state into their whiteboard. The
> community does not vote it in, it can only vote it out, which should almost
> never happen for whiteboard commits. I'll be paying slightly more
> attention
> to commits to an interim branch, and more attention to commits to the
> trunk,
> but I am going to trust that the community has vetted it more and more at
> each level, and hopefully, mustella will prevent regressions.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
There's an awful lot of process described in your response. This is exactly
what I'm saying we need to come to an agreement on, finalize a decision and
publish this process on the wiki.
--
Omar Gonzalez
s9tpepper@apache.org
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Alex Harui <ah...@adobe.com>.
On 3/13/12 10:12 AM, "Omar Gonzalez" <s9...@apache.org> wrote:
>
> As an example, Tink has his layouts and containers in whiteboard. What now?
As the unit test thread is saying, we're a bit stuck right now. What should
be happening is that Tink and others write some tests to validate that it
works and folks who actually try it and like it tell him so, report bugs,
provide patches, make suggestions, etc.
That would then give him the confidence to commit to an interim branch which
would hopefully cause more folks to look at it. After a few more eyes are
on it, he would feel confident enough to try to commit to trunk.
IMHO, other than the tests, the rest of it can happen now and it could end
up in the patches branch if we will be using that as the interim branch.
> We have no process to take his contributions and get them in the SDK.
> Defining a process does not necessarily mean that Tink HAS to perform all
> those tasks... but _someone_ should, either other committers or the
> community so that we can put that 'official stamp' on them.
To me, with commit-then-review, each commit is official by default. They
can go in unfinished and get improved with a series of actions by the
community and once someone feels like there is no reason to veto it, it
moves to the next branch and eventually gets released.
>
> Is this a bad thing? Or are we proposing that people just put in any code
> in any state into the SDK so long as the community votes it in (or some
> other procedure)?
I am proposing that folks put code in any state into their whiteboard. The
community does not vote it in, it can only vote it out, which should almost
never happen for whiteboard commits. I'll be paying slightly more attention
to commits to an interim branch, and more attention to commits to the trunk,
but I am going to trust that the community has vetted it more and more at
each level, and hopefully, mustella will prevent regressions.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Omar Gonzalez <s9...@apache.org>.
On Tue, Mar 13, 2012 at 10:04 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/13/12 12:24 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> > Hi,
> >
> >> I may change my mind about this in the morning, but this is just too
> much
> >> process.
> > I see it as more of a list of what you may need to think about/get other
> > people to help you out along the way with rather than a step by step
> process.
> > Perhaps I should of left off the numbers? I certainly don't think that a
> > contribution would need to address all of those concerns initially but it
> > would be not to nice to say to the list "I've not considered any
> localisation
> > issues with this contribution can someone take a look at that for me" or
> "I've
> > no idea if this works well n Android/iOS".
> I don't agree. If you don't have an IOS device, that shouldn't be a
> blocker. If you don't have a Mac, that shouldn't matter either. That is
> the
> advantage of community. Folks help each other by contributing their
> expertise.
> Yes, most of us have the experience to at least think a little about
> localization, but I can guarantee I don't know as much about it as some of
> you. The next time I contribute a brand new component, I expect there to
> be
> issues with localization, accessibility, the names of the APIs, and there
> will be bugs in it. But at least there will be code to look at and
> improve.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
I don't think Justin is saying it should be a blocker. I believe what is
being proposed is that it be used as a list to evaluate things that need to
be done to contributions. For example, let's say you write up some
component, and like you said you didn't really consider localization
because either you don't care or you don't know enough about localization
to add that in. The list would be used POST-contribution to get the
component through the last things needed, _with_ the help of the community
and other contributors, to get the component in a state where the community
will vote it in as part of an SDK release (or however we end up doing that
process).
I don't think the checklist being proposed is a list specifically for the
contributing developer, but more of a guide as to what we should address
before taking someone's contribution and making it an official part of the
SDK.
As an example, Tink has his layouts and containers in whiteboard. What now?
We have no process to take his contributions and get them in the SDK.
Defining a process does not necessarily mean that Tink HAS to perform all
those tasks... but _someone_ should, either other committers or the
community so that we can put that 'official stamp' on them.
Is this a bad thing? Or are we proposing that people just put in any code
in any state into the SDK so long as the community votes it in (or some
other procedure)?
--
Omar Gonzalez
s9tpepper@apache.org
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Carol Frampton <cf...@adobe.com>.
On 3/13/12 3 :24AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>We could actually use apache.flex (or org.apache.flex) as the intern
>package in the patches branch?
Based on mail I got from Bertrand about a question I asked about code
donation I think he would say org.apache.flex
Carol
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I don't agree. If you don't have an IOS device, that shouldn't be a
> blocker. If you don't have a Mac, that shouldn't matter either. That is the
> advantage of community. Folks help each other by contributing their
> expertise.
Perhaps I wasn't clean that exactly what I was saying. I agree 100%.
When submitting something just would be nice to point what it is missing.
Justin
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Alex Harui <ah...@adobe.com>.
On 3/13/12 12:24 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I may change my mind about this in the morning, but this is just too much
>> process.
> I see it as more of a list of what you may need to think about/get other
> people to help you out along the way with rather than a step by step process.
> Perhaps I should of left off the numbers? I certainly don't think that a
> contribution would need to address all of those concerns initially but it
> would be not to nice to say to the list "I've not considered any localisation
> issues with this contribution can someone take a look at that for me" or "I've
> no idea if this works well n Android/iOS".
I don't agree. If you don't have an IOS device, that shouldn't be a
blocker. If you don't have a Mac, that shouldn't matter either. That is the
advantage of community. Folks help each other by contributing their
expertise.
Yes, most of us have the experience to at least think a little about
localization, but I can guarantee I don't know as much about it as some of
you. The next time I contribute a brand new component, I expect there to be
issues with localization, accessibility, the names of the APIs, and there
will be bugs in it. But at least there will be code to look at and improve.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I may change my mind about this in the morning, but this is just too much
> process.
I see it as more of a list of what you may need to think about/get other people to help you out along the way with rather than a step by step process. Perhaps I should of left off the numbers? I certainly don't think that a contribution would need to address all of those concerns initially but it would be not to nice to say to the list "I've not considered any localisation issues with this contribution can someone take a look at that for me" or "I've no idea if this works well n Android/iOS".
Currently when something is checked into the trunk (or rather the patches branch) it's going to have little or no effect - we don't have any nightly builds for instance so all we are doing at worse is breaking a potential future build or someone's custom build.
Any bit of code committed can just as easily be reverted. We've all been a bit commit shy (including me). Putting up stuff that is working but needs a little polish may actually give people something to do.
> My only criteria before it goes in a release is that you tried to prove that
> it doesn't break anything.
Sounds fine by me.
> And that's why I liked the staged branching plan where stuff goes from
> whiteboard to something in-between before going to trunk/release.
I'm liking this idea more.
We could actually use apache.flex (or org.apache.flex) as the intern package in the patches branch?
Justin
Re: SDK Inclusion Process (was re: [OT] What are we doing here?)
Posted by Alex Harui <ah...@adobe.com>.
On 3/12/12 4:58 PM, "Omar Gonzalez" <s9...@apache.org> wrote:
>
> I think Alex and Carol's feedback on this checklist would be greatly
> appreciated as well given their experience with the SDK.
I may change my mind about this in the morning, but this is just too much
process. Apache allows folks to veto commits, so one item off a checklist
like this is nice to use as your reason to veto something if you happen to
notice it, but to require a human to run this gauntlet or other humans to
enforce this gauntlet feels like too much.
I think we had too much process at Adobe as well.
My only criteria before it goes in a release is that you tried to prove that
it doesn't break anything. Hopefully we will have an infrastructure to help
you prove that.
And that's why I liked the staged branching plan where stuff goes from
whiteboard to something in-between before going to trunk/release.
Check stuff into your whiteboard in any state, when you feel better about
it, try to get it committed to the interim branch, let folks pound on it,
try to get it committed to trunk. No proposal emails unless you want to
discuss something that will take a long time to do.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui