incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Dalton <bendal...@gmail.com>
Subject Re: [VOTE] Branching Strategy and SCM
Date Tue, 14 Aug 2012 12:49:30 GMT
Whatever branching model/scm we use, we need to provide a step-by-step guide (or tool as Mark
suggested) on how to checkout the code, make changes, and submit a patch…

While I get the Apache Mentors' viewpoints on sticking with what works for Apache projects,
I fear we are missing a huge opportunity to have a much more active developer base if we use
Git. Other open source projects thrive with Git because the ease of committing a simple fix
via a pull request from a forked repo. I used SVN for years, but have been much more productive
with git since it's much harder to get yourself into merge hell.

Just my 2 cents.  


On Tuesday, August 14, 2012 at 8:06 AM, Kessler CTR Mark J wrote:

> Just a thought... in the same way the Installer was created and used to make the complications
for the FB setup; could we have a small application to run the commands for people, but provide
a more intuitive gui? That is regardless of the svn/git debate.
>  
>  
>  
> -----Original Message-----
> From: jude [mailto:flexcapacitor@gmail.com]  
> Sent: Tuesday, August 14, 2012 7:57
> To: flex-dev@incubator.apache.org (mailto:flex-dev@incubator.apache.org)
> Subject: Re: [VOTE] Branching Strategy and SCM
>  
> As Omar said, it will be *more* productive for us to use Git going forward.
> The workflow model is already setup
> http://nvie.com/posts/a-successful-git-branching-model/<http://nvie.com/posts/a-successful-git-branching-model/you>.
>  
>  
> The disadvantage, which is small, is that those that don't know it will have to learn
it (maybe a week or two)? Yes we can!
>  
>  
> On Mon, Aug 13, 2012 at 10:14 PM, Omar Gonzalez
> <omarg.developer@gmail.com (mailto:omarg.developer@gmail.com)>wrote:
>  
> > * I think we as a community need to figure out how to work together in
> > > a more centralized environment before we get too decentralized. I  
> > > worry that the desire to move to git is in many ways a desire to  
> > > "get around" the problem of not being able to define a branching  
> > > strategy by adopting one in which each developer can have his or her  
> > > own branching strategy. My concern is that this will lead to us not  
> > > really working together much.
> > >  
> >  
> >  
> >  
> > That couldn't be further from what is being proposed by using the Git  
> > Branching model. I don't see how desiring to move to Git plus the most  
> > well defined branching model that has been proposed is promoting to  
> > work with "his or her own branching strategy". No one has ever  
> > proposed that we should move to Git and work however each developer  
> > wants, quite the contrary, we have proposed to work using a VERY  
> > detailed workflow of Git branching.
> >  
> > *In contrast, the other strategies are described in ways like: * *"In  
> > this model, there is a "trunk" branch that is almost always*  
> > *production-ready, a "develop" branch, and various other branches on  
> > whiteboards and elsewhere on an as-needed basis."*
> >  
> > Could this be any less specific? How is this promoting to work  
> > together when things need to be "almost always production ready" and  
> > "on an as-needed basis", what are the criterion for these decisions?
> >  
> > If you actually read
> > http://nvie.com/posts/a-successful-git-branching-model/you would see  
> > that the uses and purpose of each of the branches are VERY detailed  
> > with diagrams and detailed workflows. How is this promoting "his or  
> > her own branching strategy"? On the contrary, its the only model that  
> > has been proposed with any kind of ACTUAL detail beyond just saying  
> > "on an as-needed basis".
> >  
> > Anyhow, I think this is my last post on the subject, as they say, you  
> > can lead a horse to water but you can't make them drink it... or also  
> > this horse is dead and beat to death or something like that...
> >  
> > -omar  


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