Nice Shaz, but I was hoping it was a github style network visualization that included a few versions worth of merges. Who wants to draw that?
On Thu, Jan 24, 2013 at 2:05 PM, Shazron <[email protected]> wrote: > Inline image got mangled, here it is linked: http://cl.ly/MOrD > > > On Thu, Jan 24, 2013 at 1:39 PM, Shazron <[email protected]> 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 <[email protected]>wrote: >> >>> Nice! even simpler. :) >>> >>> >>> On Thu, Jan 24, 2013 at 3:44 PM, Jesse <[email protected]> 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 <[email protected] >>> > >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 < >>> [email protected] >>> > > >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 <[email protected]> >>> > wrote: >>> > > > >>> > > > > On Thu, Jan 24, 2013 at 11:09 AM, Braden Shepherdson < >>> > > > [email protected] >>> > > > > >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 < >>> > > > > [email protected] >>> > > > > > >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 < >>> [email protected]> >>> > > > wrote: >>> > > > > > > >>> > > > > > > On Wed, Jan 23, 2013 at 4:58 PM, Michael Brooks < >>> > > > > > [email protected] >>> > > > > > > >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 <[email protected] >>> > >>> > > wrote: >>> > > > > > > > >>> > > > > > > >> I'm liking it. Start in 2.5? >>> > > > > > > >> >>> > > > > > > >> On Wed, Jan 23, 2013 at 1:19 PM, Filip Maj <[email protected] >>> > >>> > > 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" < >>> [email protected]> >>> > > > 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 >>> > > > > > > >>>> <[email protected]>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 < >>> > > > > > > > [email protected] >>> > > > > > > >>>>>> 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 < >>> > > > > > > > [email protected]> >>> > > > > > > >>>>>> 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 < >>> > > > > > > > [email protected] >>> > > > > > > >>> >>> > > > > > > >>>>>> 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 >>> > >>> >> >> > -- @purplecabbage risingj.com
