Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of omarg.developer@gmail.com
 designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAd0WrbLYnzDjJSQyQPNxC-8cyc7zeezY7Hc2QJs0WTRRra9wA@mail.gmail.com>
References: <254f1a76$654d6909$4cb4bdf8$@com>
	<CAAd0WrbLYnzDjJSQyQPNxC-8cyc7zeezY7Hc2QJs0WTRRra9wA@mail.gmail.com>
Date: Thu, 5 Jan 2012 01:48:16 -0800
Message-ID: 
 <CAEFz_vu6aT-oHmW0efM1z4Tjyfk9Uo3WoQNMzO5O8=9CvttXUw@mail.gmail.com>
Subject: Re: So, what should we do first?
From: Omar Gonzalez <omarg.developer@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0015174be312e37bf304b5c4d4c6

--0015174be312e37bf304b5c4d4c6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 cod=
e
> vs someone else. Everyone can quickly go through the various sandboxes an=
d
> 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 foc=
us
> or agreed goal and developing branches in that direction is simple. Not t=
he
> 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 severa=
l
> > technologies and the one thing I'm pretty sure of is that, if not manag=
ed
> > 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 be=
en
> > giving it a lot of thought lately and I've come to some conclusions/ide=
as
> > 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 branc=
h
> > 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 upwar=
ds
> > 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 t=
o
> > 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 numbe=
rs
> > 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 th=
at
> > the trunk should always be the release.  It can never be in a state tha=
t
> > isn't a certified release.  I think that may be because our "product" i=
s
> > 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 whi=
ch
> > 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 anoth=
er
> > day.
> >
> > On 1/4/12 9:52 PM, "Jonathan Campos"  wrote:
> >
> > > As someone that has worked with an Apache like project before I can s=
ay
> > > 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 se=
e
> > 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 jus=
t
> > about
> > >> every project I have worked on some variation of this method seems t=
o
> > 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 Studie=
s
> > 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 publ=
ic
> > Flex
> > >> SVN repo; so I'm not sure the extent of what is in there or how it i=
s
> > >> organized.
> > >>
> > >>  Most projects I've worked on have used a "Trunk/Branch/Tag" approac=
h.
> >  To
> > >> map:
> > >>
> > >> * Released sounds kind of like tags; which is a full snapshot in tim=
e
> > >> 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 th=
e
> > >> 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=B9m 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=B9t fall over immediately can go
> here
> > >>>     -Unstable: Things that are being polished for release can go he=
re
> > >>>     -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 wo=
rk
> > and
> > >>> use JIRA to guide what short-term work I do.
> > >>>
> > >>
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
> >
>

--0015174be312e37bf304b5c4d4c6--