With 2.5 starting, it appears time to poke this thread. - Is the Google doc refreshed with the latest consensus? - If so, should the Google doc be transferred to a wiki page? - Have the necessary branches been created? - Are we all in the boat, and understand how to row this beast?
-- Marcel Kinard On Jan 24, 2013, at 5:14 PM, Jesse <purplecabb...@gmail.com> wrote: > 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 <shaz...@gmail.com> wrote: > >> 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 >>>>> >>>> >>> >>> >> > > > -- > @purplecabbage > risingj.com
