incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: Discuss: Branching Strategy and SCM
Date Tue, 14 Aug 2012 14:51:29 GMT
On Monday, August 13, 2012, Alex Harui wrote:

>
>
>
> On 8/13/12 10:36 PM, "Omar Gonzalez" <omarg.developer@gmail.com<javascript:;>>
> wrote:
>
> >>
> >> Also the vote added this to the above options - "The release manager can
> >> choose to branch from an older revision and cherry-pick or branch from
> the
> >> head and remove/block certain revisions." Which I have concerns about as
> >> it's not quite how I saw the process as described in the URL.
> >>
> >> Thanks,
> >> Justin
> >
> >
> > That's because that's not how its supposed to work in the GBM.
> >
> >  "The release manager can choose to branch from an older revision and
> > cherry-pick or branch from the head and remove/block certain revisions."
> >
> > This is never mentioned in GBM.
> That's correct.  I added it on purpose, because I don't see how folks will
> be able to decide what goes in Flex.Next as there is no product schedule,
> and with volunteers, you never know when you think you have time and be
> wrong.  This is different from dedicated development where you know at
> release planning time who is working on stuff due for the current release
> and who, if anybody, is on a longer term project.
>
>
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?


> If we take the conservative approach of following GBM as written and do not
> check stuff into the develop branch until you are absolutely sure it is
> ready to go, then you will have delayed sharing or made it harder as we
> have
> to keep switching to different branches in order to try others work.


Again, not accurate. Nothing is stopping a dev from publishing a feature
branch during dev so others can collaborate. THAT'S THE WHOLE POINT OF GBM
AN GIT.


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message