You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/01/05 01:42:14 UTC
So, what should we do first?
I’m loving the ideas and energy on this list so far. And so, the subject question needs to be answered: What should we (the committers in this project) do first?
I recall from the summit that a healthy Apache project releases at least every 4 to 6 months, and one of the things an incubator podling has to do is cut at least one release so it can show it knows the Apache way of doing so. So, while we’ve got lots of good ideas out there around refactoring Flex, lots of those seem like more than a 4 to 6 month project. They should certainly get underway, but we also need to make sure we make enough useful, short-term fixes to be worthy of a release so we can practice making a release. I’m thinking that means we pick off a bunch of bugs to fix, and maybe take a new component or two or three.
To do so without getting de-stabilized by the longer term projects, we should agree on a branch strategy. It sounds like many Apache projects have multiple branches like:
-Sandbox: Anything that doesn’t fall over immediately can go here
-Unstable: Things that are being polished for release can go here
-Stable: The release candidate goes here.
-Released: The latest release.
Long term projects would go in Sandbox and shorter term stuff would go in Unstable and get synched to Sandbox if required.
Most of you are volunteers trying to scratch out spare time to make contributions, but some of us have all day to work on this stuff. I am thinking of splitting time between long-term work and short term work and use JIRA to guide what short-term work I do.
So, add your thoughts on branch strategy (especially Apache veterans). You can discuss your favorite short-term project if you want, but what really matters is whether you’ll get around to committing it. And of course, this is all talk until we get cleared to submit the code and get JIRA up and running.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: So, what should we do first?
Posted by Web DoubleFx <we...@hotmail.com>.
An other way, maybe clearer in term of dev and branching would maybe the use of svn as master and git for branching, you can read more in the links bellow :
http://blogpro.toutantic.net/2012/01/02/another-git-branching-model/ http://wiki.apache.org/general/GitAtApache
Frédéric Thomas
> Date: Wed, 4 Jan 2012 20:56:47 -0500
> From: jeffry@dot-com-it.com
> To: flex-dev@incubator.apache.org
> Subject: Re: So, what should we do first?
>
>
> I can honestly say it's been a long time since I looked at the public
> Flex SVN repo; so I'm not sure the extent of what is in there or how it
> is organized.
>
> Most projects I've worked on have used a "Trunk/Branch/Tag" approach.
> To map:
>
> * Released sounds kind of like tags; which is a full snapshot in time
> that--presumably--doesn't change.
> * Stable sounds kind of like Trunk, which is the primary working branch
> for the next version.
> * Sandbox/Unstable sound like branch; which are different working
> copies. They often start as an off-shoot of the trunk; presumably to be
> combined back in at some future point.
>
> Is it worthwhile to separate "long term development" (Sandbox) ) vs
> "Short term stuff development" (UnStable)? I assume we wouldn't want to
> do that development in the same sub-branch; but is there a reason to
> make the distinction between short term and long term development?
>
> Beyond that, I don't have a strong opinion either way.
>
> On 1/4/2012 7:42 PM, Alex Harui wrote:
> > I’m loving the ideas and energy on this list so far. And so, the subject question needs to be answered: What should we (the committers in this project) do first?
> >
> >
> > To do so without getting de-stabilized by the longer term projects, we should agree on a branch strategy. It sounds like many Apache projects have multiple branches like:
> > -Sandbox: Anything that doesn’t fall over immediately can go here
> > -Unstable: Things that are being polished for release can go here
> > -Stable: The release candidate goes here.
> > -Released: The latest release.
> >
> > Long term projects would go in Sandbox and shorter term stuff would go in Unstable and get synched to Sandbox if required.
> >
> > Most of you are volunteers trying to scratch out spare time to make contributions, but some of us have all day to work on this stuff. I am thinking of splitting time between long-term work and short term work and use JIRA to guide what short-term work I do.
>
>
> --
> 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
>
Re: So, what should we do first?
Posted by Jeffry Houser <je...@dot-com-it.com>.
I can honestly say it's been a long time since I looked at the public
Flex SVN repo; so I'm not sure the extent of what is in there or how it
is organized.
Most projects I've worked on have used a "Trunk/Branch/Tag" approach.
To map:
* Released sounds kind of like tags; which is a full snapshot in time
that--presumably--doesn't change.
* Stable sounds kind of like Trunk, which is the primary working branch
for the next version.
* Sandbox/Unstable sound like branch; which are different working
copies. They often start as an off-shoot of the trunk; presumably to be
combined back in at some future point.
Is it worthwhile to separate "long term development" (Sandbox) ) vs
"Short term stuff development" (UnStable)? I assume we wouldn't want to
do that development in the same sub-branch; but is there a reason to
make the distinction between short term and long term development?
Beyond that, I don't have a strong opinion either way.
On 1/4/2012 7:42 PM, Alex Harui wrote:
> I’m loving the ideas and energy on this list so far. And so, the subject question needs to be answered: What should we (the committers in this project) do first?
>
>
> To do so without getting de-stabilized by the longer term projects, we should agree on a branch strategy. It sounds like many Apache projects have multiple branches like:
> -Sandbox: Anything that doesn’t fall over immediately can go here
> -Unstable: Things that are being polished for release can go here
> -Stable: The release candidate goes here.
> -Released: The latest release.
>
> Long term projects would go in Sandbox and shorter term stuff would go in Unstable and get synched to Sandbox if required.
>
> Most of you are volunteers trying to scratch out spare time to make contributions, but some of us have all day to work on this stuff. I am thinking of splitting time between long-term work and short term work and use JIRA to guide what short-term work I do.
--
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
Re: So, what should we do first?
Posted by Arturo Alvarado <ar...@centraldcom.com>.
As a short term project, how about bringing some of the new mobile components to the Desktop/Web?
Arturo Alvarado
----- Original Message -----
From: "Alex Harui" <ah...@adobe.com>
To: flex-dev@incubator.apache.org
Sent: Wednesday, January 4, 2012 7:13:36 PM
Subject: Re: So, what should we do first?
Still hoping for end of week, but maybe Monday.
-Alex
On 1/4/12 4:54 PM, "Jeff Tapper" <je...@spoon.as> wrote:
> Any idea how long till adobe commits the code?
> On Jan 4, 2012 7:44 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>> I¹m loving the ideas and energy on this list so far. And so, the subject
>> question needs to be answered: What should we (the committers in this
>> project) do first?
>>
>> I recall from the summit that a healthy Apache project releases at least
>> every 4 to 6 months, and one of the things an incubator podling has to do
>> is cut at least one release so it can show it knows the Apache way of doing
>> so. So, while we¹ve got lots of good ideas out there around refactoring
>> Flex, lots of those seem like more than a 4 to 6 month project. They
>> should certainly get underway, but we also need to make sure we make enough
>> useful, short-term fixes to be worthy of a release so we can practice
>> making a release. I¹m thinking that means we pick off a bunch of bugs to
>> fix, and maybe take a new component or two or three.
>>
>> To do so without getting de-stabilized by the longer term projects, we
>> should agree on a branch strategy. It sounds like many Apache projects
>> have multiple branches like:
>> -Sandbox: Anything that doesn¹t fall over immediately can go here
>> -Unstable: Things that are being polished for release can go here
>> -Stable: The release candidate goes here.
>> -Released: The latest release.
>>
>> Long term projects would go in Sandbox and shorter term stuff would go in
>> Unstable and get synched to Sandbox if required.
>>
>> Most of you are volunteers trying to scratch out spare time to make
>> contributions, but some of us have all day to work on this stuff. I am
>> thinking of splitting time between long-term work and short term work and
>> use JIRA to guide what short-term work I do.
>>
>> So, add your thoughts on branch strategy (especially Apache veterans).
>> You can discuss your favorite short-term project if you want, but what
>> really matters is whether you¹ll get around to committing it. And of
>> course, this is all talk until we get cleared to submit the code and get
>> JIRA up and running.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: So, what should we do first?
Posted by Alex Harui <ah...@adobe.com>.
Still hoping for end of week, but maybe Monday.
-Alex
On 1/4/12 4:54 PM, "Jeff Tapper" <je...@spoon.as> wrote:
> Any idea how long till adobe commits the code?
> On Jan 4, 2012 7:44 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>> I¹m loving the ideas and energy on this list so far. And so, the subject
>> question needs to be answered: What should we (the committers in this
>> project) do first?
>>
>> I recall from the summit that a healthy Apache project releases at least
>> every 4 to 6 months, and one of the things an incubator podling has to do
>> is cut at least one release so it can show it knows the Apache way of doing
>> so. So, while we¹ve got lots of good ideas out there around refactoring
>> Flex, lots of those seem like more than a 4 to 6 month project. They
>> should certainly get underway, but we also need to make sure we make enough
>> useful, short-term fixes to be worthy of a release so we can practice
>> making a release. I¹m thinking that means we pick off a bunch of bugs to
>> fix, and maybe take a new component or two or three.
>>
>> To do so without getting de-stabilized by the longer term projects, we
>> should agree on a branch strategy. It sounds like many Apache projects
>> have multiple branches like:
>> -Sandbox: Anything that doesn¹t fall over immediately can go here
>> -Unstable: Things that are being polished for release can go here
>> -Stable: The release candidate goes here.
>> -Released: The latest release.
>>
>> Long term projects would go in Sandbox and shorter term stuff would go in
>> Unstable and get synched to Sandbox if required.
>>
>> Most of you are volunteers trying to scratch out spare time to make
>> contributions, but some of us have all day to work on this stuff. I am
>> thinking of splitting time between long-term work and short term work and
>> use JIRA to guide what short-term work I do.
>>
>> So, add your thoughts on branch strategy (especially Apache veterans).
>> You can discuss your favorite short-term project if you want, but what
>> really matters is whether you¹ll get around to committing it. And of
>> course, this is all talk until we get cleared to submit the code and get
>> JIRA up and running.
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: So, what should we do first?
Posted by Jeff Tapper <je...@spoon.as>.
Any idea how long till adobe commits the code?
On Jan 4, 2012 7:44 PM, "Alex Harui" <ah...@adobe.com> wrote:
> I’m loving the ideas and energy on this list so far. And so, the subject
> question needs to be answered: What should we (the committers in this
> project) do first?
>
> I recall from the summit that a healthy Apache project releases at least
> every 4 to 6 months, and one of the things an incubator podling has to do
> is cut at least one release so it can show it knows the Apache way of doing
> so. So, while we’ve got lots of good ideas out there around refactoring
> Flex, lots of those seem like more than a 4 to 6 month project. They
> should certainly get underway, but we also need to make sure we make enough
> useful, short-term fixes to be worthy of a release so we can practice
> making a release. I’m thinking that means we pick off a bunch of bugs to
> fix, and maybe take a new component or two or three.
>
> To do so without getting de-stabilized by the longer term projects, we
> should agree on a branch strategy. It sounds like many Apache projects
> have multiple branches like:
> -Sandbox: Anything that doesn’t fall over immediately can go here
> -Unstable: Things that are being polished for release can go here
> -Stable: The release candidate goes here.
> -Released: The latest release.
>
> Long term projects would go in Sandbox and shorter term stuff would go in
> Unstable and get synched to Sandbox if required.
>
> Most of you are volunteers trying to scratch out spare time to make
> contributions, but some of us have all day to work on this stuff. I am
> thinking of splitting time between long-term work and short term work and
> use JIRA to guide what short-term work I do.
>
> So, add your thoughts on branch strategy (especially Apache veterans).
> You can discuss your favorite short-term project if you want, but what
> really matters is whether you’ll get around to committing it. And of
> course, this is all talk until we get cleared to submit the code and get
> JIRA up and running.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>