get a babycarrier :) although you would then have to type with your arms extended and further away from your screen (external keyboard I suppose)
On Mon, Jul 15, 2013 at 4:26 PM, Andrew Grieve <agri...@chromium.org> wrote: > huzzah! great. > > btw - im still learning to type with a baby in one arm :) > > that command doesnt exist in coho. > > ./cordova-coho/coho repo-update -b 3.0.x -r REPOS > > comes close, but wont change branch if there were no changes. > > > On Mon, Jul 15, 2013 at 7:15 PM, Steven Gill <stevengil...@gmail.com> > wrote: > > > Hey Andrew, > > > > I posted in here before reading the getting organized for 3.0 thread. I > > retract my statement that every plugin needs issues and agree with > plugins > > being tested by platform maintainers before they tag their respective > > platforms. I created one issue to tag all of the plugins once platforms > are > > tagged. > > > > > > On Mon, Jul 15, 2013 at 4:12 PM, Joe Bowser <bows...@gmail.com> wrote: > > > > > So, since we're stuck with coho if we want to get this done this week, > > > how do you get coho to check out a branch of all the plugins? > > > > > > On Mon, Jul 15, 2013 at 4:10 PM, Andrew Grieve <agri...@chromium.org> > > > wrote: > > > > On Mon, Jul 15, 2013 at 5:22 PM, Steven Gill <stevengil...@gmail.com > > > > > wrote: > > > > > > > >> We will need to add issues for tagging plugins. > > > > > > > > What's your reasoning? > > > > > > > > > > > > > > > >> I can create the issue and > > > >> tag the plugins. I figure for now, plugins will use same tagging > > > process as > > > >> other repos. > > > >> > > > > And that process is? > > > > > > > > For the RC - it's trivial to create release branches and an RC tag. > > coho > > > > can do it in bulk. The main question is what criteria should we use > to > > > > determine whether a plugin is ready for tagging? For an RC, we could > > just > > > > tag with whatever's there , but then it's not really adding any > meaning > > > on > > > > top of the release branch existing. I think the thing that separates > > the > > > > release branch from the tag is some testing. > > > > > > > > > > > >> > > > >> > > > >> On Mon, Jul 15, 2013 at 12:02 PM, Filip Maj <f...@adobe.com> wrote: > > > >> > > > >> > Created the issues: https://issues.apache.org/jira/browse/CB-4208 > > > >> > > > > >> > On 7/15/13 11:56 AM, "Joe Bowser" <bows...@gmail.com> wrote: > > > >> > > > > >> > >So, for tagging today, can we get the issues setup and the JS > > tagged > > > >> > >at least? We can somehow muddle through this RC1. > > > >> > > > > > >> > >On Mon, Jul 15, 2013 at 9:48 AM, Brian LeRoux <b...@brian.io> > wrote: > > > >> > >> I'd say we could consider the core plugins as build ephemera > not > > > >> > >> unlike docs or automations. Really cordova-cli is the main > point > > of > > > >> > >> interaction between us and our developer community. > > > >> > >> > > > >> > >> > > > >> > >> On Mon, Jul 15, 2013 at 9:03 AM, Andrew Grieve < > > > agri...@chromium.org> > > > >> > >>wrote: > > > >> > >>> The Apache Way was a part of what I was thinking as well. > > > >> > >>> > > > >> > >>> Also - it occurs to me that we'll have to change our voting > > system > > > >> > >>>when it > > > >> > >>> comes to plugins since each plugin repo should have a +1 from > > each > > > >> > >>>platform > > > >> > >>> maintainer, and can be tagged only once. > > > >> > >>> > > > >> > >>> > > > >> > >>> On Fri, Jul 12, 2013 at 12:53 PM, Joe Bowser < > bows...@gmail.com > > > > > > >> > wrote: > > > >> > >>> > > > >> > >>>> Don't we have to release a zip on an Apache server because of > > > "The > > > >> > >>>> Apache Way"? That's why I thought we had to release > artifacts, > > > not > > > >> > >>>> for people, but for process. > > > >> > >>>> > > > >> > >>>> On Fri, Jul 12, 2013 at 9:31 AM, Brian LeRoux <b...@brian.io> > > > wrote: > > > >> > >>>> > I don't mind this but it seems like a lot of work to > release > > > >> > >>>>artifacts > > > >> > >>>> > for...who? End users we want to encourage to use the > tooling > > > >> golden > > > >> > >>>> > path for creating projects, working w/ plugins, etc. > > > >> > >>>> > > > > >> > >>>> > If anything I'd rather we *only* distribute cordova-cli as > > the > > > >> > >>>> > canonical repo and entry point for usage and treat the rest > > as > > > our > > > >> > >>>> > project build artifacts/ephemera. > > > >> > >>>> > > > > >> > >>>> > Way easier. Way more in tune w/ actual usage. > > > >> > >>>> > > > > >> > >>>> > > > > >> > >>>> > > > > >> > >>>> > On Fri, Jul 12, 2013 at 7:25 AM, Andrew Grieve > > > >> > >>>><agri...@chromium.org> > > > >> > >>>> wrote: > > > >> > >>>> >> Definitely would like to get everything Release / > Versioning > > > >> > >>>>related > > > >> > >>>> >> documented on the wiki. The most complete source right now > > is: > > > >> > >>>> >> http://wiki.apache.org/cordova/CuttingReleases We should > > add > > > >> > >>>>another > > > >> > >>>> page > > > >> > >>>> >> for versioning once we settle on what to do with plugins. > > > >> > >>>> >> > > > >> > >>>> >> Right now only CLI & Plugman are distributed on npm and > are > > > >> > >>>>versioned > > > >> > >>>> >> separately. Nothing else is on npm though, so package.json > > > isn't > > > >> > >>>>used. > > > >> > >>>> >> Instead VERSION files hold the version. > > > >> > >>>> >> > > > >> > >>>> >> I've decided I didn't like my previous proposal of not > > > updating > > > >> > >>>>versions > > > >> > >>>> >> when things don't change because it will make it harder to > > > check > > > >> > >>>>out a > > > >> > >>>> >> version of Cordova. > > > >> > >>>> >> > > > >> > >>>> >> New Proposal: > > > >> > >>>> >> > > > >> > >>>> >> 1. Each Cordova release will include: > > > >> > >>>> >> - A copy of every repo, including all core plugins. > > > >> > >>>> >> > > > >> > >>>> >> 2. Each plugin repo will get a release branch even if the > > code > > > >> > >>>>hasn't > > > >> > >>>> >> changed. > > > >> > >>>> >> > > > >> > >>>> >> 3. Each plugin's version will match the Cordova version > > > >> > >>>> >> > > > >> > >>>> >> 4. Plugins can have separate point releases if they are > > > important > > > >> > >>>> updates > > > >> > >>>> >> to them. These will be in the form of tags along the > release > > > >> > >>>>branch. > > > >> > >>>> >> > > > >> > >>>> >> 5. As soon as release branches are created, we change the > > > VERSION > > > >> > >>>>file > > > >> > >>>> and > > > >> > >>>> >> re-tag master to a -dev version of the next release (e.g. > > > >> > >>>>3.1.0-dev) > > > >> > >>>> >> > > > >> > >>>> >> > > > >> > >>>> >> On Thu, Jul 11, 2013 at 9:05 AM, Carlos Santana > > > >> > >>>><csantan...@gmail.com > > > >> > >>>> >wrote: > > > >> > >>>> >> > > > >> > >>>> >>> Dumb questions > > > >> > >>>> >>> > > > >> > >>>> >>> Does the package.json {version:""} field needs to be > > updated > > > on > > > >> > >>>>every > > > >> > >>>> >>> commit to the repo? > > > >> > >>>> >>> (meaning depending what is the commit, then the major, > > > minor, > > > >> > >>>>patch, > > > >> > >>>> or > > > >> > >>>> >>> extension gets updated) > > > >> > >>>> >>> Does the npm registry support pre-release and build > > metadata > > > >> (i.e. > > > >> > >>>> x.7.z.92 > > > >> > >>>> >>> in 2.9.1-x.7.z.92)? > > > >> > >>>> >>> If this true, Does npm knows to install the latest stable > > > >> > >>>>version, but > > > >> > >>>> user > > > >> > >>>> >>> can request a pre-release by specifying the version that > it > > > >> wants > > > >> > >>>>@2 > > > >> > >>>> >>> .9.1-x.7.z.92 > > > >> > >>>> >>> > > > >> > >>>> >>> > > > >> > >>>> >>> > > > >> > >>>> >>> Refs: > > > >> > >>>> >>> http://semver.org/ > > > >> > >>>> >>> > > > >> > >>>> >>> Given a version number MAJOR.MINOR.PATCH, increment the: > > > >> > >>>> >>> > > > >> > >>>> >>> 1. MAJOR version when you make incompatible API > changes, > > > >> > >>>> >>> 2. MINOR version when you add functionality in a > > > >> > >>>> backwards-compatible > > > >> > >>>> >>> manner, and > > > >> > >>>> >>> 3. PATCH version when you make backwards-compatible > bug > > > >> fixes. > > > >> > >>>> >>> > > > >> > >>>> >>> *Additional labels for pre-release and build metadata are > > > >> > >>>>available as > > > >> > >>>> >>> extensions to the MAJOR.MINOR.PATCH format.* > > > >> > >>>> >>> > > > >> > >>>> >>> > > > >> > >>>> >>> On Thu, Jul 11, 2013 at 8:57 AM, Carlos Santana > > > >> > >>>><csantan...@gmail.com > > > >> > >>>> >>> >wrote: > > > >> > >>>> >>> > > > >> > >>>> >>> > About versioning maybe we should open a > > > >> > >>>>mail-thread/jira/wikipage > > > >> > >>>> (not > > > >> > >>>> >>> > familiar with process yet :-)) > > > >> > >>>> >>> > To discuss and be clear what is the guideline/process > to > > > >> version > > > >> > >>>> >>> different > > > >> > >>>> >>> > components. > > > >> > >>>> >>> > > > > >> > >>>> >>> > Some thoughts (maybe this is already well understood > and > > > >> > >>>>documented > > > >> > >>>> in > > > >> > >>>> >>> > wiki): > > > >> > >>>> >>> > - Lets follow semantic versioning as much as possible > for > > > ALL > > > >> > >>>> components > > > >> > >>>> >>> > (i.e. plugins, core, cli, plugman, platform, repos) > > > >> > >>>> >>> > - Document the deliverables/releases channels (i.e. > npm, > > > >> apache > > > >> > >>>> zip/dist, > > > >> > >>>> >>> > git repo) > > > >> > >>>> >>> > - Maintain the versions in sync (package.json > > {version:""}, > > > >> git > > > >> > >>>>tag) > > > >> > >>>> >>> > tag/hash should match what's posted in npm registry? > > > >> > >>>> >>> > > > > >> > >>>> >>> > --Carlos > > > >> > >>>> >>> > > > > >> > >>>> >>> > > > > >> > >>>> >>> > On Wed, Jul 10, 2013 at 7:33 PM, Andrew Grieve > > > >> > >>>><agri...@chromium.org > > > >> > >>>> >>> >wrote: > > > >> > >>>> >>> > > > > >> > >>>> >>> >> Coho started as just a tool to package, but has grown > > > into a > > > >> > >>>>tool > > > >> > >>>> that: > > > >> > >>>> >>> >> a) helps work with multiple repos > > > >> > >>>> >>> >> b) documents our release process in working code. > > > >> > >>>> >>> >> > > > >> > >>>> >>> >> re windows tagging - As of the last release bug > > template, > > > >> we're > > > >> > >>>> tagging > > > >> > >>>> >>> >> each branch individually either via coho or not, so no > > > issue > > > >> > >>>>there. > > > >> > >>>> It > > > >> > >>>> >>> >> won't be tagged by coho unless someone does it > > > explicitly. I > > > >> > >>>>think > > > >> > >>>> we > > > >> > >>>> >>> can > > > >> > >>>> >>> >> still use it to create the windows release branches, > > > since if > > > >> > >>>>it > > > >> > >>>> messes > > > >> > >>>> >>> up > > > >> > >>>> >>> >> we can just fix what it missed (but all it does is > > update > > > >> > >>>>VERSION > > > >> > >>>> and > > > >> > >>>> >>> >> cordova.js). > > > >> > >>>> >>> >> > > > >> > >>>> >>> >> As for plugins, I've only used CLI by pointing at > > > directories > > > >> > >>>>so > > > >> > >>>> far, > > > >> > >>>> >>> but > > > >> > >>>> >>> >> I > > > >> > >>>> >>> >> was under the impression that if you give it a URL, > you > > > have > > > >> to > > > >> > >>>> give it > > > >> > >>>> >>> a > > > >> > >>>> >>> >> repo + subdirectory + hash/tag combination. If it's > > > currently > > > >> > >>>>just > > > >> > >>>> >>> >> installing from master, I think that's a bad default > and > > > >> should > > > >> > >>>> instead > > > >> > >>>> >>> go > > > >> > >>>> >>> >> by a tag (npm goes by the "stable" tag by default I > > > believe). > > > >> > >>>>So... > > > >> > >>>> we > > > >> > >>>> >>> >> will > > > >> > >>>> >>> >> need an explicit action for commits to a plugin to be > > > picked > > > >> > >>>>up by > > > >> > >>>> >>> >> plugman. > > > >> > >>>> >>> >> > > > >> > >>>> >>> >> How about if a plugin has a commit that is urgent, it > > > gets a > > > >> > >>>>point > > > >> > >>>> >>> release > > > >> > >>>> >>> >> right away. Otherwise, it waits for the next Cordova > > > release > > > >> > >>>>cycle. > > > >> > >>>> >>> >> > > > >> > >>>> >>> >> > > > >> > >>>> >>> >> > > > >> > >>>> >>> >> On Wed, Jul 10, 2013 at 6:47 PM, Jesse > > > >> > >>>><purplecabb...@gmail.com> > > > >> > >>>> wrote: > > > >> > >>>> >>> >> > > > >> > >>>> >>> >> > re: COHO > > > >> > >>>> >>> >> > I cannot guarantee the output of windows/phone > > releases > > > if > > > >> > >>>>they > > > >> > >>>> are > > > >> > >>>> >>> >> tagged > > > >> > >>>> >>> >> > and updated via coho. I like the idea of having > > > continuous > > > >> > >>>> >>> integration, > > > >> > >>>> >>> >> but > > > >> > >>>> >>> >> > this is not there yet. I would prefer for now to > > > manually > > > >> > >>>>update > > > >> > >>>> and > > > >> > >>>> >>> >> tag > > > >> > >>>> >>> >> > wp7+wp8+windows8 repos because I do not currently > > trust > > > the > > > >> > >>>>magic > > > >> > >>>> in > > > >> > >>>> >>> >> coho, > > > >> > >>>> >>> >> > and do not have time to go and understand all of the > > > magic. > > > >> > >>>> >>> >> > > > > >> > >>>> >>> >> > @purplecabbage > > > >> > >>>> >>> >> > risingj.com > > > >> > >>>> >>> >> > > > > >> > >>>> >>> >> > > > > >> > >>>> >>> >> > On Wed, Jul 10, 2013 at 3:36 PM, Steven Gill < > > > >> > >>>> stevengil...@gmail.com> > > > >> > >>>> >>> >> > wrote: > > > >> > >>>> >>> >> > > > > >> > >>>> >>> >> > > Plugin versioning is definitely something we need > to > > > >> > >>>>discuss in > > > >> > >>>> >>> >> detail. > > > >> > >>>> >>> >> > > > > > >> > >>>> >>> >> > > What happens if I make a change to the camera > > plugin. > > > Do > > > >> I > > > >> > >>>> >>> immediately > > > >> > >>>> >>> >> > bump > > > >> > >>>> >>> >> > > the version? Probably not. But people who install > it > > > >> using > > > >> > >>>> >>> plugman/cli > > > >> > >>>> >>> >> > > after the change will get the latest one on master > > > with > > > >> no > > > >> > >>>> obvious > > > >> > >>>> >>> >> > > difference to them. Version wise it is the same as > > > before > > > >> > >>>>the > > > >> > >>>> >>> change. > > > >> > >>>> >>> >> > This > > > >> > >>>> >>> >> > > feels wrong. > > > >> > >>>> >>> >> > > > > > >> > >>>> >>> >> > > We can now update plugins independently of our > once > > a > > > >> month > > > >> > >>>> release > > > >> > >>>> >>> >> and > > > >> > >>>> >>> >> > get > > > >> > >>>> >>> >> > > those updates to our users instantly. I think we > > > should > > > >> > >>>>update > > > >> > >>>> the > > > >> > >>>> >>> >> > version > > > >> > >>>> >>> >> > > of the plugins after every change. Similar to > > > >> node-modules > > > >> > >>>>on > > > >> > >>>> npm. > > > >> > >>>> >>> >> > > > > > >> > >>>> >>> >> > > Coho is not just for packaging. I love the fact > > that I > > > >> can > > > >> > >>>> clone and > > > >> > >>>> >>> >> > update > > > >> > >>>> >>> >> > > all of the repos in a few quick commands. Coho > seems > > > to > > > >> > >>>>have the > > > >> > >>>> >>> >> ability > > > >> > >>>> >>> >> > to > > > >> > >>>> >>> >> > > do tagging, release packaging and signing, > uploading > > > >> > >>>>releases to > > > >> > >>>> >>> >> apache, > > > >> > >>>> >>> >> > > cloning all repos and soon generating release > issues > > > on > > > >> > >>>>jira. It > > > >> > >>>> >>> will > > > >> > >>>> >>> >> be > > > >> > >>>> >>> >> > > important to solve all of the issues people are > > having > > > >> with > > > >> > >>>> coho and > > > >> > >>>> >>> >> > > document what you can do with it. > > > >> > >>>> >>> >> > > > > > >> > >>>> >>> >> > > > > > >> > >>>> >>> >> > > On Wed, Jul 10, 2013 at 3:15 PM, Joe Bowser > > > >> > >>>><bows...@gmail.com> > > > >> > >>>> >>> >> wrote: > > > >> > >>>> >>> >> > > > > > >> > >>>> >>> >> > > > I'm going to create a new thread about this, but > > > what's > > > >> > >>>>the > > > >> > >>>> >>> purpose > > > >> > >>>> >>> >> of > > > >> > >>>> >>> >> > > > coho again? I thought it was just for packaging > > > >> releases. > > > >> > >>>> >>> >> > > > > > > >> > >>>> >>> >> > > > On Wed, Jul 10, 2013 at 3:07 PM, Andrew Grieve < > > > >> > >>>> >>> >> agri...@chromium.org> > > > >> > >>>> >>> >> > > > wrote: > > > >> > >>>> >>> >> > > > > Our intern Jeffrey is actively working on > > adding a > > > >> > >>>>command > > > >> > >>>> to > > > >> > >>>> >>> >> coho to > > > >> > >>>> >>> >> > > be > > > >> > >>>> >>> >> > > > > able to create release bugs (based off of > > > >> > >>>>cordova-labs). If > > > >> > >>>> he > > > >> > >>>> >>> >> gets > > > >> > >>>> >>> >> > > done, > > > >> > >>>> >>> >> > > > > by Monday, then it'll be a cinch to create the > > > >> issues. > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > We could maybe start by discussing what we > want > > > to do > > > >> > >>>>with > > > >> > >>>> the > > > >> > >>>> >>> >> plugin > > > >> > >>>> >>> >> > > > repos > > > >> > >>>> >>> >> > > > > for the release. > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > Should they all have release branches? > > > >> > >>>> >>> >> > > > > Should they be versioned the same? e.g. 3.0.x, > > or > > > >> > >>>>should > > > >> > >>>> they > > > >> > >>>> >>> >> start > > > >> > >>>> >>> >> > out > > > >> > >>>> >>> >> > > > at > > > >> > >>>> >>> >> > > > > 1.0.x? > > > >> > >>>> >>> >> > > > > Are we including a .zip of all of them in our > > > apache > > > >> > >>>> >>> distribution > > > >> > >>>> >>> >> > .zip? > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > Here's a stab at it from me: > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > - Always include all core plugins in the > apache > > > >> > >>>>release .zip > > > >> > >>>> >>> >> > > > > - If a plugin has not changed since the > previous > > > >> > >>>>release, > > > >> > >>>> then > > > >> > >>>> >>> >> just > > > >> > >>>> >>> >> > put > > > >> > >>>> >>> >> > > > in > > > >> > >>>> >>> >> > > > > the previous release of the .zip. > > > >> > >>>> >>> >> > > > > - E.g. for 3.1.0, if plugin-console has no > > > >> changes, > > > >> > >>>>then > > > >> > >>>> just > > > >> > >>>> >>> >> > > package > > > >> > >>>> >>> >> > > > > version 3.0.0 of the plugin in the release > > > >> > >>>> >>> >> > > > > - Create release branches for the plugin repos > > > only > > > >> if > > > >> > >>>> there has > > > >> > >>>> >>> >> > been a > > > >> > >>>> >>> >> > > > > commit since the previous release > > > >> > >>>> >>> >> > > > > - If there were no commits, then there > cannot > > > be > > > >> any > > > >> > >>>> >>> >> regressions, > > > >> > >>>> >>> >> > so > > > >> > >>>> >>> >> > > > no > > > >> > >>>> >>> >> > > > > need for a release branch. > > > >> > >>>> >>> >> > > > > - I think they should be versioned the same to > > > help > > > >> us > > > >> > >>>> figure > > > >> > >>>> >>> out > > > >> > >>>> >>> >> > when > > > >> > >>>> >>> >> > > > the > > > >> > >>>> >>> >> > > > > last change was. > > > >> > >>>> >>> >> > > > > - This could mean that if plugin-console > goes > > > >> three > > > >> > >>>> months > > > >> > >>>> >>> >> > without a > > > >> > >>>> >>> >> > > > > change, it will go from 3.0.0 straight to > 3.3.0 > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > > On Wed, Jul 10, 2013 at 5:50 PM, Filip Maj > > > >> > >>>><f...@adobe.com> > > > >> > >>>> >>> wrote: > > > >> > >>>> >>> >> > > > > > > > >> > >>>> >>> >> > > > >> Yeah.. Maybe we should create the issues for > > the > > > rc > > > >> > >>>>soon? > > > >> > >>>> >>> >> > > > >> > > > >> > >>>> >>> >> > > > >> On 7/10/13 1:57 PM, "Andrew Grieve" > > > >> > >>>><agri...@chromium.org> > > > >> > >>>> >>> >> wrote: > > > >> > >>>> >>> >> > > > >> > > > >> > >>>> >>> >> > > > >> >I would put that at next week unless someone > > has > > > >> > >>>>cycles > > > >> > >>>> to get > > > >> > >>>> >>> >> on > > > >> > >>>> >>> >> > it > > > >> > >>>> >>> >> > > > this > > > >> > >>>> >>> >> > > > >> >week. > > > >> > >>>> >>> >> > > > >> > > > > >> > >>>> >>> >> > > > >> > > > > >> > >>>> >>> >> > > > >> >On Wed, Jul 10, 2013 at 4:24 PM, Marcel > > Kinard < > > > >> > >>>> >>> >> cmarc...@gmail.com > > > >> > >>>> >>> >> > > > > > >> > >>>> >>> >> > > > >> wrote: > > > >> > >>>> >>> >> > > > >> > > > > >> > >>>> >>> >> > > > >> >> When will the Upgrade Guides (2.9 -> 3.0) > be > > > >> > >>>>written? > > > >> > >>>> That > > > >> > >>>> >>> >> > content > > > >> > >>>> >>> >> > > is > > > >> > >>>> >>> >> > > > >> >> currently not in cordova-docs. > > > >> > >>>> >>> >> > > > >> > > > >> > >>>> >>> >> > > > >> > > > >> > >>>> >>> >> > > > > > > >> > >>>> >>> >> > > > > > >> > >>>> >>> >> > > > > >> > >>>> >>> >> > > > >> > >>>> >>> > > > > >> > >>>> >>> > > > > >> > >>>> >>> > > > > >> > >>>> >>> > -- > > > >> > >>>> >>> > Carlos Santana > > > >> > >>>> >>> > <csantan...@gmail.com> > > > >> > >>>> >>> > > > > >> > >>>> >>> > > > >> > >>>> >>> > > > >> > >>>> >>> > > > >> > >>>> >>> -- > > > >> > >>>> >>> Carlos Santana > > > >> > >>>> >>> <csantan...@gmail.com> > > > >> > >>>> >>> > > > >> > >>>> > > > >> > > > > >> > > > > >> > > > > > >
