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 aharui@adobe.com designates
 64.18.1.27 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Mon, 13 Aug 2012 15:43:08 -0700
Subject: Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Thread-Topic: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Thread-Index: Ac15oVE87KSObCMaTrC9QkxlujoQEAAA7Egc
Message-ID: <CC4ED10C.446FD%aharui@adobe.com>
In-Reply-To: <3F9B848F-C9E7-458C-8A7A-11A07EF92CAD@comcast.net>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 8/13/12 3:15 PM, "Dave Fisher" <dave2wave@comcast.net> wrote:

>=20
> On Aug 13, 2012, at 2:52 PM, Alex Harui wrote:
>=20
>>=20
>>=20
>>>=20
>>> Really what is the worst that can happen if someone plays in trunk and =
makes
>>> a
>>> mistake?
>>>=20
>>> Regards,
>>> Dave
>>>=20
>> For me, I don't like the psychology of reverting someone's changes, or e=
ven
>> my own.  It feels like going backward.  If the only public copy of some =
work
>> goes in trunk and then gets removed from the release branch, there is al=
ways
>> a chance that you'll mess up the re-integration.  Yes, it is always in t=
he
>> history to be fished out, but I'd rather avoid that.
>=20
> I am thinking about the psychology of working on a change and getting it =
all
> working in "unstable" and then waiting to see if the RM or PPMC or who ex=
actly
> decides it is good enough to be in "stable" trunk. If I'm a committer the=
n I
> should be trusted to not screw it up in the first place.
We had lots of good developers on Flex, but lots of stuff got checked in an=
d
needed fixing later.  In my mind, the community would have a discussion
about what goes in the release.  Folks might say, "hey, feature X still has
a dozen open bugs" or, "I think feature Y is ready.  I've been using it a
lot lately."  I trust release managers to be eager to ship contributions bu=
t
be cautious enough to ensure high quality.
>=20
> If the project thinks it is near release then the group ought to work in =
not
> making unstable changes to trunk. We are all grown ups here aren't we?
I was under the impression that folks would be contributing all kinds of
stuff and at some point, someone would say "hey, let's release this stuff"
and start on the release process without too much advanced warning.  Becaus=
e
I have no idea what day we're going to decide to cut a release, I might hav=
e
just checked in new component like, say, a chart component that doesn't yet
handle labels for wedges that are too thin.  That wouldn't be ready for
production, but ready for more adventurous folks to play with.
>=20
> In the 3-Tier scheme how many buildbots and test rigs are required vs. th=
e
> work in trunk method?
One CI server for trunk and one for "develop".  In either scheme if you cut
a branch I guess you have to add buildbots for them as well?
>=20

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