Inline image got mangled, here it is linked: http://cl.ly/MOrD
On Thu, Jan 24, 2013 at 1:39 PM, Shazron <shaz...@gmail.com> wrote:
> Thanks for the pseudocode Andrew, seems simpler to understand ;) Jesse's
> re-factor makes it even easier. Here's my contrib for those more visually
> inclined:
>
>
> [image: Inline image 2]
>
>
> On Thu, Jan 24, 2013 at 1:29 PM, Andrew Grieve <agri...@chromium.org>wrote:
>
>> Nice! even simpler. :)
>>
>>
>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <purplecabb...@gmail.com> wrote:
>>
>> > Thanks for clarifying Andrew. et al, I guess I was mis-understanding
>> some
>> > of the earlier discussion around naming stuff.
>> >
>> > So everything is going to master all the time, and we only care about
>> > 'next' if we are inReleaseMode and it is a bug fix?
>> >
>> > if(inReleaseMode && isBugFix) {
>> > commitToBranch('next');
>> > mergeBranch('next').into('master');
>> > }
>> > else {
>> > commitToBranch('master');
>> > }
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Jan 24, 2013 at 12:29 PM, Andrew Grieve <agri...@chromium.org
>> > >wrote:
>> >
>> > > Just to clarify - there should be *no* using of the git cherry-picking
>> > > command, only git merge.
>> > >
>> > > Jesse - not sure what you're referring to with "branch must be named
>> x".
>> > > The latest revision of the proposal has only two branches: master and
>> > next.
>> > > Do you mean you don't like the name "next"?
>> > >
>> > > Maybe the proposal will seem simpler if put in the form of code :)
>> > >
>> > > if (!inReleaseMode) {
>> > > commitToBranch('master');
>> > > } else {
>> > > if (isBugFix) {
>> > > commitToBranch('next');
>> > > mergeBranch('next').into('master');
>> > > } else {
>> > > commitToBranch('master');
>> > > }
>> > > }
>> > >
>> > >
>> > > On Thu, Jan 24, 2013 at 3:06 PM, Braden Shepherdson <
>> bra...@chromium.org
>> > > >wrote:
>> > >
>> > > > Most of the time the flow will be unchanged: push to master. Tagging
>> > > things
>> > > > we already know how to do; that doesn't change.
>> > > >
>> > > > The only new flow for most people is cherrypicking bug fixes from
>> > master
>> > > to
>> > > > next, which we can give examples of. Plus that could remain the
>> > > > responsibility of the main platform maintainers, who are doing the
>> > > tagging.
>> > > >
>> > > > Braden
>> > > >
>> > > >
>> > > > On Thu, Jan 24, 2013 at 2:56 PM, Jesse <purplecabb...@gmail.com>
>> > wrote:
>> > > >
>> > > > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson <
>> > > > bra...@chromium.org
>> > > > > >wrote:
>> > > > >
>> > > > > > The founding goal we're trying to accomplish here is that we
>> don't
>> > > want
>> > > > > > everyone sitting on changes to be in the next version while we
>> use
>> > > > master
>> > > > > > to prep a release.
>> > > > > >
>> > > > > > I don't think having one branch for prepping the release and
>> > another
>> > > > for
>> > > > > > main development is a lot of bureaucracy.
>> > > > > >
>> > > > >
>> > > > > It is not, the 'branch must be named x' is mainly where I have
>> > > concerns.
>> > > > > Really I just want things simple.
>> > > > >
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Jan 24, 2013 at 1:57 PM, Jesse MacFadyen <
>> > > > > purplecabb...@gmail.com
>> > > > > > >wrote:
>> > > > > >
>> > > > > > > I have been quietly listening on this thread, but thought I
>> > should
>> > > at
>> > > > > > > least share my opinion.
>> > > > > > >
>> > > > > > > I don't think adding contribution rules helps anyone. Git is
>> > > > > > > complicated enough as it is, and this just all seems like
>> > > > bureaucracy.
>> > > > > > >
>> > > > > > > I think master should always contain the latest stable code,
>> and
>> > be
>> > > > > > > periodically tagged with rc's and versions.
>> > > > > > > All work should be done in personal forks and feature
>> branches.
>> > > > > > > If the latest tag of master is an rc, then we should only be
>> > > merging
>> > > > > > > bugfixes, until the release.
>> > > > > > > Immediately after tagging a version we decide which feature
>> > > branches
>> > > > > > > and pull requests to pull in, and go for it.
>> > > > > > >
>> > > > > > > I don't think this is much different from what we have, but I
>> > think
>> > > > > > > that is good.
>> > > > > > > The suggestions thus far, while interesting, don't increase
>> our
>> > > > > > > velocity in my opinion. Also, I can also pretty much guaranty
>> > I'll
>> > > > > > > screw it up for the next 3-4 versions. ( because I'm dumb )
>> > > > > > >
>> > > > > > > Cheers,
>> > > > > > > Jesse
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On 2013-01-24, at 5:53 AM, Andrew Grieve <
>> agri...@chromium.org>
>> > > > wrote:
>> > > > > > >
>> > > > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks <
>> > > > > > mich...@michaelbrooks.ca
>> > > > > > > >wrote:
>> > > > > > >
>> > > > > > > > Before we move forward, I have a few questions about the "no
>> > > > master"
>> > > > > > > > approach.
>> > > > > > > >
>> > > > > > > > There is *no* master branch, so that community-driven pull
>> > > requests
>> > > > > > will
>> > > > > > > be
>> > > > > > > >> forced to think about which branch to request against.
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > - Andrew, can you cite other projects that do not use a
>> master
>> > > > > branch?
>> > > > > > > This project is my first time using git / github, so I don't
>> have
>> > > > much
>> > > > > to
>> > > > > > > draw from. I was going off of others' suggestions on this
>> thread
>> > > > when I
>> > > > > > > proposed the names.
>> > > > > > >
>> > > > > > >
>> > > > > > > > - On Github, you must have a default branch. If not master,
>> it
>> > > must
>> > > > > be
>> > > > > > > > something else. So, users are not forced to think about the
>> > > branch
>> > > > to
>> > > > > > > send
>> > > > > > > > a pull request again... they will likely just use the
>> default.
>> > > > > > >
>> > > > > > > Hmm, good point. The goal is to get people downloading Cordova
>> > for
>> > > > use
>> > > > > to
>> > > > > > > end up with Stable, and for developers to send pull requests
>> > > against
>> > > > > dev.
>> > > > > > > With a forced default branch, I don't think we can accomplish
>> > this.
>> > > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > - Why is the "stable" branch not just "master"?
>> > > > > > >
>> > > > > > > My thinking was that it's not obvious whether Master ==
>> bleeding
>> > > > edge,
>> > > > > or
>> > > > > > > Master == Stable version. Using the names "dev" and "stable"
>> > makes
>> > > > it a
>> > > > > > bit
>> > > > > > > clear.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > So... If github forces us to have a default branch, I'm
>> thinking
>> > > that
>> > > > > > > having users send pull requests against "dev" is more valuable
>> > than
>> > > > > > having
>> > > > > > > people download the latest "stable" by default. If people are
>> > > pulling
>> > > > > > code
>> > > > > > > from github rather than from our release .zip files, then it's
>> > > likely
>> > > > > > they
>> > > > > > > want to hack on it anyways, or that they want the dev version
>> to
>> > > see
>> > > > if
>> > > > > > > bugs are fixed.
>> > > > > > >
>> > > > > > > Soo.... Here's version #3! If anyone can think of how to keep
>> the
>> > > > three
>> > > > > > > branches while addressing being forced to have a default
>> branch,
>> > > feel
>> > > > > > free
>> > > > > > > to speak up! :)
>> > > > > > >
>> > > > > > >
>> > > > > > > Cordova repositories have two main branches:
>> > > > > > > 1. master
>> > > > > > > 2. next
>> > > > > > >
>> > > > > > > Topic branches exist for collaborating on features, or for
>> > > > code-review
>> > > > > > > purposes.
>> > > > > > >
>> > > > > > > Cordova uses tags to label releases.
>> > > > > > > - Each release candidate has a tag. e.g. "2.2.0rc1"
>> > > > > > > - Each release has a tag. e.g. "2.2.0"
>> > > > > > > - The "latest" tag points to the last stable release (this
>> > follows
>> > > > npm
>> > > > > > > conventions)
>> > > > > > >
>> > > > > > >
>> > > > > > > 1. The "next" branch.
>> > > > > > > - This branch is used only when in the process of doing a
>> > release.
>> > > > > > > - All tags are created from this branch.
>> > > > > > > - All release-candidate bug-fixes are done on this branch.
>> > > > > > >
>> > > > > > > 2. The "master" branch.
>> > > > > > > - When not in the release-process, all commits are made here
>> > > > > > > - When in the release-process, all non-bugfix commits are
>> made
>> > > here
>> > > > > > > - This is where topic-branches are merged into.
>> > > > > > >
>> > > > > > > Cutting a release:
>> > > > > > > 1. git checkout next && git merge --ff-only master
>> > > > > > > 2. Test test test!
>> > > > > > > 3. Fix bugs by committing them directly to "next" and then
>> doing
>> > a
>> > > > > non-ff
>> > > > > > > merge of next into master
>> > > > > > > 4. Tag release candidate
>> > > > > > > 5. Repeat steps 2-4 as necessary
>> > > > > > > 6. Tag the release (both by version and by updating the
>> "latest"
>> > > tag)
>> > > > > > > 7. Create distribution .zip file
>> > > > > > > 8. Test one last time using the dist files
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > > Michael
>> > > > > > > >
>> > > > > > > > On Wed, Jan 23, 2013 at 11:25 AM, Brian LeRoux <b...@brian.io>
>> > > wrote:
>> > > > > > > >
>> > > > > > > >> I'm liking it. Start in 2.5?
>> > > > > > > >>
>> > > > > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <f...@adobe.com>
>> > > wrote:
>> > > > > > > >>> Looks great Andrew!
>> > > > > > > >>>
>> > > > > > > >>> If everyone's on board, how are we going to test run this?
>> > > Flip a
>> > > > > > > > switch
>> > > > > > > >>> at a certain point, give it a shot with one repo for one
>> RC?
>> > > > > > > >>>
>> > > > > > > >>> On 1/22/13 12:29 PM, "Andrew Grieve" <
>> agri...@chromium.org>
>> > > > wrote:
>> > > > > > > >>>
>> > > > > > > >>>> Braden, you're right. I've now done some local playing
>> > around
>> > > in
>> > > > > > git,
>> > > > > > > > and
>> > > > > > > >>>> have an updated proposal that uses merges instead of
>> > deleting
>> > > > > > > branches.
>> > > > > > > >>>> PTAL:
>> > > > > > > >>>>
>> > > > > > > >>>> Cordova repositories have three main branches:
>> > > > > > > >>>> 1. stable
>> > > > > > > >>>> 2. next
>> > > > > > > >>>> 3. dev
>> > > > > > > >>>>
>> > > > > > > >>>> Topic branches also exist for collaborating on features,
>> or
>> > > for
>> > > > > > > >>>> code-review
>> > > > > > > >>>> purposes.
>> > > > > > > >>>>
>> > > > > > > >>>> There is *no* master branch, so that community-driven
>> pull
>> > > > > requests
>> > > > > > > > will
>> > > > > > > >>>> be
>> > > > > > > >>>> forced to think about which branch to request against.
>> > > > > > > >>>>
>> > > > > > > >>>> 1. The "stable" branch.
>> > > > > > > >>>> - Sits at the latest stable release of cordova
>> > > > > > > >>>> - This changes only when doing fast-forward merges from
>> > "next"
>> > > > > > > >>>>
>> > > > > > > >>>> 2. The "next" branch.
>> > > > > > > >>>> - This branch is used only when in the process of doing a
>> > > > release.
>> > > > > > > >>>> - All tags (both stable and RC) are done on this branch.
>> > > > > > > >>>> - All release-candidate bug-fixes are done on this
>> branch.
>> > > > > > > >>>>
>> > > > > > > >>>> 3. The "dev" branch.
>> > > > > > > >>>> - This is where non-release-candidate commits are done
>> > > > > > > >>>> - This is where topic-branches are merged into.
>> > > > > > > >>>>
>> > > > > > > >>>> Cutting a release:
>> > > > > > > >>>> 1. git checkout next && git merge --ff-only dev
>> > > > > > > >>>> 2. Test test test!
>> > > > > > > >>>> 3. Fix bugs by committing them directly to "next" and
>> then
>> > > > doing a
>> > > > > > > > non-ff
>> > > > > > > >>>> merge of next into dev
>> > > > > > > >>>> 4. Tag release candidate
>> > > > > > > >>>> 5. Repeat steps 2-4 as necessary
>> > > > > > > >>>> 6. Tag the release
>> > > > > > > >>>> 7. Create distribution .zip file
>> > > > > > > >>>> 8. Test one last time using the dist files
>> > > > > > > >>>> 9. git checkout stable && git merge --ff-only next
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>> On Tue, Jan 22, 2013 at 1:59 PM, Braden Shepherdson
>> > > > > > > >>>> <bra...@chromium.org>wrote:
>> > > > > > > >>>>
>> > > > > > > >>>>> I think deleting and recreating branches with the same
>> name
>> > > can
>> > > > > > cause
>> > > > > > > >>>>> badness in git[1] because of remotes. It's not really
>> the
>> > > same
>> > > > > > branch
>> > > > > > > >> in
>> > > > > > > >>>>> terms of commits, and git thinks that your old stable
>> and
>> > the
>> > > > new
>> > > > > > > >> stable
>> > > > > > > >>>>> differ by all of each of their commits. Tags can be
>> moved
>> > > > > > > > arbitrarily,
>> > > > > > > >>>>> so I
>> > > > > > > >>>>> think stable makes sense as a tag. I'm not sure about
>> how
>> > > best
>> > > > to
>> > > > > > > >> handle
>> > > > > > > >>>>> next.
>> > > > > > > >>>>>
>> > > > > > > >>>>> [1]
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://stackoverflow.com/questions/11844581/git-delete-and-recreate-branc
>> > > > > > > >>>>> h
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>> On Tue, Jan 22, 2013 at 11:31 AM, Andrew Grieve <
>> > > > > > > > agri...@chromium.org
>> > > > > > > >>>>>> wrote:
>> > > > > > > >>>>>
>> > > > > > > >>>>>> Michal's attending hackathons for the week, and I'm not
>> > sure
>> > > > we
>> > > > > > > > need
>> > > > > > > >>>>> to
>> > > > > > > >>>>> do
>> > > > > > > >>>>>> a hang-out for this, as I think we really are quite
>> close
>> > to
>> > > > > > > >> resolving
>> > > > > > > >>>>>> this. I'd really like to resolve this ASAP so that we
>> > don't
>> > > > need
>> > > > > > to
>> > > > > > > >>>>> have
>> > > > > > > >>>>> a
>> > > > > > > >>>>>> code-freeze for this release.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> Here's a proposal:
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> Cordova repositories have three main branches:
>> > > > > > > >>>>>> 1. stable
>> > > > > > > >>>>>> 2. next
>> > > > > > > >>>>>> 3. dev
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> Topic branches also exist for collaborating on
>> features,
>> > or
>> > > > for
>> > > > > > > >>>>> code-review
>> > > > > > > >>>>>> purposes.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> There is *no* master branch, so that community-driven
>> pull
>> > > > > > requests
>> > > > > > > >>>>> will
>> > > > > > > >>>>> be
>> > > > > > > >>>>>> forced to think about which branch to request against.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> 1. The "stable" branch.
>> > > > > > > >>>>>> - Sits at the latest stable release of cordova
>> > > > > > > >>>>>> - No one ever commits to the "stable" branch. It exists
>> > only
>> > > > as
>> > > > > a
>> > > > > > > >>>>>> short-cut for checking out the latest stable tag.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> 2. The "next" branch.
>> > > > > > > >>>>>> - This branch exists only when in the process of doing
>> a
>> > > > > release.
>> > > > > > > >>>>>> - All tags (both stable and RC) are done on this
>> branch.
>> > > > > > > >>>>>> - When a stable tag is done:
>> > > > > > > >>>>>> - The existing "stable" branch is deleted
>> > > > > > > >>>>>> - A new "stable" branch is created from "next".
>> > > > > > > >>>>>> - The "next" branch is deleted.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> 3. The "dev" branch.
>> > > > > > > >>>>>> - This is where all commits are done
>> > > > > > > >>>>>> - This is where topic-branches are merged into.
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> Cutting a release:
>> > > > > > > >>>>>> 1. Create "next" from the HEAD of "dev"
>> > > > > > > >>>>>> 2. Test test test!
>> > > > > > > >>>>>> 3. Fix bugs by committing them to "dev" and then
>> > > > cherry-picking
>> > > > > > > > them
>> > > > > > > >>>>> into
>> > > > > > > >>>>>> "next"
>> > > > > > > >>>>>> 4. Tag release candidate
>> > > > > > > >>>>>> 5. Repeat steps 2-4 as necessary
>> > > > > > > >>>>>> 6. Tag the release
>> > > > > > > >>>>>> 7. Create distribution .zip file
>> > > > > > > >>>>>> 8. Test one last time using the dist files
>> > > > > > > >>>>>> 9. Delete "stable"
>> > > > > > > >>>>>> 10. Create a new "stable" by branching from the HEAD of
>> > > "next"
>> > > > > > > >>>>>> 11. Delete the "next" branch
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>> On Wed, Jan 16, 2013 at 10:34 AM, Michal Mocny <
>> > > > > > > > mmo...@chromium.org>
>> > > > > > > >>>>>> wrote:
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>> Just going to throw out one of my personal
>> requirements
>> > for
>> > > > > > > >> whatever
>> > > > > > > >>>>>>> proposal we come up with, so it doesn't get lost:
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>> * Feature branches are great for feature work and/or
>> > large
>> > > > > > > > sweeping
>> > > > > > > >>>>>>> changes, as are JIRA bugs for tracking them, but
>> cordova
>> > > has
>> > > > > many
>> > > > > > > >>>>> many
>> > > > > > > >>>>>>> trivial issues that could be fixed with "drive-by"
>> > patches
>> > > > that
>> > > > > > > >>>>> require
>> > > > > > > >>>>>> as
>> > > > > > > >>>>>>> little friction to commit as possible.
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>> On Tue, Jan 15, 2013 at 3:05 PM, Marcel Kinard <
>> > > > > > > > cmarc...@gmail.com
>> > > > > > > >>>
>> > > > > > > >>>>>> wrote:
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>> How about if there is a specific straw man proposal
>> at
>> > the
>> > > > > > > >>>>> beginning
>> > > > > > > >>>>> of
>> > > > > > > >>>>>>>> the face-time? Then the folks that are in agreement
>> > won't
>> > > > need
>> > > > > > > > to
>> > > > > > > >>>>> say
>> > > > > > > >>>>>>>> anything ;-)
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> Seriously, making adjustments to something tangible
>> is
>> > > > easier
>> > > > > > > >> than
>> > > > > > > >>>>>>>> instantiating it from scratch. A volunteer for a very
>> > > simple
>> > > > > > > >>>>> writeup
>> > > > > > > >>>>> on
>> > > > > > > >>>>>>> the
>> > > > > > > >>>>>>>> wiki?
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> -- Marcel Kinard
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> On 1/14/2013 10:06 PM, Michal Mocny wrote:
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>> Okay gentlemen, I think there have been countless
>> good
>> > > > points
>> > > > > > > >>>>> made
>> > > > > > > >>>>>> from
>> > > > > > > >>>>>>>>> all
>> > > > > > > >>>>>>>>> parties, but also some bike-shedding.
>> > > > > > > >>>>>>>>>
>> > > > > > > >>>>>>>>> Perhaps it is time to schedule some face-time to
>> better
>> > > > > > > >>>>> articulate
>> > > > > > > >>>>>> some
>> > > > > > > >>>>>>> of
>> > > > > > > >>>>>>>>> the finer points, and to help come to some
>> consensus?
>> > > > > > > >>>>>>>>>
>> > > > > > > >>>>>>>>> -Michal
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > @purplecabbage
>> > > > > risingj.com
>> > > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > @purplecabbage
>> > risingj.com
>> >
>>
>
>
