Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A118D9CA8 for ; Tue, 14 Aug 2012 00:01:08 +0000 (UTC) Received: (qmail 83866 invoked by uid 500); 14 Aug 2012 00:01:07 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 83832 invoked by uid 500); 14 Aug 2012 00:01:07 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 83824 invoked by uid 99); 14 Aug 2012 00:01:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Aug 2012 00:01:07 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of omarg.developer@gmail.com designates 209.85.220.175 as permitted sender) Received: from [209.85.220.175] (HELO mail-vc0-f175.google.com) (209.85.220.175) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Aug 2012 00:01:01 +0000 Received: by vcbfy27 with SMTP id fy27so3955802vcb.6 for ; Mon, 13 Aug 2012 17:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zJ898ClpvuKQW0IXuCTjlsMZDaJH9JSMpkMbImZFksU=; b=YtqWeZ0YXQqMQJMHyJq1IKwVQPhmwaOBDEAHB4pHcwF/bNn8018sXj4gku8iya3w0V yzQCcv57vptuyl0U0O0McHaHlAsMl8h2PrgnR56YQMjU6vVUIVmC6JX+hV+7lkemYnn6 w8JOHVhgvHyU8URpZB+P47nu+6jUwv+jXi1fiwGGAKUJlR1PuRX3ErGwXQSaMjmq6Ayg l+7HvObp7l3flHvDV/sGDPNPJF3TYvzBgslARRvrNHfrhgqJdacYmLm1dYkcbyHRUD/Z Gvycr8601vzIiwYV/Xhn2HKFSwHlRPiomIJTjt7dMIuo8gJgtczVOJOMj9cjkARduiQJ bRvg== MIME-Version: 1.0 Received: by 10.220.148.210 with SMTP id q18mr9344092vcv.6.1344902440684; Mon, 13 Aug 2012 17:00:40 -0700 (PDT) Received: by 10.58.249.139 with HTTP; Mon, 13 Aug 2012 17:00:40 -0700 (PDT) In-Reply-To: References: <391032D7-4A8C-40B6-875A-E921DD627125@comcast.net> Date: Mon, 13 Aug 2012 17:00:40 -0700 Message-ID: Subject: Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM From: Omar Gonzalez To: flex-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=f46d043be04e3c0a8104c72e8030 X-Virus-Checked: Checked by ClamAV on apache.org --f46d043be04e3c0a8104c72e8030 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 13, 2012 at 2:38 PM, Dave Fisher wrote: > > On Aug 13, 2012, at 1:43 PM, Omar Gonzalez wrote: > > > On Mon, Aug 13, 2012 at 1:39 PM, Dave Fisher > wrote: > > > >> My opinion/vote is (4) - no guts, no glory - work in trunk and learn to > >> co-operate. > >> > >> The vote is more about the Classic model than it is about Git vs. SVN. > >> > >> To me svn tag == git branch. > >> > >> Regards, > >> Dave > > > > > > People that use Git a lot would strongly disagree with "svn tag == git > > branch". For starters, SVN tags are supposed to not ever be edited, and > Git > > branches are used for almost all new code addition/changes in the "nvie" > > model, so they're from from ==. > > I'm more thinking this from what happens in the central repository and > what gets marked up in the history from a few comparisons I've done. > > When you branch in git you are marking where you are in the main repos, > correct? If you never push it back the central repos never really cares > about your branch, correct? So to the repository a branch is like a tag. > Branching and tagging are the same thing in SVN, the only real difference is that it is understood that when you 'tag' something you are not meant to check out the tag and make commits to it. The minute you commit to a tag it become a branch. The distinction is not technical, its a convention. > > My opinion is that git is just putting off the work of integrating diverse > changes into a single release. I feel the same about the 3-Tier plan. It is > just putting ALL the work of deciding what is in a release to a Release > Manager. > I don't know why you think its "putting it off", what its doing is isolating work into branches that can be merged into a dev (next release) branch when the time is appropriate (whenever that is, probably once the branch has been discussed, fixed up, etc). > > Really the Apache Way is for the Committers and the PPMC to share this > responsibility. As this podling must know, you never, ever know when > someone will exit. > > But go ahead and go the way you want, it is up to you all. > > Really what is the worst that can happen if someone plays in trunk and > makes a mistake? > Chaos that would affect all committers, which could be avoided by utilizing branches and isolating work so that it is not disruptive to others work. Being that we're all here on a volunteer basis I doubt anyone wants to spend time cleaning up things that others broke because we are all in the same trunk changing code and causing conflicts that could be avoided with some clear workflows for the repository. Just because other projects are OK with chaotic repos doesn't mean we have to be. -omar --f46d043be04e3c0a8104c72e8030--