Also Anis, would it please be possible to squash most of these commits into
a few units of standalone work?  Probably best way to do that is create a
new local branch from your old branch point, apply the diffs from
browserify branch, rebase -i them, then push that branch (this way you
don't need to push with force).

-Michal


On Fri, Apr 25, 2014 at 9:30 AM, Michal Mocny <[email protected]> wrote:

>
>
>
> On Fri, Apr 25, 2014 at 12:53 AM, Michal Mocny <[email protected]>wrote:
>
>> TLDR; Ran a bunch of experiments tonight.  I think this is too early to
>> merge into master.  We pointed out several issues in previous threads and
>> seems they were ignored.
>>
>> Few quick comments from trying this:
>> - cordova-js is a new dependency of plugman, and needs to be npm linked
>> to local dev version
>> - Seems we run browserify after each plugin add (possibly due to an
>> auto-prepare?) so creating projects like mobilespec or any mobile chrome
>> app is now *much* slower (measured in minutes)
>>   - Each cordova prepare now takes 6.5s on a very small project :'(
>>
> (reverted changes locally, old prepare takes <0.5s on same project, which
> is still slow!)
>
>
>> Things that are currently found broken:
>> - prepare step fails for my cordova testing application after
>> installing org.apache.cordova.contacts, and
>> - prepare step fails for *all* cca apps because of same error as above,
>> but for chrome.runtime plugin :(
>>   - These issues seem due to js-modules not being browserify-ed properly.
>>  It may be that both are bad modules (?), but it used to work fine!
>>
>> I did get a few apps running fine, so at least we got that going for us ;)
>>
>> Still to do:
>> - track impact tp startup time
>> - see if there aren't any plugins with subtle bugs due to auto-runs
>> behaviour
>>
>> -Michal
>>
>>
>> On Thu, Apr 24, 2014 at 9:34 PM, Andrew Grieve <[email protected]>wrote:
>>
>>> Cool! Does no impact mean that browserify is still not used by
>>> default, or does it mean that it's backward compatible?
>>>
>>> Failing specs sounds like impact...
>>>
>>> And it does look like medic is failing due to browserify-type things:
>>> http://108.170.217.131:8010/waterfall
>>>
>>> Unless you feel like powering through this tonight, I'll probably
>>> revert in the morning so that our continuous build can stay green.
>>>
>>> On Thu, Apr 24, 2014 at 6:06 PM, Brian LeRoux <[email protected]> wrote:
>>> > \o/
>>> >
>>> >
>>> > On Thu, Apr 24, 2014 at 2:30 PM, Anis KADRI <[email protected]> wrote:
>>> >
>>> >> I just merged both browserify branches into master. There should be no
>>> >> impact.
>>> >> Right now most specs pass expect for File, FileTransfer, Media and
>>> Contacts
>>> >> due to some issues with merges/clobbers and I am looking into those.
>>> >>
>>> >> Also, I got rid of the project cache condition in plugman that was
>>> >> preventing iOS frameworks from being added (CB-6441)
>>> >>
>>> >> Anis
>>> >>
>>>
>>
>>
>

Reply via email to