cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: New directory structure in cordova-cli's future branch
Date Thu, 23 May 2013 18:04:22 GMT
So for the sake of moving the RC release along, Michal/Braden/Andrew are
you guys cool if we:

A) revert to www/ as root folder
B) proceed with 2.8.0rc1 tagging
C) continue with this discussion to try to get to a resolution. Worst-case
we call a vote next week?

On 5/23/13 10:56 AM, "Michal Mocny" <mmocny@chromium.org> wrote:

>Fil, that sounds extremely sensible.
>
>
>On Thu, May 23, 2013 at 12:32 PM, Filip Maj <fil@adobe.com> wrote:
>
>> https://npmjs.org/package/cordova
>>
>>
>> While CLI is not a documented flow, it is deployed and has > 1000
>> downloads per month.
>>
>> That's my only concern: not fucking those people over.
>>
>> I'm in favor of that structure I just don't want it to change without
>> warning in this next release. Ideally set up deprecation messages, be
>> noisy about the change, and sure, possibly supporting a transitioning
>> automatically in our tooling, and then land it in full and remove
>> deprecation messages about it in 3.0.
>>
>> On 5/23/13 9:27 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
>>
>> >Clarification of typing mistake, below..
>> >
>> >Also, curious why this breaks things in the first place?  I thought
>>this
>> >is
>> >the first time we are releasing these tools?  The current create script
>> >workflow is totally different, and I know there is a npm package for
>> >cordova cli already, but that was never a promoted flow (matter of
>>fact,
>> >why was it released? Are we supporting current users of that, is that
>>it?)
>> >
>> >-Michal
>> >
>> >On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mmocny@chromium.org>
>> >wrote:
>> >
>> >> Brian,
>> >> I do not really understand your previous point, but I'll take a stab.
>> >>
>> >> First some clarification:  I think there are two logical "roots", (1)
>> >>the
>> >> root of your web app (holds merges/ and www/ and maybe more), and (2)
>> >>the
>> >> root of your cordova workspace (holds platforms/ plugins/ and maybe
>> >>more).
>> >>
>> >> With the app/ folder, (1) is a subdirectory (2).  With the current
>> >> situation, they overlap inside the same folder.
>> >>
>> >> I think it should be a goal to version control, share, and perhaps
>> >>bundle
>> >> auxiliary resources with app/'s.
>> >> I think it should also be a goal to not limit the future structure of
>> >>the
>> >> cordova workspace (ie, build artifacts).
>> >>
>> >> The current situation makes these goals harder.
>> >>
>> >> As one data point, our team here has a workflow where we share
>>several
>> >> apps (containing only the contents(2)), and we share the common
>>plugins
>> >>we
>> >> work on.
>> >> The contents of (1) are never committed, shared, etc, and are just
>> >> recreated on a regular basis as cordova versions change and as we
>>test
>> >>for
>> >> different platforms.  Sidenote: yes, I have multiple different
>>cordova
>> >> workspaces pointing to one common app to test with different
>>versions.
>> >>  This is a bit of a cordova-developer necessity, but it would be
>> >> interesting if external devs could trial out new cordova releases on
>>the
>> >> side, trivially..
>> >>
>> >Sigh, of course I got the numbers reversed here.. my bad.  Of course I
>> >mean
>> >we only commit (1).
>> >
>> >
>> >>
>> >>
>> >> So, like you Brian, we are just trying to get all the
>> >>requirements/wishes
>> >> on the table so we can make a conscious decision here.  It looks like
>> >>you
>> >> are not seeing sufficient motivation for making the change, and we
>>are
>> >>not
>> >> seeing any reason to not make it.
>> >>
>> >> Another observation: the transition path even easier than we have
>> >>outlined
>> >> above.
>> >>
>> >> If your existing project is:
>> >> - app_name/
>> >>  - platforms/
>> >>  - plugins/
>> >>  - www/
>> >>  - merges/
>> >>
>> >> All you need to do is rm -rf platforms/ plugins/ www/config.xml --
>>which
>> >> you need to do anyway to upgrade to 3.0 -- create a new config.xml at
>> >>the
>> >> root and you now have a shareable app, and you can create as many
>> >>cordova
>> >> different workspaces using it as you want.
>> >>
>> >> -Michal
>> >>
>> >>
>> >> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b@brian.io> wrote:
>> >>
>> >>> Not buying that either. The `./app` directory lives in the root so
>> >>> everything will have to change when we hit the reality you describe
>> >>> where `./app` IS the root.
>> >>>
>> >>> What you are really saying this is a transition step until such time
>> >>> as `./app` becomes top level and things return to the same as they
>>are
>> >>> today but we do not require native bits to be revisioned.
>>Essentially
>> >>> this is an aesthetic forcing function to get back to the original
>> >>> structure. =P
>> >>>
>> >>> This is a very complicated way to achieve the goal of native bits
>> >>> being build artifacts. A goal I share, many do, and I think we can
>> >>> achieve it by NOT breaking things today.
>> >>>
>> >>>
>> >>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson
>> >>><braden@chromium.org>
>> >>> wrote:
>> >>> > cd app
>> >>> > git init
>> >>> >
>> >>> > Now my app directory - everything that makes this app mine and
>>isn't
>> >>> just a
>> >>> > cordova-cli artifact - is version controlled. I can easily check
>>out
>> >>>a
>> >>> new
>> >>> > copy with a cordova create ...; rm -rf app; git clone https://
>> >>> .../myrepo.git
>> >>> > app
>> >>> >
>> >>> > Once we have app-level dependencies (which is planned
>>regardless), I
>> >>>can
>> >>> > add cordova fetch-deps or whatever we decide the command should
>>be,
>> >>>and
>> >>> now
>> >>> > my app is fully set up. No need to juggle .gitignore or anything
>> >>>else.
>> >>> It's
>> >>> > hardly a killer feature, but I think it is an improvement.
>> >>> >
>> >>> > Michal asked what change we would regret more a year from now. I
>> >>>think
>> >>> this
>> >>> > style makes the separation of CLI artifacts and my app more clear,
>> >>>and
>> >>> if
>> >>> > we add more pieces to either it won't require changing people's
>> >>> .gitignore
>> >>> > files or knowing about the architecture.
>> >>> >
>> >>> > Braden
>> >>> >
>> >>> >
>> >>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b@brian.io> wrote:
>> >>> >
>> >>> >> I want to be very clear that my tone here is emotionless! I'm
>> >>>totally
>> >>> >> indifferent.
>> >>> >>
>> >>> >> Now, please explain: how is a new directory make version control
>> >>> >> easier? I don't buy it.
>> >>> >>
>> >>> >>
>> >>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
>> >>> braden@chromium.org>
>> >>> >> wrote:
>> >>> >> > The change is not purely aesthetic; it means that the "my app"
>> >>> portions
>> >>> >> of
>> >>> >> > the structure are now contained in a single directory, and
>>easier
>> >>>to
>> >>> >> > version control.
>> >>> >> >
>> >>> >> > This change gets more expensive every day. If we're ever going
>>to
>> >>>do
>> >>> it,
>> >>> >> it
>> >>> >> > should be done now, I believe.
>> >>> >> >
>> >>> >> > It seems like the (not universally supported) consensus from
>>the
>> >>> first
>> >>> >> pass
>> >>> >> > at this thread was to keep the app/ dir but have automatic
>> >>>detection
>> >>> and
>> >>> >> > ask-then-automatic conversion.
>> >>> >> >
>> >>> >> > If that approach is still acceptable, I will implement that
>> >>>support
>> >>> today
>> >>> >> > before we tag CLI for 2.8.
>> >>> >> >
>> >>> >> > Braden
>> >>> >> >
>> >>> >> >
>> >>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny
>> >>><mmocny@chromium.org>
>> >>> >> wrote:
>> >>> >> >
>> >>> >> >> Fil, good summary, thanks for that.  I also agree with your
>> >>> proposal.
>> >>> >> >>  Would it be possible to just support both options starting
>>now,
>> >>>and
>> >>> >> >> "deprecate" www/ at the top level in 3.0?
>> >>> >> >>
>> >>> >> >> Brian, this isn't just aesthetics, but its true that either
>> >>>option
>> >>> can,
>> >>> >> >> with varying difficulty, be made to work for all use cases.
>> >>> >> >>
>> >>> >> >> Migration path is trivial but will be paid by all users,
>>still,
>> >>> >> workflows
>> >>> >> >> will change completely with 3.0 anyway, this being the least
>>of
>> >>>the
>> >>> >> >> changes.  Which decision is more likely to be regretted a year
>> >>>from
>> >>> now?
>> >>> >> >>
>> >>> >> >> -Michal
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
>> >>> agrieve@chromium.org
>> >>> >> >> >wrote:
>> >>> >> >>
>> >>> >> >> > I don't really think this directory change is a big deal. We
>> >>>break
>> >>> >> things
>> >>> >> >> > in almost every release (e.g. loading pages of http), yet
>>we're
>> >>> >> having so
>> >>> >> >> > much debate over alpha tool.
>> >>> >> >> >
>> >>> >> >> > The migration path is: mkdir app && git mv www merges app &&
>> >>>git
>> >>> mv
>> >>> >> >> > app/www/config.xml app
>> >>> >> >> >
>> >>> >> >> > I think the least amount of work here is to just
>>console.log an
>> >>> error
>> >>> >> >> > message with this command if the app/ directory is not
>>found.
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>> >>> >> >> > <tommy@devgeeks.org>wrote:
>> >>> >> >> >
>> >>> >> >> > > Is it bad that I both agree vehemently with Brian's
>>calling
>> >>>it
>> >>> not
>> >>> >> >> > > beneficial enough to justify, but also really really like
>>the
>> >>> >> proposed
>> >>> >> >> > > structure better that the current one? hehe.
>> >>> >> >> > >
>> >>> >> >> > > *so҆ conflicted...*
>> >>> >> >> > >
>> >>> >> >> > > - tommy
>> >>> >> >> > >
>> >>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b@brian.io>
>>wrote:
>> >>> >> >> > >
>> >>> >> >> > > > There are two paths. I argue there is no functional
>>benefit
>> >>> and
>> >>> >> that
>> >>> >> >> > > > this change is purely aesthetic. Aesthetics are
>>important
>> >>>but
>> >>> I'd
>> >>> >> >> > > > argue folder structure is the last part of the developer
>> >>> >> aesthetics
>> >>> >> >> we
>> >>> >> >> > > > should worry about and especially not beneficial enough
>>to
>> >>> >> justify a
>> >>> >> >> > > > breaking change.
>> >>> >> >> > > >
>> >>> >> >> > > > Today:
>> >>> >> >> > > >
>> >>> >> >> > > > ./
>> >>> >> >> > > > |- merges/
>> >>> >> >> > > > |- platforms/
>> >>> >> >> > > > |- plugins/
>> >>> >> >> > > > '- www/
>> >>> >> >> > > >    |- index.html
>> >>> >> >> > > >    '- config.xml
>> >>> >> >> > > >
>> >>> >> >> > > > Proposed:
>> >>> >> >> > > >
>> >>> >> >> > > > ./
>> >>> >> >> > > > |- platforms/
>> >>> >> >> > > > |- plugins/
>> >>> >> >> > > > '- app/
>> >>> >> >> > > >    |- merges/
>> >>> >> >> > > >    |- www/
>> >>> >> >> > > >    |       '- index.html
>> >>> >> >> > > >    '- config.xml
>> >>> >> >> > > >
>> >>> >> >> > > >
>> >>> >> >> > > >
>> >>> >> >> > > >
>> >>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj
>><fil@adobe.com>
>> >>> wrote:
>> >>> >> >> > > >> I'm reviving this discussion re: additional app/
>>folder in
>> >>> the
>> >>> >> >> > > >> cli-generated project structure.
>> >>> >> >> > > >>
>> >>> >> >> > > >> To recap, there were two main discussions:
>> >>> >> >> > > >>
>> >>> >> >> > > >> A)
>> >>> >> >> > > >>
>> >>> >> >> > >
>> >>> >> >> >
>> >>> >> >>
>> >>> >>
>> >>>
>> >>>
>> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76
>> >>>xli
>> >>> >> >> > > >> hsfjmvwtoi+state:results
>> >>> >> >> > > >> B)
>> >>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>> >>> >> >> > > >>
>> >>> >> >> > > >> Arguments for moving to app/:
>> >>> >> >> > > >>
>> >>> >> >> > > >> - easier to version control relevant /
>>non-build-artifact
>> >>>app
>> >>> >> bits
>> >>> >> >> > > >> - aesthetics
>> >>> >> >> > > >>
>> >>> >> >> > > >> Arguments against it:
>> >>> >> >> > > >>
>> >>> >> >> > > >> - we break shit for users
>> >>> >> >> > > >> - config.xml location and PhoneGap Build compatibility
>> >>>(but I
>> >>> >> don't
>> >>> >> >> > see
>> >>> >> >> > > >> this as a valid argument against. This is an easy
>>problem
>> >>>to
>> >>> >> solve
>> >>> >> >> for
>> >>> >> >> > > us
>> >>> >> >> > > >> Adobe folk and the tooling can handle the trivial
>>steps of
>> >>> going
>> >>> >> up
>> >>> >> >> > one
>> >>> >> >> > > >> directory to grab the right file before interfacing
>>with
>> >>> Build)
>> >>> >> >> > > >>
>> >>> >> >> > > >> Also worth noting: people we're not against it for
>> >>> architectural
>> >>> >> >> > > reasons,
>> >>> >> >> > > >> in fact, most people were favorable for the change to
>> >>>app/.
>> >>> >> >> > > >>
>> >>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli
>> >>> work, I
>> >>> >> >> feel I
>> >>> >> >> > > >> have a good grasp of both projects and the direction
>>they
>> >>>are
>> >>> >> going,
>> >>> >> >> > > here
>> >>> >> >> > > >> is my suggestion on how to move forward with this:
>> >>> >> >> > > >>
>> >>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge
>> >>>future
>> >>> work
>> >>> >> >> in,
>> >>> >> >> > > will
>> >>> >> >> > > >> revert to the old /www-based structure, then
>> >>> >> >> > > >> 2. In 3.0 we make the change, where landing such a
>> >>>breaking
>> >>> >> change
>> >>> >> >> is
>> >>> >> >> > > >> easier and we'll have a bunch of press/noise about the
>> >>> release
>> >>> >> out
>> >>> >> >> > there
>> >>> >> >> > > >> too so communicating this change would be easier.
>> >>> >> >> > > >>
>> >>> >> >> > > >> If there are any other arguments for/against the app/
>> >>>based
>> >>> >> >> structure,
>> >>> >> >> > > now
>> >>> >> >> > > >> is the time to bring it up. We can give this some more
>> >>>time
>> >>> to
>> >>> >> bake,
>> >>> >> >> > but
>> >>> >> >> > > >> after 2.8 is released, I'd like to call a vote on
>>whether
>> >>>we
>> >>> >> should
>> >>> >> >> > move
>> >>> >> >> > > >> to this structure or not in 3.0.
>> >>> >> >> > > >>
>> >>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny"
>><mmocny@chromium.org>
>> >>> wrote:
>> >>> >> >> > > >>
>> >>> >> >> > > >>> I should also add.  I appreciate that this is a
>>change,
>> >>>and
>> >>> >> every
>> >>> >> >> > > change
>> >>> >> >> > > >>> has some learning overhead and we shouldn't stuff
>> >>>everything
>> >>> >> >> possible
>> >>> >> >> > > in
>> >>> >> >> > > >>> all the time.
>> >>> >> >> > > >>>
>> >>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we
>> >>> should do
>> >>> >> the
>> >>> >> >> > big
>> >>> >> >> > > >>> re-org all at once, so lets decide this now in a way
>>we
>> >>>wont
>> >>> >> >> regret.
>> >>> >> >> > > >>> Thats
>> >>> >> >> > > >>> why we are being picky, I guess.  I like knowing that
>>the
>> >>> root
>> >>> >> of
>> >>> >> >> the
>> >>> >> >> > > >>> project has cordova-only artifacts and your app-repo
>>is
>> >>> just a
>> >>> >> >> > > >>> subdirectory
>> >>> >> >> > > >>> somewhere.  Then, the exact location and exact
>>contents
>> >>>are
>> >>> way
>> >>> >> >> more
>> >>> >> >> > > >>> flexible.
>> >>> >> >> > > >>>
>> >>> >> >> > > >>> -Michal
>> >>> >> >> > > >>>
>> >>> >> >> > > >>>
>> >>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>> >>> >> >> mmocny@chromium.org>
>> >>> >> >> > > >>> wrote:
>> >>> >> >> > > >>>
>> >>> >> >> > > >>>> Okay, we've got options, so lets try to distill the
>> >>> details.
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> First, some of the other (perceived) benefits of an
>>app
>> >>> folder
>> >>> >> >> are:
>> >>> >> >> > > >>>> * we do a raw cp -r of the www/ folder, and so that
>> >>>should
>> >>> have
>> >>> >> >> only
>> >>> >> >> > > >>>> platform agnostic and "necessary" files.
>> >>> >> >> > > >>>> * merges folder was removed from www/ because it did
>>not
>> >>> meet
>> >>> >> >> above
>> >>> >> >> > > >>>> criteria, and config.xml is another candidate
>> >>> >> >> > > >>>> * there also potentially exist docs/ (useful for
>>shared
>> >>> apps,
>> >>> >> like
>> >>> >> >> > > >>>> mobile-spec), platform specific resource files
>>(icons,
>> >>> splash
>> >>> >> >> > screen),
>> >>> >> >> > > >>>> etc
>> >>> >> >> > > >>>> * a git repository is already basically mirroring the
>> >>> concept
>> >>> >> of
>> >>> >> >> the
>> >>> >> >> > > >>>> "app
>> >>> >> >> > > >>>> folder"
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> So, I've come up with the following potential
>>workflows
>> >>>for
>> >>> >> >> starting
>> >>> >> >> > > >>>> with
>> >>> >> >> > > >>>> an existing app:
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> #1: "your app repo is moved into some subdirectory
>>of a
>> >>> cordova
>> >>> >> >> > > project
>> >>> >> >> > > >>>> --
>> >>> >> >> > > >>>> its exact location is basically a cordova artifact"
>> >>> >> >> > > >>>>  cordova create Foo
>> >>> >> >> > > >>>>  cd Foo
>> >>> >> >> > > >>>>  cordova app add [--link] git-repo/local-repo (nicely
>> >>>akin
>> >>> to
>> >>> >> >> plugin
>> >>> >> >> > > >>>> add)
>> >>> >> >> > > >>>>  cordova plugin/platforms add ...
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> #2: "your app repo becomes a cordova project
>>in-place"
>> >>> >> >> > > >>>>  git clone FooApp (this repo contains merges/ and
>>www/)
>> >>> >> >> > > >>>>  cordova create FooApp Foo (cli should not clobber
>> >>>existing
>> >>> >> >> folders)
>> >>> >> >> > > >>>>  cd FooApp
>> >>> >> >> > > >>>>  set up .gitignore for cordova artifacts (cordova
>>should
>> >>> try
>> >>> >> not
>> >>> >> >> to
>> >>> >> >> > > >>>> introduce new artifacts)
>> >>> >> >> > > >>>>  cordova plugin/platforms add ...
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> #3: "what we have now"
>> >>> >> >> > > >>>>  git clone FooApp
>> >>> >> >> > > >>>>  cordova create Foo
>> >>> >> >> > > >>>>  cp -R FooApp/{www,merges,...} Foo  (or ln -s)
>> >>> >> >> > > >>>>  cd Foo
>> >>> >> >> > > >>>>  cordova plugin/platforms add ...
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> (Please let me know of more workflows)
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> Workflow #1 I think is very clean, and requires an
>>app
>> >>> folder
>> >>> >> >> > concept
>> >>> >> >> > > >>>> (we
>> >>> >> >> > > >>>> could maybe use a temporary intermediate folder to
>>get
>> >>> around
>> >>> >> >> this,
>> >>> >> >> > > but
>> >>> >> >> > > >>>> why).
>> >>> >> >> > > >>>> Workflow #2 essentially your app repo is the app
>>folder
>> >>> >> concept,
>> >>> >> >> but
>> >>> >> >> > > now
>> >>> >> >> > > >>>> the cordova artifacts also go inside it.  Would
>>require
>> >>> minimal
>> >>> >> >> > > changes
>> >>> >> >> > > >>>> to
>> >>> >> >> > > >>>> cordova-cli to not clobber, and requires gitignore.
>> >>> >> >> > > >>>> Workflow #3 is what we have now, which I think is the
>> >>>worst
>> >>> >> option
>> >>> >> >> > for
>> >>> >> >> > > >>>> app
>> >>> >> >> > > >>>> management, but can work with or without an app
>>folder.
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> Also, I think it would be great if apps had both
>>plugin
>> >>>and
>> >>> >> >> platform
>> >>> >> >> > > >>>> dependancies, such that you could distill workflow #1
>> >>>down
>> >>> to:
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>>  cordova create Foo
>> >>> >> >> > > >>>>  cd Foo
>> >>> >> >> > > >>>>  cordova app add git-repo
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> .. and it would run the plugin/platform add
>> >>>automatically.
>> >>>  Can
>> >>> >> >> even
>> >>> >> >> > > get
>> >>> >> >> > > >>>> that down to a single "cordova create git-repo" line.
>> >>>That
>> >>> >> would
>> >>> >> >> > make
>> >>> >> >> > > >>>> sharing apps, such as mobile-spec-test, really
>>trivial.
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> -Michal
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>> On Tue, Apr 16, 2013 at 9:19 AM, Andrew Grieve
>> >>> >> >> > > >>>> <agrieve@chromium.org>wrote:
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>>> So, reading through the thread Braden linked to:
>> >>> >> >> > > >>>>>
>> >>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>> There are two advantage that were brought up:
>> >>> >> >> > > >>>>> 1. config.xml (configuration) does not live along
>>side
>> >>>of
>> >>> app
>> >>> >> >> > > resources
>> >>> >> >> > > >>>>> 2. It will make it easier to package apps
>> >>> >> >> > > >>>>>  - E.g. zip the app/ directory and install it into
>>the
>> >>> >> >> app-harness
>> >>> >> >> > > >>>>> (instead of zipping www + merges). Likewise for
>> >>>phonegap
>> >>> >> build.
>> >>> >> >> > > >>>>>  - E.g. cordova-mobile-spec would contain the
>>contents
>> >>>of
>> >>> >> app/.
>> >>> >> >> > With
>> >>> >> >> > > >>>>> our
>> >>> >> >> > > >>>>> current setup, it would contain www/ merges/, and
>>have
>> >>> the CLI
>> >>> >> >> > place
>> >>> >> >> > > >>>>> build
>> >>> >> >> > > >>>>> artifacts within the repo's directory instead of as
>>a
>> >>> sibling
>> >>> >> to
>> >>> >> >> > it.
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>> I think everyone acknowledged the benefits, but
>>there
>> >>>was
>> >>> >> still
>> >>> >> >> > > >>>>> not consensus over whether it was "worth it".
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>> I don't really feel strongly about it. Braden says
>>it's
>> >>> easy
>> >>> >> to
>> >>> >> >> > > change
>> >>> >> >> > > >>>>> code-wise. Does anyone want to go to bat for it?
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>> On Mon, Apr 15, 2013 at 6:59 PM, Brian LeRoux
>> >>><b@brian.io
>> >>> >
>> >>> >> >> wrote:
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>>> I'd rather we did not go ahead w/ the new directory
>> >>> >> structure.
>> >>> >> >> It
>> >>> >> >> > > >>>>> offers no
>> >>> >> >> > > >>>>>> functional benefit, and comes at an upgrade cost
>>for
>> >>>ppl
>> >>> >> using
>> >>> >> >> the
>> >>> >> >> > > >>>>> CLI
>> >>> >> >> > > >>>>>> tools today.
>> >>> >> >> > > >>>>>>
>> >>> >> >> > > >>>>>>
>> >>> >> >> > > >>>>>> On Mon, Apr 15, 2013 at 12:46 PM, Andrew Grieve <
>> >>> >> >> > > agrieve@chromium.org
>> >>> >> >> > > >>>>>>> wrote:
>> >>> >> >> > > >>>>>>
>> >>> >> >> > > >>>>>>> Just catching up on the past week of emails and
>>it's
>> >>>not
>> >>> >> clear
>> >>> >> >> > that
>> >>> >> >> > > >>>>> there
>> >>> >> >> > > >>>>>>> was a consensus here. By the sounds of it though:
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>> 1. Lots of users are using Cordova-CLI (master
>> >>>branch)
>> >>> >> >> > > >>>>>>> 2. Cordova-CLI's "future" branch has
>> >>> >> non-backwards-compatible
>> >>> >> >> > > >>>>> changes.
>> >>> >> >> > > >>>>>>> 3. One of these changes is the directory
>>structure.
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>> The main debate is on how to message these
>>changes to
>> >>> users.
>> >>> >> >> What
>> >>> >> >> > > >>>>> we
>> >>> >> >> > > >>>>>> should
>> >>> >> >> > > >>>>>>> do is:
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>> 1. Have an upgrade guide. (e.g. paths are now
>> >>>relative
>> >>> to
>> >>> >> >> > > >>>>> plugin.xml)
>> >>> >> >> > > >>>>>>> 2. Ensure that our error handling shows useful
>> >>>messages
>> >>> when
>> >>> >> >> they
>> >>> >> >> > > >>>>> result
>> >>> >> >> > > >>>>>>> from an old-way-of-doing-things (e.g. your app's
>> >>> structure
>> >>> >> >> > doesn't
>> >>> >> >> > > >>>>>> match.)
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>> Rather than printing out the commands to run to
>> >>>convert
>> >>> >> their
>> >>> >> >> > > >>>>> project,
>> >>> >> >> > > >>>>>>> maybe we could have them in the upgrade guide and
>> >>>have
>> >>> the
>> >>> >> >> error
>> >>> >> >> > > >>>>> messages
>> >>> >> >> > > >>>>>>> point to the guide?
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>> On Wed, Apr 10, 2013 at 5:47 PM, Tim Kim <
>> >>> >> timkim85@gmail.com>
>> >>> >> >> > > >>>>> wrote:
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>>> Braden I have merged master and the future
>>branch:
>> >>> >> >> > > >>>>>>>>
>> >>> https://github.com/timkim/plugman/tree/future_master_merge
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>> I think it's about ready to merge back in to
>>future.
>> >>> I've
>> >>> >> >> gotten
>> >>> >> >> > > >>>>> the
>> >>> >> >> > > >>>>>>>> android-one-install and the
>>ios-config-xml-install
>> >>> (minus
>> >>> >> one
>> >>> >> >> > > >>>>> weird
>> >>> >> >> > > >>>>>> test
>> >>> >> >> > > >>>>>>> I
>> >>> >> >> > > >>>>>>>> don't understand) working.
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>> On 10 April 2013 14:42, Anis KADRI <
>> >>> anis.kadri@gmail.com>
>> >>> >> >> > wrote:
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>>> As far as I am concerned I don't really have a
>> >>>strong
>> >>> >> opinion
>> >>> >> >> > > >>>>> on
>> >>> >> >> > > >>>>> this
>> >>> >> >> > > >>>>>>>>> topic. As I said in the previous thread, I do
>>like
>> >>> this
>> >>> >> new
>> >>> >> >> > > >>>>> directory
>> >>> >> >> > > >>>>>>>>> structure and if you have it there and tested
>>then
>> >>> fine.
>> >>> >> We
>> >>> >> >> > > >>>>> break
>> >>> >> >> > > >>>>>> shit
>> >>> >> >> > > >>>>>>>> all
>> >>> >> >> > > >>>>>>>>> the time it's not like this change is one too
>>many.
>> >>> What
>> >>> >> >> > > >>>>> matters
>> >>> >> >> > > >>>>> is
>> >>> >> >> > > >>>>>> to
>> >>> >> >> > > >>>>>>>>> communicate it to our users and give them an
>> >>>upgrade
>> >>> path
>> >>> >> to
>> >>> >> >> > > >>>>> this
>> >>> >> >> > > >>>>> new
>> >>> >> >> > > >>>>>>> app
>> >>> >> >> > > >>>>>>>>> structure (the Cordova docs are a good place for
>> >>> that).
>> >>> >> >> > > >>>>>>>>>
>> >>> >> >> > > >>>>>>>>> However, I agree with Brian that there are more
>> >>> important
>> >>> >> >> > > >>>>> things
>> >>> >> >> > > >>>>> to
>> >>> >> >> > > >>>>>>>> tackle
>> >>> >> >> > > >>>>>>>>> right now. Now sure what you had on your list
>>but
>> >>> since js
>> >>> >> >> only
>> >>> >> >> > > >>>>>> modules
>> >>> >> >> > > >>>>>>>> are
>> >>> >> >> > > >>>>>>>>> in Plugman right now (untested) The next big
>>thing
>> >>> that is
>> >>> >> >> > > >>>>> going
>> >>> >> >> > > >>>>> to
>> >>> >> >> > > >>>>>> be
>> >>> >> >> > > >>>>>>>>> non-trivial is: plugin dependencies (which will
>>in
>> >>> some
>> >>> >> ways
>> >>> >> >> > > >>>>> involve
>> >>> >> >> > > >>>>>>>>> discovery I think). We should have a discussion
>> >>>about
>> >>> that
>> >>> >> >> > > >>>>> (hangout,
>> >>> >> >> > > >>>>>>> IRC,
>> >>> >> >> > > >>>>>>>>> connect...whatever). I have a couple of ideas
>>about
>> >>> that.
>> >>> >> >> > > >>>>>>>>>
>> >>> >> >> > > >>>>>>>>> Tim is working on fixing/adding/updating plugman
>> >>>tests
>> >>> >> and it
>> >>> >> >> > > >>>>> looks
>> >>> >> >> > > >>>>>>> like
>> >>> >> >> > > >>>>>>>>> he's making good progress on it.
>> >>> >> >> > > >>>>>>>>>
>> >>> >> >> > > >>>>>>>>> -a
>> >>> >> >> > > >>>>>>>>>
>> >>> >> >> > > >>>>>>>>>
>> >>> >> >> > > >>>>>>>>> On Wed, Apr 10, 2013 at 11:53 AM, Michael Wolf <
>> >>> >> >> > > >>>>>>> Michael.Wolf@cynergy.com
>> >>> >> >> > > >>>>>>>>>> wrote:
>> >>> >> >> > > >>>>>>>>>
>> >>> >> >> > > >>>>>>>>>> +1
>> >>> >> >> > > >>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>> I get the intention, however anything we can
>>do to
>> >>> reduce
>> >>> >> >> > > >>>>> this
>> >>> >> >> > > >>>>> type
>> >>> >> >> > > >>>>>>> of
>> >>> >> >> > > >>>>>>>>>> breaking change should be done.   These type of
>> >>> changes
>> >>> >> >> > > >>>>> should
>> >>> >> >> > > >>>>> be
>> >>> >> >> > > >>>>>>>>>> considered for major releases only so users can
>> >>>plan
>> >>> for
>> >>> >> >> > > >>>>> them.
>> >>> >> >> > > >>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>> mw
>> >>> >> >> > > >>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>> On 4/9/13 5:05 PM, "Jesse"
>> >>><purplecabbage@gmail.com>
>> >>> >> wrote:
>> >>> >> >> > > >>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>> +1 to the sanity plea of devgeek Tommy
>> >>> >> >> > > >>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>> Also, if it didn't happen on this list, ....
>> >>> >> >> > > >>>>>>>>>>> 'Consensus' should always be tracked back to a
>> >>> thread
>> >>> >> here,
>> >>> >> >> > > >>>>>>> regardless
>> >>> >> >> > > >>>>>>>>> of
>> >>> >> >> > > >>>>>>>>>>> meetings, hangouts, irc, bbs, ...
>> >>> >> >> > > >>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>> @purplecabbage
>> >>> >> >> > > >>>>>>>>>>> risingj.com
>> >>> >> >> > > >>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>> On Tue, Apr 9, 2013 at 1:48 PM, tommy-carlos
>> >>> Williams
>> >>> >> >> > > >>>>>>>>>>> <tommy@devgeeks.org>wrote:
>> >>> >> >> > > >>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>> Sorry, but as someone that helps users
>>everyday,
>> >>> the
>> >>> >> >> > > >>>>> almost
>> >>> >> >> > > >>>>>> "it's
>> >>> >> >> > > >>>>>>>>> alpha,
>> >>> >> >> > > >>>>>>>>>>>> they shoulda seen it coming" tone of this is
>>a
>> >>>bit
>> >>> >> >> > > >>>>> upsetting.
>> >>> >> >> > > >>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>> It reminds me of before the deprecation
>>policy,
>> >>>etc
>> >>> >> when
>> >>> >> >> > > >>>>>> PhoneGap
>> >>> >> >> > > >>>>>>>>> would
>> >>> >> >> > > >>>>>>>>>>>> completely break everything whenever a new
>> >>>version
>> >>> came
>> >>> >> >> > > >>>>> out.
>> >>> >> >> > > >>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>> I feel like we have come a long way since
>>then
>> >>> (with a
>> >>> >> >> > > >>>>> ways
>> >>> >> >> > > >>>>>> still
>> >>> >> >> > > >>>>>>> to
>> >>> >> >> > > >>>>>>>>> go,
>> >>> >> >> > > >>>>>>>>>>>> no question about it).  I would hate to be
>>the
>> >>>one
>> >>> in
>> >>> >> IRC
>> >>> >> >> > > >>>>> and on
>> >>> >> >> > > >>>>>>> the
>> >>> >> >> > > >>>>>>>>>>>> Google
>> >>> >> >> > > >>>>>>>>>>>> Group list having to explain this to everyone
>> >>> using the
>> >>> >> >> > > >>>>> cli.
>> >>> >> >> > > >>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>> I was under the impression that the cli was
>> >>> "shipping"
>> >>> >> >> > > >>>>> now,
>> >>> >> >> > > >>>>> not
>> >>> >> >> > > >>>>>>>> just a
>> >>> >> >> > > >>>>>>>>>>>> little side thing. I know that quite a few
>> >>>people
>> >>> are
>> >>> >> >> > > >>>>> using
>> >>> >> >> > > >>>>> it
>> >>> >> >> > > >>>>>> for
>> >>> >> >> > > >>>>>>>>> real
>> >>> >> >> > > >>>>>>>>>>>> apps (myself included). If that is true,
>>then we
>> >>> have a
>> >>> >> >> > > >>>>> duty
>> >>> >> >> > > >>>>> to
>> >>> >> >> > > >>>>>> at
>> >>> >> >> > > >>>>>>>>> least
>> >>> >> >> > > >>>>>>>>>>>> think very carefully before breaking
>>something
>> >>>and
>> >>> >> come up
>> >>> >> >> > > >>>>> with
>> >>> >> >> > > >>>>>> a
>> >>> >> >> > > >>>>>>>> good
>> >>> >> >> > > >>>>>>>>>>>> plan
>> >>> >> >> > > >>>>>>>>>>>> for easing that transition.
>> >>> >> >> > > >>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>> - tommy
>> >>> >> >> > > >>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>> On 10/04/2013, at 1:40, Braden Shepherdson <
>> >>> >> >> > > >>>>> braden@chromium.org
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>>>> wrote:
>> >>> >> >> > > >>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>> This mailing list post is, or will shortly
>>be,
>> >>> indexed
>> >>> >> >> > > >>>>> by
>> >>> >> >> > > >>>>>> Google
>> >>> >> >> > > >>>>>>>> and
>> >>> >> >> > > >>>>>>>>>>>>> others. Any newcomers will see the new docs
>>and
>> >>> create
>> >>> >> >> > > >>>>> new
>> >>> >> >> > > >>>>>>>> projects.
>> >>> >> >> > > >>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>> As I mentioned on IRC, existing users are
>> >>>either
>> >>> >> >> > > >>>>> accepting
>> >>> >> >> > > >>>>> or
>> >>> >> >> > > >>>>>>>>> ignoring
>> >>> >> >> > > >>>>>>>>>>>> the
>> >>> >> >> > > >>>>>>>>>>>>> "alpha" warnings that this software is new
>>and
>> >>> under
>> >>> >> >> > > >>>>> heavy
>> >>> >> >> > > >>>>>>>>>>>> development,
>> >>> >> >> > > >>>>>>>>>>>> and
>> >>> >> >> > > >>>>>>>>>>>>> if they want to jump on it early they're
>>going
>> >>>to
>> >>> have
>> >>> >> >> > > >>>>> to
>> >>> >> >> > > >>>>>> expect
>> >>> >> >> > > >>>>>>>>> some
>> >>> >> >> > > >>>>>>>>>>>> pain.
>> >>> >> >> > > >>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>> That said, I don't really know of any better
>> >>>way
>> >>> to
>> >>> >> >> > > >>>>> socialize
>> >>> >> >> > > >>>>>>> it.
>> >>> >> >> > > >>>>>>>> Is
>> >>> >> >> > > >>>>>>>>>>>> there
>> >>> >> >> > > >>>>>>>>>>>>> anywhere where a brief blog post on this
>>would
>> >>> make
>> >>> >> >> > > >>>>> sense?
>> >>> >> >> > > >>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>> I don't know how many people are using these
>> >>> tools and
>> >>> >> >> > > >>>>> not
>> >>> >> >> > > >>>>> on
>> >>> >> >> > > >>>>>>> the
>> >>> >> >> > > >>>>>>>>>>>> mailing
>> >>> >> >> > > >>>>>>>>>>>>> list, though certainly some turn up on IRC
>> >>> >> occasionally.
>> >>> >> >> > > >>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>> Braden
>> >>> >> >> > > >>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>> On Tue, Apr 9, 2013 at 11:24 AM, Filip Maj
>> >>> >> >> > > >>>>> <fil@adobe.com>
>> >>> >> >> > > >>>>>>> wrote:
>> >>> >> >> > > >>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
>> >>> existing
>> >>> >> >> > > >>>>> users?
>> >>> >> >> > > >>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>> >>> >> >> > > >>>>> braden@chromium.org
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>>>> wrote:
>> >>> >> >> > > >>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>> I've just pushed a change to the future
>> >>>branch
>> >>> that
>> >>> >> >> > > >>>>> changes
>> >>> >> >> > > >>>>>>> the
>> >>> >> >> > > >>>>>>>>>>>> directory
>> >>> >> >> > > >>>>>>>>>>>>>>> structure to:
>> >>> >> >> > > >>>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>> app/
>> >>> >> >> > > >>>>>>>>>>>>>>>  merges/
>> >>> >> >> > > >>>>>>>>>>>>>>>      android/
>> >>> >> >> > > >>>>>>>>>>>>>>>      ios/
>> >>> >> >> > > >>>>>>>>>>>>>>>  www/
>> >>> >> >> > > >>>>>>>>>>>>>>>  config.xml
>> >>> >> >> > > >>>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>> As was discussed at our video conference
>> >>> meeting a
>> >>> >> >> > > >>>>> couple of
>> >>> >> >> > > >>>>>>>> weeks
>> >>> >> >> > > >>>>>>>>>>>> ago,
>> >>> >> >> > > >>>>>>>>>>>>>>> this has a number of advantages:
>> >>> >> >> > > >>>>>>>>>>>>>>> - config.xml is no longer in the www/
>> >>>directory
>> >>> >> >> > > >>>>>>>>>>>>>>> - One can easily version control the whole
>> >>>app/
>> >>> >> >> > > >>>>> directory,
>> >>> >> >> > > >>>>>> and
>> >>> >> >> > > >>>>>>>> get
>> >>> >> >> > > >>>>>>>>>>>> their
>> >>> >> >> > > >>>>>>>>>>>>>>> web assets, merges and so on into the
>>repo.
>> >>> >> >> > > >>>>>>>>>>>>>>> - That repo can contain additional
>> >>>information:
>> >>> a
>> >>> >> >> > > >>>>> README.md,
>> >>> >> >> > > >>>>>>>>>>>> supplementary
>> >>> >> >> > > >>>>>>>>>>>>>>> documentation, tests, whatever. The CLI
>>will
>> >>> ignore
>> >>> >> >> > > >>>>> anything
>> >>> >> >> > > >>>>>>>>>>>> outside of
>> >>> >> >> > > >>>>>>>>>>>>>>> the
>> >>> >> >> > > >>>>>>>>>>>>>>> merges and www directories.
>> >>> >> >> > > >>>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>> The downside is that this is a breaking
>> >>>change:
>> >>> >> >> > > >>>>> running
>> >>> >> >> > > >>>>> the
>> >>> >> >> > > >>>>>>> new
>> >>> >> >> > > >>>>>>>>>>>> version of
>> >>> >> >> > > >>>>>>>>>>>>>>> the tools on an old project will fail
>>(but I
>> >>> think
>> >>> >> in
>> >>> >> >> > > >>>>> a
>> >>> >> >> > > >>>>>>> harmless
>> >>> >> >> > > >>>>>>>>>>>> way)
>> >>> >> >> > > >>>>>>>>>>>>>>> until
>> >>> >> >> > > >>>>>>>>>>>>>>> you rearrange the directories. You can do
>> >>>that
>> >>> with
>> >>> >> >> > > >>>>> the
>> >>> >> >> > > >>>>>>>> following
>> >>> >> >> > > >>>>>>>>>>>>>>> commands:
>> >>> >> >> > > >>>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>> $ mkdir app
>> >>> >> >> > > >>>>>>>>>>>>>>> $ mv www/config.xml app
>> >>> >> >> > > >>>>>>>>>>>>>>> $ mv www app
>> >>> >> >> > > >>>>>>>>>>>>>>> $ mv merges app
>> >>> >> >> > > >>>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>> All docs and tests are updated as well.
>>Any
>> >>> problems
>> >>> >> >> > > >>>>> should
>> >>> >> >> > > >>>>>> be
>> >>> >> >> > > >>>>>>>>>>>> reported on
>> >>> >> >> > > >>>>>>>>>>>>>>> JIRA and assigned to me.
>> >>> >> >> > > >>>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>> Braden
>> >>> >> >> > > >>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>> --
>> >>> >> >> > > >>>>>>>> Timothy Kim
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>
>> >>> >> >> > >
>> >>> >> >> > >
>> >>> >> >> >
>> >>> >> >>
>> >>> >>
>> >>>
>> >>
>> >>
>>
>>


Mime
View raw message