On Monday, August 13, 2012, Alex Harui wrote: > > > > On 8/13/12 10:36 PM, "Omar Gonzalez" <omarg.develo...@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
