On 8/14/12 7:51 AM, "Omar Gonzalez" <omarg.develo...@gmail.com> wrote:
>>
> Very simple: Publish feature branch to remote repo, send an email to
> flex-dev and say X feature is ready to discuss/dissect/merge to Flex.Next.
> Can also put a STATUS file in the feature branch. Isn't that easy enough?
I can see how GBM can work for a smaller team, but for me, I can't imagine
having to download and build 40 different committer's feature branches in
order to examine their work in order to help guarantee the stability of the
"develop" branch. I was expecting the "develop" branch to contain some
stuff that wasn't quite baked but at least didn't break the build. Then new
stuff would be shoved in front of me. But that would mean you might need to
filter more of it out before releasing.
>
>>
>> I would love to believe that we can fully verify something that is in a
>> branch before it gets checked in, but I just don't think it will happen.
>> Folks will need to have their work get some scenario testing and checking
>> in
>> stuff into "develop" that doesn't break anything but may not be complete is
>> to me the easiest option. I believe we will get more done by taking time
>> to
>> cherry pick at release time rather than trying to manage all of these
>> feature branches and then find they need more baking when finally merged
>> into "develop" and put under real world use.
>
>
> If u think that's easier then that's cool, I know I will never volunteer
> time to this project to try and 'cherry pick' stuff from a bunch of devs
> that may or may not still be around for you to ask questions about their
> work. Good luck with that.
>
> -Omar
That's fine. If you want to cut a release from the head, you will have to
deal with stuff that isn't quite ready to go, or we will have to be much
more careful about what goes in "develop" than I expected.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
