Move speex into the chrome repo

Move speex into the chrome repo

This is a smaller library that is always checked out and depsed in. It seems there is no particular reason for it to be in a separate repo other than it makes changes more difficult.

Committed: https://crrev.com/ef5e3c5c987cbf9fbd1a37743094847580d3e821
Cr-Commit-Position: refs/heads/master@{#297781}

[brettw, 2014-09-26 18:11:57]

brettw@chromium.org changed reviewers:
+ phajdan.jr@chromium.org

[Paweł Hajdan Jr., 2014-09-26 18:53:46]

phajdan.jr@chromium.org changed reviewers:
+ agable@chromium.org, maruel@chromium.org

[Paweł Hajdan Jr., 2014-09-26 18:53:46]

LGTM

If possible please wait for M-A or Aaron to also take a look. I think they know
gclient best.

[M-A Ruel, 2014-09-26 19:10:42]

maruel@chromium.org changed reviewers:
+ borenet@chromium.org

[M-A Ruel, 2014-09-26 19:10:43]

I think it's eric that wrote the code that handles this situation but I want to
double check first.

[borenet, 2014-09-26 19:18:21]

On 2014/09/26 19:10:43, M-A Ruel wrote:
> I think it's eric that wrote the code that handles this situation but I want
to
> double check first.

So my guess is that, if --delete-unversioned-trees is used, "gclient sync" will:
1. Add all of these files when it updates src
2. Process the rest of the DEPS
3. Delete third_party/speex at the end.

Things will fail, but on the next sync, gclient should fix itself.

[brettw, 2014-09-26 19:20:12]

On 2014/09/26 19:18:21, borenet wrote:
> On 2014/09/26 19:10:43, M-A Ruel wrote:
> > I think it's eric that wrote the code that handles this situation but I want
> to
> > double check first.
> 
> So my guess is that, if --delete-unversioned-trees is used, "gclient sync"
will:

Do people use this flag? I do see a "you can delete this directory" when I sync
with this patch. I can send a PSA not to do this (and you can generally figure
it out yourself -- this has happened to me before), but I wouldn't want the bots
to all go crazy.

[borenet, 2014-09-26 19:22:54]

On 2014/09/26 19:20:12, brettw wrote:
> On 2014/09/26 19:18:21, borenet wrote:
> > On 2014/09/26 19:10:43, M-A Ruel wrote:
> > > I think it's eric that wrote the code that handles this situation but I
want
> > to
> > > double check first.
> > 
> > So my guess is that, if --delete-unversioned-trees is used, "gclient sync"
> will:
> 
> Do people use this flag? I do see a "you can delete this directory" when I
sync
> with this patch. I can send a PSA not to do this (and you can generally figure
> it out yourself -- this has happened to me before), but I wouldn't want the
bots
> to all go crazy.

I assume it's rare that a human uses the flag, but I wouldn't be surprised if
most or all of the bots use it.

[brettw, 2014-09-26 19:24:19]

What do we think the right approach to landing this is then? Land it some
evening with tree closed, wait for cycle, force another patch for a rebuild,
then open the tree?

[borenet, 2014-09-26 19:51:05]

On 2014/09/26 19:24:19, brettw wrote:
> What do we think the right approach to landing this is then? Land it some
> evening with tree closed, wait for cycle, force another patch for a rebuild,
> then open the tree?

I don't know what the best practice should be, but that's pretty much what we
did for Skia's transition.  Maybe even make --delete-unversioned-trees a no-op
during that time period?

[agable, 2014-09-29 08:59:50]

agable@chromium.org changed reviewers:
+ hinoka@chromium.org

[agable, 2014-09-29 08:59:51]

Even if we can't make gclient smart enough for this, we should be able to make
bot_update smart enough for this. It can handle it just fine on patch
application (specifically because it applies to patch to DEPS first), but I
expect bot_update will still run into problems when it just syncs chromium and
gets the speex files at the same time as the DEPS file. +hinoka for more.

[brettw, 2014-09-30 04:15:56]

Any update on this? Try runs are green so tomorrow I'm going to assume this
works OK unless somebody tells me not.

[agable, 2014-09-30 14:24:45]

On 2014/09/30 04:15:56, brettw wrote:
> Any update on this? Try runs are green so tomorrow I'm going to assume this
> works OK unless somebody tells me not.

As I mentioned, the fact that t

[agable, 2014-09-30 14:24:46]

On 2014/09/30 04:15:56, brettw wrote:
> Any update on this? Try runs are green so tomorrow I'm going to assume this
> works OK unless somebody tells me not.

As I mentioned, the fact that t

[agable, 2014-09-30 14:27:07]

On 2014/09/30 04:15:56, brettw wrote:
> Any update on this? Try runs are green so tomorrow I'm going to assume this
> works OK unless somebody tells me not.

As I mentioned, the fact that the try runs are green doesn't actually mean the
main waterfall will be -- the trybots apply the patch to DEPS before doing
anything else, so they clean out the old speex checkout before populating it
again with the rest of the patch. That won't happen on the main waterfall --
there, the bots will try to sync forward, and end up trying to check out real
files on top of the speex repo before they've evaluated the DEPS file and
realized that it should go away.

Two solutions right now:
a) somehow teach bot_update to handle this (hard, not even sure if it's worth
it, not even sure how bot_update would do it, honestly).
b) wait for a quiet time, commit, and force a rebuild immediately afterwards.

[Paweł Hajdan Jr., 2014-10-01 11:37:15]

On 2014/09/30 14:27:07, agable wrote:
> Two solutions right now:
> a) somehow teach bot_update to handle this (hard, not even sure if it's worth
> it, not even sure how bot_update would do it, honestly).
> b) wait for a quiet time, commit, and force a rebuild immediately afterwards.

I'm leaning towards b)

Happy to land this for you in EMEA, let me know what you think.

[brettw, 2014-10-01 16:20:14]

On 2014/10/01 11:37:15, Paweł Hajdan Jr. wrote:
> On 2014/09/30 14:27:07, agable wrote:
> > Two solutions right now:
> > a) somehow teach bot_update to handle this (hard, not even sure if it's
worth
> > it, not even sure how bot_update would do it, honestly).
> > b) wait for a quiet time, commit, and force a rebuild immediately
afterwards.
> 
> I'm leaning towards b)
> 
> Happy to land this for you in EMEA, let me know what you think.

I agree. I'll try to land it tonight PST, and if I don't get a chance, maybe
Pawel can try while I'm sleeping.

[brettw, 2014-10-02 04:14:49]

The CQ bit was checked by brettw@chromium.org

[commit-bot: I haz the power, 2014-10-02 04:15:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/608853002/20001

[commit-bot: I haz the power, 2014-10-02 04:20:01]

Committed patchset #2 (id:20001) as 4c91dbf90c03659e24b069509e5aef8e4d1d2070

[commit-bot: I haz the power, 2014-10-02 04:20:39]

Patchset 2 (id:??) landed as
https://crrev.com/ef5e3c5c987cbf9fbd1a37743094847580d3e821
Cr-Commit-Position: refs/heads/master@{#297781}

[brettw, 2014-10-02 05:04:42]

For the record, the answer to "what will happen" is that gclient does delete the
directory and the bot goes red on the runhooks step (since a .gypi is missing).
But a whitespace change or a force build puts the bot back into a good state and
everything can continue.