On Tue, Aug 14, 2012 at 7:58 AM, Greg Reddin wrote:
> On Tue, Aug 14, 2012 at 9:53 AM, Omar Gonzalez
> wrote:
> > It sounds like hell to me.
>
> I don't see the hell in it -- at least I don't see the hell that would
> be avoided under a distributed SCM. How would that use case play out
> in git?
On 14 August 2012 20:37, Om wrote:
> > > Alex but couldn't we simply make "[VOTE]/[DISCUSS] - [MERGE]" mandatory
> > > once we want to merge something to Develop branch?
> > >
> > > João Fernandes
> > Yes, but in order to vote, I have to get your branch and build it and
> test
> > it in order to
> > Alex but couldn't we simply make "[VOTE]/[DISCUSS] - [MERGE]" mandatory
> > once we want to merge something to Develop branch?
> >
> > João Fernandes
> Yes, but in order to vote, I have to get your branch and build it and test
> it in order to vote. 40 committers, 40 branches at minimum. I'd
Alex but probably there won't be 1 branch / dev, multiple devs will
probably focus on the same branch.
Also, I think it's better to veto before committing to develop no?
I would like to replace [DISCUSSION] by [PROPOSAL], so if anyone developed
/ fixed stuff in their branch, they would launch a [P
On 8/14/12 11:45 AM, "João Fernandes"
wrote:
> Alex but couldn't we simply make "[VOTE]/[DISCUSS] - [MERGE]" mandatory
> once we want to merge something to Develop branch?
>
> João Fernandes
Yes, but in order to vote, I have to get your branch and build it and test
it in order to vote. 40 co
Alex but couldn't we simply make "[VOTE]/[DISCUSS] - [MERGE]" mandatory
once we want to merge something to Develop branch?
João Fernandes
On 8/14/12 7:51 AM, "Omar Gonzalez" 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 w
On Tuesday, August 14, 2012, Greg Reddin wrote:
> On Tue, Aug 14, 2012 at 9:53 AM, Omar Gonzalez
> > wrote:
> > It sounds like hell to me.
>
> I don't see the hell in it -- at least I don't see the hell that would
> be avoided under a distributed SCM. How would that use case play out
> in git?
>
On Tue, Aug 14, 2012 at 9:53 AM, Omar Gonzalez
wrote:
> It sounds like hell to me.
I don't see the hell in it -- at least I don't see the hell that would
be avoided under a distributed SCM. How would that use case play out
in git?
On Tuesday, August 14, 2012, Greg Reddin wrote:
> On Mon, Aug 13, 2012 at 10:29 PM, Omar Gonzalez
> > wrote:
> > The way I see it, if there are a bunch of developers working in trunk,
> and
> > they happen to leave things unfinished or unstable, then somebody has to
> go
> > through all of that an
On Monday, August 13, 2012, Alex Harui wrote:
>
>
>
> On 8/13/12 10:36 PM, "Omar Gonzalez" >
> 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 ce
On Mon, Aug 13, 2012 at 10:29 PM, Omar Gonzalez
wrote:
> The way I see it, if there are a bunch of developers working in trunk, and
> they happen to leave things unfinished or unstable, then somebody has to go
> through all of that and figure out what is actually ready for a release and
> what is
On 8/13/12 10:36 PM, "Omar Gonzalez" 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 quit
>
> 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.
>
> Th
Hi,
> That would be the 3rd options:
> 7. Git Branching Model (see Description 3) on SVN
> 8. Git Branching Model on SVN now and then on Git (see Note 1)
> 9. Git Branching Model on Git now (see Note 2)
I know my view is different to some others on the list but this is basically
my reasoning re
> About the only way it can be done without cherry picking is the one
> branch/change (but that wasn't put forward as an option)
That would be the 3rd options:
7. Git Branching Model (see Description 3) on SVN
8. Git Branching Model on SVN now and then on Git (see Note 1)
9. Git Branching Model o
Hi,
> Doesn't option 4 exacerbate this problem? How can this be a reason to vote
> 'for' option 4?
Also you can branch as needed with option 4.
Thanks,
Justin
Hi,
> The way I see it, if there are a bunch of developers working in trunk, and
> they happen to leave things unfinished or unstable, then somebody has to go
> through all of that and figure out what is actually ready for a release and
> what is not.
I see that as a concern but I think it's a con
On Mon, Aug 13, 2012 at 8:25 PM, Om wrote:
> On Mon, Aug 13, 2012 at 5:50 PM, Justin Mclean >wrote:
>
> > Hi,
> >
> > - Unsure how it is decided what from develop/trunk goes into a release.
> > IMO this will make releases a lot more work for the release manager and
> > less likely someone will w
19 matches
Mail list logo
