Committer duties and information

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Committer duties and information

Michael Schmalle
Hi All,

I was just curious if there was any Apache Flex specific information  
floating around about how duties might be divided on each others  
strength in relation to our understanding of the SDK.

I know there is the official committer information page that Alex  
provided but has there been any discussion on how an initial committer  
can prepare for whats to be expected in the Apache Flex project?

Or is this just to soon to ask this question?

Thanks,
Mike


Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Jeffry Houser

  Be sure to watch the "What it Means to be an Apache Project" from the
Flex Summit, here:

http://tv.adobe.com/show/flex-community-summit-december-2011/

   My understanding is that we do whatever we want.  I don't know how
that goes from "chaos" to "release" yet, though.

On 1/4/2012 2:12 PM, Michael Schmalle wrote:

> Hi All,
>
> I was just curious if there was any Apache Flex specific information
> floating around about how duties might be divided on each others
> strength in relation to our understanding of the SDK.
>
> I know there is the official committer information page that Alex
> provided but has there been any discussion on how an initial committer
> can prepare for whats to be expected in the Apache Flex project?
>
> Or is this just to soon to ask this question?
>
> Thanks,
> Mike
>
>


--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust


Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Peter Elst
Thats a good point I've not been clear on either - is roadmap discussed on
the mailinglist and voted on so there's a bit of structure to what type of
things get worked on rather than a random collection of bug fixes and
non-related features?

- Peter


On Wed, Jan 4, 2012 at 7:17 PM, Jeffry Houser <[hidden email]> wrote:

>
>  Be sure to watch the "What it Means to be an Apache Project" from the
> Flex Summit, here:
>
> http://tv.adobe.com/show/flex-**community-summit-december-**2011/<http://tv.adobe.com/show/flex-community-summit-december-2011/>
>
>  My understanding is that we do whatever we want.  I don't know how that
> goes from "chaos" to "release" yet, though.
>
>
> On 1/4/2012 2:12 PM, Michael Schmalle wrote:
>
>> Hi All,
>>
>> I was just curious if there was any Apache Flex specific information
>> floating around about how duties might be divided on each others strength
>> in relation to our understanding of the SDK.
>>
>> I know there is the official committer information page that Alex
>> provided but has there been any discussion on how an initial committer can
>> prepare for whats to be expected in the Apache Flex project?
>>
>> Or is this just to soon to ask this question?
>>
>> Thanks,
>> Mike
>>
>>
>>
>
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Arthur Lockman
I agree with Peter. There needs to be some kind of structure so we
don't en up with some kind of mishmash of features that dont work
together.
-Arthur

---
Arthur Lockman
a.rthr.me
@arthurlockman
Sent from my iPhone

On Jan 4, 2012, at 2:59 PM, Peter Elst <[hidden email]> wrote:

> Thats a good point I've not been clear on either - is roadmap discussed on
> the mailinglist and voted on so there's a bit of structure to what type of
> things get worked on rather than a random collection of bug fixes and
> non-related features?
>
> - Peter
>
>
> On Wed, Jan 4, 2012 at 7:17 PM, Jeffry Houser <[hidden email]> wrote:
>
>>
>> Be sure to watch the "What it Means to be an Apache Project" from the
>> Flex Summit, here:
>>
>> http://tv.adobe.com/show/flex-**community-summit-december-**2011/<http://tv.adobe.com/show/flex-community-summit-december-2011/>
>>
>> My understanding is that we do whatever we want.  I don't know how that
>> goes from "chaos" to "release" yet, though.
>>
>>
>> On 1/4/2012 2:12 PM, Michael Schmalle wrote:
>>
>>> Hi All,
>>>
>>> I was just curious if there was any Apache Flex specific information
>>> floating around about how duties might be divided on each others strength
>>> in relation to our understanding of the SDK.
>>>
>>> I know there is the official committer information page that Alex
>>> provided but has there been any discussion on how an initial committer can
>>> prepare for whats to be expected in the Apache Flex project?
>>>
>>> Or is this just to soon to ask this question?
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>>
>>
>> --
>> Jeffry Houser
>> Technical Entrepreneur
>> 203-379-0773
>> --
>> http://www.flextras.com?c=104
>> UI Flex Components: Tested! Supported! Ready!
>> --
>> http://www.theflexshow.com
>> http://www.jeffryhouser.com
>> http://www.asktheflexpert.com
>> --
>> Part of the DotComIt Brain Trust
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Jonathan Campos
In reply to this post by Peter Elst
That is an exact question that I asked at the Flex Summit specifically for
the group.

Roy Fielding had a great analogy/answer.
The main idea is that this is that we are throwing a party, not running a
business with free labor. So people need to be energized about what they
are doing, they aren't there to be given tasks.

As such there is no roadmap. You may come up with a great idea and start
working on it, then when other people see what you are doing they may join.
Over time your idea snowballs and gets added in, but this doesn't mean that
there is a formal roadmap for people to sit at and program away against.

However this is where Spoon comes in. We do have plans and roadmaps of
features we want to add. Some take time and require people. If you are
interested in our roadmap (our party) you and anyone else is free to join.

Make sense?

J

On Wed, Jan 4, 2012 at 1:58 PM, Peter Elst <[hidden email]> wrote:

> Thats a good point I've not been clear on either - is roadmap discussed on
> the mailinglist and voted on so there's a bit of structure to what type of
> things get worked on rather than a random collection of bug fixes and
> non-related features?
>
> - Peter
>
>
> On Wed, Jan 4, 2012 at 7:17 PM, Jeffry Houser <[hidden email]>
> wrote:
>
> >
> >  Be sure to watch the "What it Means to be an Apache Project" from the
> > Flex Summit, here:
> >
> > http://tv.adobe.com/show/flex-**community-summit-december-**2011/<
> http://tv.adobe.com/show/flex-community-summit-december-2011/>
> >
> >  My understanding is that we do whatever we want.  I don't know how that
> > goes from "chaos" to "release" yet, though.
> >
> >
> > On 1/4/2012 2:12 PM, Michael Schmalle wrote:
> >
> >> Hi All,
> >>
> >> I was just curious if there was any Apache Flex specific information
> >> floating around about how duties might be divided on each others
> strength
> >> in relation to our understanding of the SDK.
> >>
> >> I know there is the official committer information page that Alex
> >> provided but has there been any discussion on how an initial committer
> can
> >> prepare for whats to be expected in the Apache Flex project?
> >>
> >> Or is this just to soon to ask this question?
> >>
> >> Thanks,
> >> Mike
> >>
> >>
> >>
> >
> > --
> > Jeffry Houser
> > Technical Entrepreneur
> > 203-379-0773
> > --
> > http://www.flextras.com?c=104
> > UI Flex Components: Tested! Supported! Ready!
> > --
> > http://www.theflexshow.com
> > http://www.jeffryhouser.com
> > http://www.asktheflexpert.com
> > --
> > Part of the DotComIt Brain Trust
> >
> >
>



--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Alex Harui
In reply to this post by Peter Elst
I'm not sure this made the video from the summit, but Roy Fielding gave me
the impression that there are no "roadmaps" in Apache.  You work on what you
want to work on and commit it.  If people don't like it, you get voted down
and you have to pull it and adjust it until people like it.  If I were you,
before I embarked on a significant amount of code, I would start a
discussion on the mailing list first to make sure there won't be a major
unexpected issue when you try to check in, and to see if anyone else wants
to join in.

I've been flip-flopping between requesting a "review-then-commit" workflow
vs the default "commit-then-review".  Past experience has shown that there
are lots of things to consider when modifying the Flex framework that many
folks don't consider (Marshall Plan, can't assume stage access, for
example).

Because it looks like we won't get JIRA up any time soon, we might start out
with commit-then-review and I'll just have to try to keep up with reviewing
all of the commits.

And because it looks like it will be a while before we get the test suite
running, I would like to discourage commits of anything significant until we
have a way to verify your changes are safe.


On 1/4/12 11:58 AM, "[hidden email]" <[hidden email]> wrote:

> Thats a good point I've not been clear on either - is roadmap discussed on
> the mailinglist and voted on so there's a bit of structure to what type of
> things get worked on rather than a random collection of bug fixes and
> non-related features?
>
> - Peter
>
>
> On Wed, Jan 4, 2012 at 7:17 PM, Jeffry Houser <[hidden email]> wrote:
>
>>
>>  Be sure to watch the "What it Means to be an Apache Project" from the
>> Flex Summit, here:
>>
>> http://tv.adobe.com/show/flex-**community-summit-december-**2011/<http://tv.a
>> dobe.com/show/flex-community-summit-december-2011/>
>>
>>  My understanding is that we do whatever we want.  I don't know how that
>> goes from "chaos" to "release" yet, though.
>>
>>
>> On 1/4/2012 2:12 PM, Michael Schmalle wrote:
>>
>>> Hi All,
>>>
>>> I was just curious if there was any Apache Flex specific information
>>> floating around about how duties might be divided on each others strength
>>> in relation to our understanding of the SDK.
>>>
>>> I know there is the official committer information page that Alex
>>> provided but has there been any discussion on how an initial committer can
>>> prepare for whats to be expected in the Apache Flex project?
>>>
>>> Or is this just to soon to ask this question?
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>>
>>
>> --
>> Jeffry Houser
>> Technical Entrepreneur
>> 203-379-0773
>> --
>> http://www.flextras.com?c=104
>> UI Flex Components: Tested! Supported! Ready!
>> --
>> http://www.theflexshow.com
>> http://www.jeffryhouser.com
>> http://www.asktheflexpert.com
>> --
>> Part of the DotComIt Brain Trust
>>
>>

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Greg Reddin
In reply to this post by Peter Elst
On Wed, Jan 4, 2012 at 1:58 PM, Peter Elst <[hidden email]> wrote:
> is roadmap discussed on
> the mailinglist and voted on so there's a bit of structure to what type of
> things get worked on rather than a random collection of bug fixes and
> non-related features?

There's a couple of principles about working on Apache projects that
are at play here, in my opinion. Of course each project has its own
personality and its own ways of doing things, but these are common
enough to almost be "laws" of the Apache Way:

 * If it doesn't happen on list it doesn't happen. This doesn't mean
we need to vote on everything, but it does mean that ideas, roadmaps,
etc. should be discussed on list. That's why I encouraged the ones who
are interested in site work to do that communication on list. That way
everybody can see it and anybody can participate if they want. It
would be bad if someone checked in a large patch he had been
discussing privately with two other committers on a forum or IRC
without first bringing that discussion to the list. In some senses the
list *is* the community. At least it's the official record of it.

 * Everyone should scratch his/her own itch. No one has authority to
dictate what anyone else works on. Of course we all come together as a
community to get a release out so pragmatism will sometimes dictate
what someone works on. But anyone is generally free to work in
whatever part of the code he/she wishes. I think some projects divide
their subversion repo into different subprojects and commiters stick
to the areas they are experienced with. But I don't think any Apache
project would dictate that certain committers are only allowed to work
in certain areas.

So... to apply that directly to your question: yes, a roadmap should
definitely be discussed on list, but it doesn't necessarily need to be
voted on. But it's possible that a release might include what seems
like "a random collection of bug fixes and non-related features." In
fact that situation might be healthy because it means there are a lot
of different, diverse people working on different areas of the code
simultaneously and they all work together to produce a unified
release.

Sorry if I'm rambling.
Greg

Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Fréderic Cox
In reply to this post by Jonathan Campos
This makes sense to me if we can also vote on the features of Spoon to
influence priority

On 04/01/12 21:08, "Jonathan Campos" <[hidden email]> wrote:

>That is an exact question that I asked at the Flex Summit specifically for
>the group.
>
>Roy Fielding had a great analogy/answer.
>The main idea is that this is that we are throwing a party, not running a
>business with free labor. So people need to be energized about what they
>are doing, they aren't there to be given tasks.
>
>As such there is no roadmap. You may come up with a great idea and start
>working on it, then when other people see what you are doing they may
>join.
>Over time your idea snowballs and gets added in, but this doesn't mean
>that
>there is a formal roadmap for people to sit at and program away against.
>
>However this is where Spoon comes in. We do have plans and roadmaps of
>features we want to add. Some take time and require people. If you are
>interested in our roadmap (our party) you and anyone else is free to join.
>
>Make sense?
>
>J
>
>On Wed, Jan 4, 2012 at 1:58 PM, Peter Elst <[hidden email]> wrote:
>
>> Thats a good point I've not been clear on either - is roadmap discussed
>>on
>> the mailinglist and voted on so there's a bit of structure to what type
>>of
>> things get worked on rather than a random collection of bug fixes and
>> non-related features?
>>
>> - Peter
>>
>>
>> On Wed, Jan 4, 2012 at 7:17 PM, Jeffry Houser <[hidden email]>
>> wrote:
>>
>> >
>> >  Be sure to watch the "What it Means to be an Apache Project" from the
>> > Flex Summit, here:
>> >
>> > http://tv.adobe.com/show/flex-**community-summit-december-**2011/<
>> http://tv.adobe.com/show/flex-community-summit-december-2011/>
>> >
>> >  My understanding is that we do whatever we want.  I don't know how
>>that
>> > goes from "chaos" to "release" yet, though.
>> >
>> >
>> > On 1/4/2012 2:12 PM, Michael Schmalle wrote:
>> >
>> >> Hi All,
>> >>
>> >> I was just curious if there was any Apache Flex specific information
>> >> floating around about how duties might be divided on each others
>> strength
>> >> in relation to our understanding of the SDK.
>> >>
>> >> I know there is the official committer information page that Alex
>> >> provided but has there been any discussion on how an initial
>>committer
>> can
>> >> prepare for whats to be expected in the Apache Flex project?
>> >>
>> >> Or is this just to soon to ask this question?
>> >>
>> >> Thanks,
>> >> Mike
>> >>
>> >>
>> >>
>> >
>> > --
>> > Jeffry Houser
>> > Technical Entrepreneur
>> > 203-379-0773
>> > --
>> > http://www.flextras.com?c=104
>> > UI Flex Components: Tested! Supported! Ready!
>> > --
>> > http://www.theflexshow.com
>> > http://www.jeffryhouser.com
>> > http://www.asktheflexpert.com
>> > --
>> > Part of the DotComIt Brain Trust
>> >
>> >
>>
>
>
>
>--
>Jonathan Campos
>Dallas Flex User Group Manager
>http://www.d-flex.org/
>blog: http://www.unitedmindset.com/jonbcampos
>twitter: http://www.twitter.com/jonbcampos


Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Jonathan Campos
While Spoon has some initial committers in the mix, every commit is still
bound by the rules of Apache and getting voted out. Obviously everything we
do is in the open right in an Apache workspace off of the Apache Flex
project.

We do have specific big BIG goals that we want to include in the framework.
We are prepping an open meeting to discuss some of these initiatives that
we plan to tackle. If you like them, join in. If you have no interest and
want to focus on another section, more power to you.

J

On Wed, Jan 4, 2012 at 2:17 PM, Fréderic Cox <[hidden email]> wrote:

> This makes sense to me if we can also vote on the features of Spoon to
> influence priority
>
> On 04/01/12 21:08, "Jonathan Campos" <[hidden email]> wrote:
>
> >That is an exact question that I asked at the Flex Summit specifically for
> >the group.
> >
> >Roy Fielding had a great analogy/answer.
> >The main idea is that this is that we are throwing a party, not running a
> >business with free labor. So people need to be energized about what they
> >are doing, they aren't there to be given tasks.
> >
> >As such there is no roadmap. You may come up with a great idea and start
> >working on it, then when other people see what you are doing they may
> >join.
> >Over time your idea snowballs and gets added in, but this doesn't mean
> >that
> >there is a formal roadmap for people to sit at and program away against.
> >
> >However this is where Spoon comes in. We do have plans and roadmaps of
> >features we want to add. Some take time and require people. If you are
> >interested in our roadmap (our party) you and anyone else is free to join.
> >
> >Make sense?
> >
> >J
> >
> >On Wed, Jan 4, 2012 at 1:58 PM, Peter Elst <[hidden email]> wrote:
> >
> >> Thats a good point I've not been clear on either - is roadmap discussed
> >>on
> >> the mailinglist and voted on so there's a bit of structure to what type
> >>of
> >> things get worked on rather than a random collection of bug fixes and
> >> non-related features?
> >>
> >> - Peter
> >>
> >>
> >> On Wed, Jan 4, 2012 at 7:17 PM, Jeffry Houser <[hidden email]>
> >> wrote:
> >>
> >> >
> >> >  Be sure to watch the "What it Means to be an Apache Project" from the
> >> > Flex Summit, here:
> >> >
> >> > http://tv.adobe.com/show/flex-**community-summit-december-**2011/<
> >> http://tv.adobe.com/show/flex-community-summit-december-2011/>
> >> >
> >> >  My understanding is that we do whatever we want.  I don't know how
> >>that
> >> > goes from "chaos" to "release" yet, though.
> >> >
> >> >
> >> > On 1/4/2012 2:12 PM, Michael Schmalle wrote:
> >> >
> >> >> Hi All,
> >> >>
> >> >> I was just curious if there was any Apache Flex specific information
> >> >> floating around about how duties might be divided on each others
> >> strength
> >> >> in relation to our understanding of the SDK.
> >> >>
> >> >> I know there is the official committer information page that Alex
> >> >> provided but has there been any discussion on how an initial
> >>committer
> >> can
> >> >> prepare for whats to be expected in the Apache Flex project?
> >> >>
> >> >> Or is this just to soon to ask this question?
> >> >>
> >> >> Thanks,
> >> >> Mike
> >> >>
> >> >>
> >> >>
> >> >
> >> > --
> >> > Jeffry Houser
> >> > Technical Entrepreneur
> >> > 203-379-0773
> >> > --
> >> > http://www.flextras.com?c=104
> >> > UI Flex Components: Tested! Supported! Ready!
> >> > --
> >> > http://www.theflexshow.com
> >> > http://www.jeffryhouser.com
> >> > http://www.asktheflexpert.com
> >> > --
> >> > Part of the DotComIt Brain Trust
> >> >
> >> >
> >>
> >
> >
> >
> >--
> >Jonathan Campos
> >Dallas Flex User Group Manager
> >http://www.d-flex.org/
> >blog: http://www.unitedmindset.com/jonbcampos
> >twitter: http://www.twitter.com/jonbcampos
>
>


--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Michael Schmalle
In reply to this post by Jonathan Campos
Quoting Jonathan Campos <[hidden email]>:

> That is an exact question that I asked at the Flex Summit specifically for
> the group.
>
> Roy Fielding had a great analogy/answer.
> The main idea is that this is that we are throwing a party, not running a
> business with free labor. So people need to be energized about what they
> are doing, they aren't there to be given tasks.
>
> As such there is no roadmap. You may come up with a great idea and start
> working on it, then when other people see what you are doing they may join.
> Over time your idea snowballs and gets added in, but this doesn't mean that
> there is a formal roadmap for people to sit at and program away against.
>
> However this is where Spoon comes in. We do have plans and roadmaps of
> features we want to add. Some take time and require people. If you are
> interested in our roadmap (our party) you and anyone else is free to join.
>
> Make sense?
>
> J

This actually does make sense for features.

So can I ask this, am I to then just look at the bug base, say hey  
that looks like something I can fix, fix it then commit it?

Don't jump on this to quick, I am saying there needs to be a unit  
test? I remember Alex saying that Apache is usually commit & review  
but that they were trying for a review and commit in the beginning.  
Has anybody else heard this?

Does there have to be votes on say a new component that would be added  
to the SDK? I'm really just trying to understand the algorithm of  
develop/test/fix/commit for an initial committer.

Thanks,
Mike






Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Greg Reddin
In reply to this post by Jonathan Campos
On Wed, Jan 4, 2012 at 2:08 PM, Jonathan Campos <[hidden email]> wrote:
> Roy Fielding had a great analogy/answer.
> The main idea is that this is that we are throwing a party, not running a
> business with free labor. So people need to be energized about what they
> are doing, they aren't there to be given tasks.
>
> As such there is no roadmap. You may come up with a great idea and start
> working on it, then when other people see what you are doing they may join.
> Over time your idea snowballs and gets added in, but this doesn't mean that
> there is a formal roadmap for people to sit at and program away against.

That basically uses fewer words to say what I was trying to say :-)

Of course, it doesn't mean you can't have a roadmap. It just means if
someone wants to go off-roading we won't try to stop them.

Greg

Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Alex Harui
In reply to this post by Fréderic Cox
Let's be clear that Spoon's roadmaps and priorities are independent of the
Flex project in the Apache incubator.  Several committers to Flex are also
Spoon members and they will coordinate with each other and hopefully make
major contributions to the Flex project.

But if you are a committer and you want to check something in, you don't
have to get Spoon involved, just do it.  If folks don't like it, it will get
vetoed.  And as I said in my other post, I would discuss major changes on
this list before committing it.

If you are not yet a committer, wait until we get JIRA up then submit a
patch, get folks to vote for your patch then get a committers attention to
review and accept it.


On 1/4/12 12:17 PM, "Fréderic Cox" <[hidden email]> wrote:

> This makes sense to me if we can also vote on the features of Spoon to
> influence priority
>
> On 04/01/12 21:08, "Jonathan Campos" <[hidden email]> wrote:
>
>> That is an exact question that I asked at the Flex Summit specifically for
>> the group.
>>
>> Roy Fielding had a great analogy/answer.
>> The main idea is that this is that we are throwing a party, not running a
>> business with free labor. So people need to be energized about what they
>> are doing, they aren't there to be given tasks.
>>
>> As such there is no roadmap. You may come up with a great idea and start
>> working on it, then when other people see what you are doing they may
>> join.
>> Over time your idea snowballs and gets added in, but this doesn't mean
>> that
>> there is a formal roadmap for people to sit at and program away against.
>>
>> However this is where Spoon comes in. We do have plans and roadmaps of
>> features we want to add. Some take time and require people. If you are
>> interested in our roadmap (our party) you and anyone else is free to join.
>>
>> Make sense?
>>
>> J
>>
>> On Wed, Jan 4, 2012 at 1:58 PM, Peter Elst <[hidden email]> wrote:
>>
>>> Thats a good point I've not been clear on either - is roadmap discussed
>>> on
>>> the mailinglist and voted on so there's a bit of structure to what type
>>> of
>>> things get worked on rather than a random collection of bug fixes and
>>> non-related features?
>>>
>>> - Peter
>>>
>>>
>>> On Wed, Jan 4, 2012 at 7:17 PM, Jeffry Houser <[hidden email]>
>>> wrote:
>>>
>>>>
>>>>  Be sure to watch the "What it Means to be an Apache Project" from the
>>>> Flex Summit, here:
>>>>
>>>> http://tv.adobe.com/show/flex-**community-summit-december-**2011/<
>>> http://tv.adobe.com/show/flex-community-summit-december-2011/>
>>>>
>>>>  My understanding is that we do whatever we want.  I don't know how
>>> that
>>>> goes from "chaos" to "release" yet, though.
>>>>
>>>>
>>>> On 1/4/2012 2:12 PM, Michael Schmalle wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I was just curious if there was any Apache Flex specific information
>>>>> floating around about how duties might be divided on each others
>>> strength
>>>>> in relation to our understanding of the SDK.
>>>>>
>>>>> I know there is the official committer information page that Alex
>>>>> provided but has there been any discussion on how an initial
>>> committer
>>> can
>>>>> prepare for whats to be expected in the Apache Flex project?
>>>>>
>>>>> Or is this just to soon to ask this question?
>>>>>
>>>>> Thanks,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Jeffry Houser
>>>> Technical Entrepreneur
>>>> 203-379-0773
>>>> --
>>>> http://www.flextras.com?c=104
>>>> UI Flex Components: Tested! Supported! Ready!
>>>> --
>>>> http://www.theflexshow.com
>>>> http://www.jeffryhouser.com
>>>> http://www.asktheflexpert.com
>>>> --
>>>> Part of the DotComIt Brain Trust
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Jonathan Campos
>> Dallas Flex User Group Manager
>> http://www.d-flex.org/
>> blog: http://www.unitedmindset.com/jonbcampos
>> twitter: http://www.twitter.com/jonbcampos
>

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Jonathan Campos
In reply to this post by Michael Schmalle
These are great questions and many of them that we asked at the Flex Summit.

You could also pick off a bug, fix it, get reviewed, and get a committer to
submit. The patch would be able to still be voted down if the patch wasn't
liked by another committer and discussions would follow.

For a new component you could try to just add it in, but you'll go through
this same process of review and voting. I've said it before a few times
that there are plenty of people that have their own amazing "login window
component", doesn't meant that it will go in if other committers disagree.
That doesn't mean that the component isn't the most amazing thing since
sliced bread, just means that maybe it doesn't belong in the framework that
everyone uses. That is what 3rd party add-ons are perfect for.

We as a group should be focusing on what we can do to make these 3rd party
add-ons easier to include, not how to get everything and the kitchen sink
into the framework.

On Wed, Jan 4, 2012 at 2:19 PM, Michael Schmalle <[hidden email]>wrote:

> Quoting Jonathan Campos <[hidden email]>:
>
>  That is an exact question that I asked at the Flex Summit specifically for
>> the group.
>>
>> Roy Fielding had a great analogy/answer.
>> The main idea is that this is that we are throwing a party, not running a
>> business with free labor. So people need to be energized about what they
>> are doing, they aren't there to be given tasks.
>>
>> As such there is no roadmap. You may come up with a great idea and start
>> working on it, then when other people see what you are doing they may
>> join.
>> Over time your idea snowballs and gets added in, but this doesn't mean
>> that
>> there is a formal roadmap for people to sit at and program away against.
>>
>> However this is where Spoon comes in. We do have plans and roadmaps of
>> features we want to add. Some take time and require people. If you are
>> interested in our roadmap (our party) you and anyone else is free to join.
>>
>> Make sense?
>>
>> J
>>
>
> This actually does make sense for features.
>
> So can I ask this, am I to then just look at the bug base, say hey that
> looks like something I can fix, fix it then commit it?
>
> Don't jump on this to quick, I am saying there needs to be a unit test? I
> remember Alex saying that Apache is usually commit & review but that they
> were trying for a review and commit in the beginning. Has anybody else
> heard this?
>
> Does there have to be votes on say a new component that would be added to
> the SDK? I'm really just trying to understand the algorithm of
> develop/test/fix/commit for an initial committer.
>
> Thanks,
> Mike
>
>
>
>
>
>


--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Peter Elst
In reply to this post by Michael Schmalle
I'm excited to what Spoon can add to the mix and the idea of a plan on your
end sounds very appealing to me and gives some guidance to the community.

I might be jumping the gun on this and not hoping this happens but how
strongly does Spoon feel about its roadmap and would you for example look
at forking if certain bits don't get accepted in.

Would hate to see us end up in a situation like that, or the opposite where
Spoon as likely one of the biggest contributors de facto dictate where the
product is going and the discussion on that happens within the Spoon
project.

Not to be negative - think it is good to bring up and discuss exactly how
Spoon will function within this setup.

Thanks,
Peter


On Wed, Jan 4, 2012 at 8:19 PM, Michael Schmalle <[hidden email]>wrote:

> Quoting Jonathan Campos <[hidden email]>:
>
>  That is an exact question that I asked at the Flex Summit specifically for
>> the group.
>>
>> Roy Fielding had a great analogy/answer.
>> The main idea is that this is that we are throwing a party, not running a
>> business with free labor. So people need to be energized about what they
>> are doing, they aren't there to be given tasks.
>>
>> As such there is no roadmap. You may come up with a great idea and start
>> working on it, then when other people see what you are doing they may
>> join.
>> Over time your idea snowballs and gets added in, but this doesn't mean
>> that
>> there is a formal roadmap for people to sit at and program away against.
>>
>> However this is where Spoon comes in. We do have plans and roadmaps of
>> features we want to add. Some take time and require people. If you are
>> interested in our roadmap (our party) you and anyone else is free to join.
>>
>> Make sense?
>>
>> J
>>
>
> This actually does make sense for features.
>
> So can I ask this, am I to then just look at the bug base, say hey that
> looks like something I can fix, fix it then commit it?
>
> Don't jump on this to quick, I am saying there needs to be a unit test? I
> remember Alex saying that Apache is usually commit & review but that they
> were trying for a review and commit in the beginning. Has anybody else
> heard this?
>
> Does there have to be votes on say a new component that would be added to
> the SDK? I'm really just trying to understand the algorithm of
> develop/test/fix/commit for an initial committer.
>
> Thanks,
> Mike
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Jonathan Campos
In reply to this post by Alex Harui
I completely agree with Alex. If I made it seem that you had to be part of
Spoon or even care about what we care about I miscommunicated.

On Wed, Jan 4, 2012 at 2:24 PM, Alex Harui <[hidden email]> wrote:

> Let's be clear that Spoon's roadmaps and priorities are independent of the
> Flex project in the Apache incubator.  Several committers to Flex are also
> Spoon members and they will coordinate with each other and hopefully make
> major contributions to the Flex project.
>
> But if you are a committer and you want to check something in, you don't
> have to get Spoon involved, just do it.  If folks don't like it, it will
> get
> vetoed.  And as I said in my other post, I would discuss major changes on
> this list before committing it.
>
> If you are not yet a committer, wait until we get JIRA up then submit a
> patch, get folks to vote for your patch then get a committers attention to
> review and accept it.
>
>
> On 1/4/12 12:17 PM, "Fréderic Cox" <[hidden email]> wrote:
>
> > This makes sense to me if we can also vote on the features of Spoon to
> > influence priority
> >
> > On 04/01/12 21:08, "Jonathan Campos" <[hidden email]> wrote:
> >
> >> That is an exact question that I asked at the Flex Summit specifically
> for
> >> the group.
> >>
> >> Roy Fielding had a great analogy/answer.
> >> The main idea is that this is that we are throwing a party, not running
> a
> >> business with free labor. So people need to be energized about what they
> >> are doing, they aren't there to be given tasks.
> >>
> >> As such there is no roadmap. You may come up with a great idea and start
> >> working on it, then when other people see what you are doing they may
> >> join.
> >> Over time your idea snowballs and gets added in, but this doesn't mean
> >> that
> >> there is a formal roadmap for people to sit at and program away against.
> >>
> >> However this is where Spoon comes in. We do have plans and roadmaps of
> >> features we want to add. Some take time and require people. If you are
> >> interested in our roadmap (our party) you and anyone else is free to
> join.
> >>
> >> Make sense?
> >>
> >> J
> >>
> >> On Wed, Jan 4, 2012 at 1:58 PM, Peter Elst <[hidden email]>
> wrote:
> >>
> >>> Thats a good point I've not been clear on either - is roadmap discussed
> >>> on
> >>> the mailinglist and voted on so there's a bit of structure to what type
> >>> of
> >>> things get worked on rather than a random collection of bug fixes and
> >>> non-related features?
> >>>
> >>> - Peter
> >>>
> >>>
> >>> On Wed, Jan 4, 2012 at 7:17 PM, Jeffry Houser <[hidden email]>
> >>> wrote:
> >>>
> >>>>
> >>>>  Be sure to watch the "What it Means to be an Apache Project" from the
> >>>> Flex Summit, here:
> >>>>
> >>>> http://tv.adobe.com/show/flex-**community-summit-december-**2011/<
> >>> http://tv.adobe.com/show/flex-community-summit-december-2011/>
> >>>>
> >>>>  My understanding is that we do whatever we want.  I don't know how
> >>> that
> >>>> goes from "chaos" to "release" yet, though.
> >>>>
> >>>>
> >>>> On 1/4/2012 2:12 PM, Michael Schmalle wrote:
> >>>>
> >>>>> Hi All,
> >>>>>
> >>>>> I was just curious if there was any Apache Flex specific information
> >>>>> floating around about how duties might be divided on each others
> >>> strength
> >>>>> in relation to our understanding of the SDK.
> >>>>>
> >>>>> I know there is the official committer information page that Alex
> >>>>> provided but has there been any discussion on how an initial
> >>> committer
> >>> can
> >>>>> prepare for whats to be expected in the Apache Flex project?
> >>>>>
> >>>>> Or is this just to soon to ask this question?
> >>>>>
> >>>>> Thanks,
> >>>>> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Jeffry Houser
> >>>> Technical Entrepreneur
> >>>> 203-379-0773
> >>>> --
> >>>> http://www.flextras.com?c=104
> >>>> UI Flex Components: Tested! Supported! Ready!
> >>>> --
> >>>> http://www.theflexshow.com
> >>>> http://www.jeffryhouser.com
> >>>> http://www.asktheflexpert.com
> >>>> --
> >>>> Part of the DotComIt Brain Trust
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Jonathan Campos
> >> Dallas Flex User Group Manager
> >> http://www.d-flex.org/
> >> blog: http://www.unitedmindset.com/jonbcampos
> >> twitter: http://www.twitter.com/jonbcampos
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>


--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Michael Schmalle
In reply to this post by Jonathan Campos
> You could also pick off a bug, fix it, get reviewed, and get a committer to
> submit. The patch would be able to still be voted down if the patch wasn't
> liked by another committer and discussions would follow.

I am an initial committer, that is why I am asking these questions. I  
also agree that the kitchen sink shouldn't be included in the core SDK  
but there should be some off-shoot of some kind.

Also I signed up for Spoon more than a month ago, you guys said you  
would get back to me I have not not heard anything, so these questions  
are trying to clear the fog for me.

Mike

Quoting Jonathan Campos <[hidden email]>:

> These are great questions and many of them that we asked at the Flex Summit.
>
> You could also pick off a bug, fix it, get reviewed, and get a committer to
> submit. The patch would be able to still be voted down if the patch wasn't
> liked by another committer and discussions would follow.
>
> For a new component you could try to just add it in, but you'll go through
> this same process of review and voting. I've said it before a few times
> that there are plenty of people that have their own amazing "login window
> component", doesn't meant that it will go in if other committers disagree.
> That doesn't mean that the component isn't the most amazing thing since
> sliced bread, just means that maybe it doesn't belong in the framework that
> everyone uses. That is what 3rd party add-ons are perfect for.
>
> We as a group should be focusing on what we can do to make these 3rd party
> add-ons easier to include, not how to get everything and the kitchen sink
> into the framework.
>
> On Wed, Jan 4, 2012 at 2:19 PM, Michael Schmalle  
> <[hidden email]>wrote:
>
>> Quoting Jonathan Campos <[hidden email]>:
>>
>>  That is an exact question that I asked at the Flex Summit specifically for
>>> the group.
>>>
>>> Roy Fielding had a great analogy/answer.
>>> The main idea is that this is that we are throwing a party, not running a
>>> business with free labor. So people need to be energized about what they
>>> are doing, they aren't there to be given tasks.
>>>
>>> As such there is no roadmap. You may come up with a great idea and start
>>> working on it, then when other people see what you are doing they may
>>> join.
>>> Over time your idea snowballs and gets added in, but this doesn't mean
>>> that
>>> there is a formal roadmap for people to sit at and program away against.
>>>
>>> However this is where Spoon comes in. We do have plans and roadmaps of
>>> features we want to add. Some take time and require people. If you are
>>> interested in our roadmap (our party) you and anyone else is free to join.
>>>
>>> Make sense?
>>>
>>> J
>>>
>>
>> This actually does make sense for features.
>>
>> So can I ask this, am I to then just look at the bug base, say hey that
>> looks like something I can fix, fix it then commit it?
>>
>> Don't jump on this to quick, I am saying there needs to be a unit test? I
>> remember Alex saying that Apache is usually commit & review but that they
>> were trying for a review and commit in the beginning. Has anybody else
>> heard this?
>>
>> Does there have to be votes on say a new component that would be added to
>> the SDK? I'm really just trying to understand the algorithm of
>> develop/test/fix/commit for an initial committer.
>>
>> Thanks,
>> Mike
>>
>>
>>
>>
>>
>>
>
>
> --
> Jonathan Campos
> Dallas Flex User Group Manager
> http://www.d-flex.org/
> blog: http://www.unitedmindset.com/jonbcampos
> twitter: http://www.twitter.com/jonbcampos
>




Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Jonathan Campos
In reply to this post by Peter Elst
I can tell you that we have no interest in splintering the community or our
efforts.

Like an Apache project we all come together in Spoon from various companies
and interests. We've just highlighted a few spots that we all are wanting
to develop on a large scale (more than just a bug fix or a few lines of
docs).

We would hope that through discussion and development that our plans and
everyone else should line up. We just are trying to have more structure.
That way if someone wants to get involved but doesn't know where, they
could always look to Spoon as a supporting organization that provides some
direction.

J

On Wed, Jan 4, 2012 at 2:27 PM, Peter Elst <[hidden email]> wrote:

> I'm excited to what Spoon can add to the mix and the idea of a plan on your
> end sounds very appealing to me and gives some guidance to the community.
>
> I might be jumping the gun on this and not hoping this happens but how
> strongly does Spoon feel about its roadmap and would you for example look
> at forking if certain bits don't get accepted in.
>
> Would hate to see us end up in a situation like that, or the opposite where
> Spoon as likely one of the biggest contributors de facto dictate where the
> product is going and the discussion on that happens within the Spoon
> project.
>
> Not to be negative - think it is good to bring up and discuss exactly how
> Spoon will function within this setup.
>
> Thanks,
> Peter
>
>
> On Wed, Jan 4, 2012 at 8:19 PM, Michael Schmalle <[hidden email]
> >wrote:
>
> > Quoting Jonathan Campos <[hidden email]>:
> >
> >  That is an exact question that I asked at the Flex Summit specifically
> for
> >> the group.
> >>
> >> Roy Fielding had a great analogy/answer.
> >> The main idea is that this is that we are throwing a party, not running
> a
> >> business with free labor. So people need to be energized about what they
> >> are doing, they aren't there to be given tasks.
> >>
> >> As such there is no roadmap. You may come up with a great idea and start
> >> working on it, then when other people see what you are doing they may
> >> join.
> >> Over time your idea snowballs and gets added in, but this doesn't mean
> >> that
> >> there is a formal roadmap for people to sit at and program away against.
> >>
> >> However this is where Spoon comes in. We do have plans and roadmaps of
> >> features we want to add. Some take time and require people. If you are
> >> interested in our roadmap (our party) you and anyone else is free to
> join.
> >>
> >> Make sense?
> >>
> >> J
> >>
> >
> > This actually does make sense for features.
> >
> > So can I ask this, am I to then just look at the bug base, say hey that
> > looks like something I can fix, fix it then commit it?
> >
> > Don't jump on this to quick, I am saying there needs to be a unit test? I
> > remember Alex saying that Apache is usually commit & review but that they
> > were trying for a review and commit in the beginning. Has anybody else
> > heard this?
> >
> > Does there have to be votes on say a new component that would be added to
> > the SDK? I'm really just trying to understand the algorithm of
> > develop/test/fix/commit for an initial committer.
> >
> > Thanks,
> > Mike
> >
> >
> >
> >
> >
> >
>



--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Greg Reddin
In reply to this post by Peter Elst
On Wed, Jan 4, 2012 at 2:27 PM, Peter Elst <[hidden email]> wrote:
> I'm excited to what Spoon can add to the mix

For the uninitiated, what is Spoon?

Greg

Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Jonathan Campos
In reply to this post by Michael Schmalle
Mike,

I can't say for sure what may have happened, but I know that we have been
working actively to send out a few newsletters and details when available.
With the Flex Summit, and these movements with Apache we've had to be a bit
patient waiting for this stuff to be straightened out. Now that things are
moving forward so will we.

J

On Wed, Jan 4, 2012 at 2:30 PM, Michael Schmalle <[hidden email]>wrote:

>  You could also pick off a bug, fix it, get reviewed, and get a committer
>> to
>> submit. The patch would be able to still be voted down if the patch wasn't
>> liked by another committer and discussions would follow.
>>
>
> I am an initial committer, that is why I am asking these questions. I also
> agree that the kitchen sink shouldn't be included in the core SDK but there
> should be some off-shoot of some kind.
>
> Also I signed up for Spoon more than a month ago, you guys said you would
> get back to me I have not not heard anything, so these questions are trying
> to clear the fog for me.
>
> Mike
>
>
> Quoting Jonathan Campos <[hidden email]>:
>
>  These are great questions and many of them that we asked at the Flex
>> Summit.
>>
>> You could also pick off a bug, fix it, get reviewed, and get a committer
>> to
>> submit. The patch would be able to still be voted down if the patch wasn't
>> liked by another committer and discussions would follow.
>>
>> For a new component you could try to just add it in, but you'll go through
>> this same process of review and voting. I've said it before a few times
>> that there are plenty of people that have their own amazing "login window
>> component", doesn't meant that it will go in if other committers disagree.
>> That doesn't mean that the component isn't the most amazing thing since
>> sliced bread, just means that maybe it doesn't belong in the framework
>> that
>> everyone uses. That is what 3rd party add-ons are perfect for.
>>
>> We as a group should be focusing on what we can do to make these 3rd party
>> add-ons easier to include, not how to get everything and the kitchen sink
>> into the framework.
>>
>> On Wed, Jan 4, 2012 at 2:19 PM, Michael Schmalle <[hidden email]
>> >wrote:
>>
>>  Quoting Jonathan Campos <[hidden email]>:
>>>
>>>  That is an exact question that I asked at the Flex Summit specifically
>>> for
>>>
>>>> the group.
>>>>
>>>> Roy Fielding had a great analogy/answer.
>>>> The main idea is that this is that we are throwing a party, not running
>>>> a
>>>> business with free labor. So people need to be energized about what they
>>>> are doing, they aren't there to be given tasks.
>>>>
>>>> As such there is no roadmap. You may come up with a great idea and start
>>>> working on it, then when other people see what you are doing they may
>>>> join.
>>>> Over time your idea snowballs and gets added in, but this doesn't mean
>>>> that
>>>> there is a formal roadmap for people to sit at and program away against.
>>>>
>>>> However this is where Spoon comes in. We do have plans and roadmaps of
>>>> features we want to add. Some take time and require people. If you are
>>>> interested in our roadmap (our party) you and anyone else is free to
>>>> join.
>>>>
>>>> Make sense?
>>>>
>>>> J
>>>>
>>>>
>>> This actually does make sense for features.
>>>
>>> So can I ask this, am I to then just look at the bug base, say hey that
>>> looks like something I can fix, fix it then commit it?
>>>
>>> Don't jump on this to quick, I am saying there needs to be a unit test? I
>>> remember Alex saying that Apache is usually commit & review but that they
>>> were trying for a review and commit in the beginning. Has anybody else
>>> heard this?
>>>
>>> Does there have to be votes on say a new component that would be added to
>>> the SDK? I'm really just trying to understand the algorithm of
>>> develop/test/fix/commit for an initial committer.
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Jonathan Campos
>> Dallas Flex User Group Manager
>> http://www.d-flex.org/
>> blog: http://www.unitedmindset.com/**jonbcampos<http://www.unitedmindset.com/jonbcampos>
>> twitter: http://www.twitter.com/**jonbcampos<http://www.twitter.com/jonbcampos>
>>
>>
>
>
>


--
Jonathan Campos
Dallas Flex User Group Manager
http://www.d-flex.org/
blog: http://www.unitedmindset.com/jonbcampos
twitter: http://www.twitter.com/jonbcampos
Reply | Threaded
Open this post in threaded view
|

Re: Committer duties and information

Alex Harui
In reply to this post by Michael Schmalle
So for practical reasons, I think we're going to start with
commit-then-review.

If you try to commit a new component, that commit will be reviewed and
vetoed out if there is a problem.

So let's get specific.  Let's say you want to contribute your version of a
Spark TabNavigator component.  Adobe has almost finished its version and
promised to commit it.  I would recommend starting a discussion on this list
about whether to take yours vs Adobe's.  That way you'll at least have an
idea whether folks are willing to review your version or want to wait for
Adobe.  Then if you do decide to commit, we'll take a harder look at the
code and maybe you'll get rejected if we find some major problem, but
otherwise it gets in.  And if folks want to wait for Adobe and you disagree,
you can offer it up under a different package name.  I suppose someone might
still try to veto that based on confusing folks about which TabNavigator to
use, so that might be worth discussing up front as well, but I personally
don't have a problems with different flavors of components.

-Alex


On 1/4/12 12:19 PM, "Michael Schmalle" <[hidden email]> wrote:

> Quoting Jonathan Campos <[hidden email]>:
>
>> That is an exact question that I asked at the Flex Summit specifically for
>> the group.
>>
>> Roy Fielding had a great analogy/answer.
>> The main idea is that this is that we are throwing a party, not running a
>> business with free labor. So people need to be energized about what they
>> are doing, they aren't there to be given tasks.
>>
>> As such there is no roadmap. You may come up with a great idea and start
>> working on it, then when other people see what you are doing they may join.
>> Over time your idea snowballs and gets added in, but this doesn't mean that
>> there is a formal roadmap for people to sit at and program away against.
>>
>> However this is where Spoon comes in. We do have plans and roadmaps of
>> features we want to add. Some take time and require people. If you are
>> interested in our roadmap (our party) you and anyone else is free to join.
>>
>> Make sense?
>>
>> J
>
> This actually does make sense for features.
>
> So can I ask this, am I to then just look at the bug base, say hey
> that looks like something I can fix, fix it then commit it?
>
> Don't jump on this to quick, I am saying there needs to be a unit
> test? I remember Alex saying that Apache is usually commit & review
> but that they were trying for a review and commit in the beginning.
> Has anybody else heard this?
>
> Does there have to be votes on say a new component that would be added
> to the SDK? I'm really just trying to understand the algorithm of
> develop/test/fix/commit for an initial committer.
>
> Thanks,
> Mike
>
>
>
>
>

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


123