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:flexcapaci...@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.develo...@gmail.com (mailto:omarg.develo...@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
