Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F05ACB8.4040301@dot-com-it.com>
Date: Thu, 05 Jan 2012 08:59:20 -0500
From: Jeffry Houser <jeffry@dot-com-it.com>
Reply-To: jeffry@dot-com-it.com
Organization: DotComIt
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: flex-dev@incubator.apache.org
Subject: Re: So, what should we do first?
References: <254f1a76$654d6909$4cb4bdf8$@com>
 <CAAd0WrbLYnzDjJSQyQPNxC-8cyc7zeezY7Hc2QJs0WTRRra9wA@mail.gmail.com>
 <CAEFz_vu6aT-oHmW0efM1z4Tjyfk9Uo3WoQNMzO5O8=9CvttXUw@mail.gmail.com>
In-Reply-To: 
 <CAEFz_vu6aT-oHmW0efM1z4Tjyfk9Uo3WoQNMzO5O8=9CvttXUw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


  You took the word right out of my mouth.

  Perhaps it is beneficial to some people to make a mental distinction 
between types of development.

On 1/5/2012 4:48 AM, Omar Gonzalez wrote:
> I dont understand why creating yourself a branch to create whatever you
> want isn't sufficient. Isn't that what branching is for?
>
> -omar
>
> On Thu, Jan 5, 2012 at 1:45 AM, Jonathan Campos<jonbcampos@gmail.com>wrote:
>
>> Just to expand on what I said earlier. I am hoping we don't agree on
>> removing sandbox.
>>
>> Sandbox is a really important working area for each person. The big thing
>> is that sandbox isn't just a giant dumping ground. Instead it is a giant
>> dumping ground per person. This was I have my section of experimental code
>> vs someone else. Everyone can quickly go through the various sandboxes and
>> see the experimental work each person has, see if they want to work on
>> their experiments, which will lead to the momentum to having a feature
>> including back in trunk.
>>
>> Sandbox is especially important as we don't have a roadmap and there isn't
>> a direct path for people to program down. On most projects you have a focus
>> or agreed goal and developing branches in that direction is simple. Not the
>> same as what we are doing here.
>> On Jan 5, 2012 2:41 AM, "flex@rduartes.net"<flex@rduartes.net>  wrote:
>>
>>> Hi,
>>> I can safely say that I have a bit of experience using Subversion to
>>> manage a long running project with a big development team across several
>>> technologies and the one thing I'm pretty sure of is that, if not managed
>>> correctly from the onset, Subversion could be a nasty beast to handle.
>>> I'll add my suggestion in here about Subversion organization as I've been
>>> giving it a lot of thought lately and I've come to some conclusions/ideas
>>> that might be of interest.
>>> 1. I'd use a main TRUNK branch that would hold a releasable version of
>> the
>>> project. If we are to implement the concept of nightly builds, I'd say
>> they
>>> come out of this main branch;
>>> 2. I'd still create a separate branch for each released version grouped
>> in
>>> a RELEASED or TAGS branch. We would end up having something like this:
>>> /released/v4.7 and /released/v5.0. This would be important if we ever
>> have
>>> (and want) to release fixes and patches for a particular version. These
>>> branches are created from TRUNK when a voting for release is determined;
>>> 3. Every development, big or small, would be done under a feature branch
>>> taken out of TRUNK. A feature branch per development. These feature
>>> branches would be refreshed regularly with code from TRUNK and would be
>>> merged back (and closed) to TRUNK when the development is finished and
>>> ready to be integrated into the main stream after such action is voted by
>>> the group. When different feature branches have dependencies between
>> them,
>>> they should decide which would be the prime branch that would carry
>> changes
>>> from both to TRUNK, this one being refreshed from the dependent branch
>> and
>>> TRUNK. The dependent branch would be merged to the prime branch when it
>>> finishes its development and the prime branch would be merged to TRUNK
>> when
>>> it finishes its development (and has received all merges from the
>> dependent
>>> branch);
>>> 4. Bug fixing for bugs found in a particular version would be done in
>> that
>>> version's RELEASE branch, or a sub-branch thereof and then merged upwards
>>> to TRUNK (and to any released versions if we determine its important
>> enough
>>> to have it fixed in those - I'm thinking security bugs for instance).
>>> I believe that using feature branches, we can have long running
>>> developments without having the need for a generic long term SANDBOX
>> branch
>>> that can very easily get polluted if we decide not to carry something to
>>> TRUNK. If we opt to not release patches to released versions, then
>> there's
>>> effectively no real need to have separate release branches (though it
>> makes
>>> it easier to track down bugs found in a particular version). I also
>> realize
>>> that some of these ideas can be achieved by simply using revision numbers
>>> as a tag system, but since branches are Subversion core concept for
>> tagging
>>> and divergent development control, I'd use those instead.
>>>
>>> Just my two cents on the subject. Sooner or later we'll have to vote on
>>> this, especially if Adobe is about to commit the source code.
>>> Cheers,Rui
>>>
>>> ----------------------------------------
>>> From: "Alex Harui"<aharui@adobe.com>
>>> Sent: quinta-feira, 5 de Janeiro de 2012 7:15
>>> To: "flex-dev@incubator.apache.org"<flex-dev@incubator.apache.org>
>>> Subject: Re: So, what should we do first?
>>>
>>> Maybe the mentors will guide us here.  I seem to have the impression that
>>> the trunk should always be the release.  It can never be in a state that
>>> isn't a certified release.  I think that may be because our "product" is
>>> just source code, and folks shouldn't have to navigate through tags to
>> get
>>> the latest.
>>>
>>> I'm not sure I want to involve Git.  The link someone posted seems to
>> just
>>> suggest that you branch downward from trunk, which is what I'm
>> suggesting.
>>> However, I did like some of the naming scheme.
>>>
>>> So to revise a bit:  trunk would always be the latest released version,
>>> staging would be the place we ready the next released version.
>>> Develop would be the place short term fixes would go.
>>>
>>> The reason I am suggesting a fourth sandbox branch for longer term work
>> is
>>> that I think some folks are planning to do some serious refactoring which
>>> could impede the progress of short term fixes if refactoring happens in
>> the
>>> base classes.
>>>
>>> Me, I'd rather start over than re-factor, but that's a thread for another
>>> day.
>>>
>>> On 1/4/12 9:52 PM, "Jonathan Campos"  wrote:
>>>
>>>> As someone that has worked with an Apache like project before I can say
>>>> that the sandbox approach is very very help and would prefer to keep
>> it.
>>>> Branches are meant to go back into the trunk eventually, however the
>>>> sandbox may never go into the trunk and have various crazy changes.
>>>>
>>>> It's been helpful to me before.
>>>> On Jan 4, 2012 11:33 PM, "Nicholas Kwiatkowski"  wrote:
>>>>
>>>>> I would have to agree with Jeffery.  Almost all of the projects I've
>>> seen
>>>>> that use SVN are organized in a Trunk/Branch/Tag method.  I don't see
>>> any
>>>>> reason for us not to mimic the same.
>>>>>
>>>>> I also think that long-term 'projects' and short-term be given the
>> same
>>>>> treatment.  Each gets its own branch, and when completed (or when it
>> is
>>>>> stable enough to be brought into the main trunk) and voted on, it is
>>> merged
>>>>> into the main trunk.  When we are ready for a release (4.7, 5.0, etc),
>>> the
>>>>> trunk is tagged with that version number and life goes on.
>>>>>
>>>>> I've not worked on any projects quite this large before, but for just
>>> about
>>>>> every project I have worked on some variation of this method seems to
>>> have
>>>>> worked pretty well.  What is nice about it to is when working on a
>>> feature,
>>>>> you really only have to concern yourself with your branch, and not
>> about
>>>>> progressing it through multiple multiple branches and merging it
>>> multiple
>>>>> times.
>>>>>
>>>>>
>>>>> -Nick Kwiatkowski
>>>>>
>>>>>   Telecom Systems Engineer, Video and Voice Systems
>>>>>
>>>>>   Michigan State University Telecommunications Systems Department
>>>>>
>>>>>
>>>>>
>>>>>   Adjunct Professor within the Telecommunications, Information Studies
>>> and
>>>>> Media Department at Michigan State University
>>>>>
>>>>>
>>>>>
>>>>>   (t) 517-432-2528        (f) 517-353-6633       (h) 517-853-9050
>>>>>
>>>>> From: Jeffry Houser
>>>>> To: flex-dev@incubator.apache.org
>>>>> Cc:
>>>>> Date: Wed, 04 Jan 2012 20:56:47 -0500
>>>>> 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.
>>>>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>>


-- 
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