Pick a fixed Clang revision for Windows now that we have an LKGR ASan builder

Pick a fixed Clang revision for Windows now that we have an LKGR ASan builder
This way, the LKGR builder and the developers who want to try ASan (or just Clang) on Windows won't get a broken Clang revision.

The FYI bots got LLVM_WIN_REVISION=HEAD in r276301 so won't be affected.

BUG=82385, 345874
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=276366

[Timur Iskhodzhanov, 2014-06-10 10:14:48]

See https://codereview.chromium.org/326873002/ for the master.fyi part of the
change

[hans, 2014-06-10 15:45:36]

I still worry a little about moving to a fixed revision essentially just for the
sake of one builder.

But if we make up for it by updating the revision really frequently (maybe in
some semi-automated way), I think it's OK.

lgtm

[Reid Kleckner, 2014-06-10 17:27:24]

https://codereview.chromium.org/320383004/diff/1/tools/clang/scripts/update.py
File tools/clang/scripts/update.py (right):

https://codereview.chromium.org/320383004/diff/1/tools/clang/scripts/update.p...
tools/clang/scripts/update.py:20: LLVM_WIN_REVISION = '210505'
This can be:
LLVM_WIN_REVISION = os.environ.get('LLVM_WIN_REVISION', '210505')

[Timur Iskhodzhanov, 2014-06-11 08:48:32]

> But if we make up for it by updating the revision really
> frequently (maybe in some semi-automated way),
> I think it's OK.

I think we should totally roll Clang/Win much more often than on other OSes. 
Personally I'm fine for roll of any Clang revision if the ASan/Win FYI bot is
green enough on it.

https://codereview.chromium.org/320383004/diff/1/tools/clang/scripts/update.py
File tools/clang/scripts/update.py (right):

https://codereview.chromium.org/320383004/diff/1/tools/clang/scripts/update.p...
tools/clang/scripts/update.py:20: LLVM_WIN_REVISION = '210505'
Done, ditto for LLVM_REPO_URL below.

[Timur Iskhodzhanov, 2014-06-11 08:48:37]

The CQ bit was checked by timurrrr@chromium.org

[commit-bot: I haz the power, 2014-06-11 08:51:59]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/timurrrr@chromium.org/320383004/20001

[Timur Iskhodzhanov, 2014-06-11 12:19:32]

The CQ bit was unchecked by timurrrr@chromium.org

[Timur Iskhodzhanov, 2014-06-11 12:19:49]

The CQ bit was checked by timurrrr@chromium.org

[commit-bot: I haz the power, 2014-06-11 12:21:37]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/timurrrr@chromium.org/320383004/20001

[commit-bot: I haz the power, 2014-06-11 12:24:04]

Change committed as 276366

[Nico, 2014-06-12 19:42:32]

as mentioned on the thread, not lgtm

we should have only a single clang revision mentioned in update scripts.

if you need some special case for win asan for now, put the special case
somewhere that doesn't look like a general place

[Timur Iskhodzhanov, 2014-06-12 20:01:13]

This isn't a general place, is it?

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[chromium-reviews, 2014-06-12 20:03:23]

It is.  I believe Nico and Hans want to kill update.sh in favor of
update.py on all platforms.


On Thu, Jun 12, 2014 at 1:01 PM, Timur Iskhodzhanov <timurrrr@chromium.org>
wrote:

> This isn't a general place, is it?
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Timur Iskhodzhanov, 2014-06-12 20:09:47]

The variable is already named LLVM_WIN_REVISION, right?

Using the same revision number as the "stable" OSes doesn't make sense to
me until we declare Clang-for-Windows "production quality".  The "beta"
progress on Windows shouldn't be blocked by "release" requirements on other
OSes.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2014-06-12 20:38:14]

On Thu, Jun 12, 2014 at 1:09 PM, Timur Iskhodzhanov <timurrrr@chromium.org>
wrote:

> The variable is already named LLVM_WIN_REVISION, right?
>
> Using the same revision number as the "stable" OSes doesn't make sense to
> me until we declare Clang-for-Windows "production quality".  The "beta"
> progress on Windows shouldn't be blocked by "release" requirements on other
> OSes.
>

I agree! And so does everyone else apparently, as all the bots have a
"ignore this revision, just use HEAD" option set.

From what I understand, you don't want to use head for win/asan as that's
not stable enough for CF. So CF should do some pinning thing. (Or CF
shouldn't use win/asan yet, given that we don't consider regular win/clang
to be generally usable.)

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Timur Iskhodzhanov, 2014-06-12 20:49:53]

There are not just "CF bot and everything else", right?

We have
a) FYI bots purposed to continuously try the latest Clang on Chromium tests
so we can catch regressions and bugfixes early
b) The Clang developers (us) who want to use the freshest Clang too
c) LKGR bot that should use the reasonably-new-but-stable Clang revision to
cook the fresh Chromium code for CF triage
d) Early adopters who want to try reasonably-new-but-stable Clang revision
locally to e.g. repro CF reports or whatnot

Since (a) and (b) are probably the only two usecases that really need HEAD
and (hopefully) we'll have more early adopters that (a) and (b) combined
really soon, I think the default should be "reasonably-new-but-stable".

Also, pinning a revision on the LKGR master sounds like something that'd
require a master restart for each roll?

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2014-06-12 21:05:30]

As mentioned on the lkgr review, I don't think this should be on lkgr yet.
For (d), this is experimental and hasn't been widely announced, so using an
unpinned version there is fine too.

(Note: "win/asan specific" means having the revision in a
"win_asan_revision" variable and defaulting to head unless some
"USE_PINNED_WIN_ASAN_CLANG" thingy is set in which case you'd use that
variable, so roughly just what you have now except with defaults reversed.
I'm not asking for some huge change here.)


On Thu, Jun 12, 2014 at 1:49 PM, Timur Iskhodzhanov <timurrrr@chromium.org>
wrote:

> There are not just "CF bot and everything else", right?
>
> We have
> a) FYI bots purposed to continuously try the latest Clang on Chromium
> tests so we can catch regressions and bugfixes early
> b) The Clang developers (us) who want to use the freshest Clang too
> c) LKGR bot that should use the reasonably-new-but-stable Clang revision
> to cook the fresh Chromium code for CF triage
> d) Early adopters who want to try reasonably-new-but-stable Clang revision
> locally to e.g. repro CF reports or whatnot
>
> Since (a) and (b) are probably the only two usecases that really need HEAD
> and (hopefully) we'll have more early adopters that (a) and (b) combined
> really soon, I think the default should be "reasonably-new-but-stable".
>
> Also, pinning a revision on the LKGR master sounds like something that'd
> require a master restart for each roll?
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2014-06-16 15:21:00]

I'll revert this by eod.


On Thu, Jun 12, 2014 at 2:05 PM, Nico Weber <thakis@chromium.org> wrote:

> As mentioned on the lkgr review, I don't think this should be on lkgr yet.
> For (d), this is experimental and hasn't been widely announced, so using an
> unpinned version there is fine too.
>
> (Note: "win/asan specific" means having the revision in a
> "win_asan_revision" variable and defaulting to head unless some
> "USE_PINNED_WIN_ASAN_CLANG" thingy is set in which case you'd use that
> variable, so roughly just what you have now except with defaults reversed.
> I'm not asking for some huge change here.)
>
>
> On Thu, Jun 12, 2014 at 1:49 PM, Timur Iskhodzhanov <timurrrr@chromium.org
> > wrote:
>
>> There are not just "CF bot and everything else", right?
>>
>> We have
>> a) FYI bots purposed to continuously try the latest Clang on Chromium
>> tests so we can catch regressions and bugfixes early
>> b) The Clang developers (us) who want to use the freshest Clang too
>> c) LKGR bot that should use the reasonably-new-but-stable Clang revision
>> to cook the fresh Chromium code for CF triage
>> d) Early adopters who want to try reasonably-new-but-stable Clang
>> revision locally to e.g. repro CF reports or whatnot
>>
>> Since (a) and (b) are probably the only two usecases that really need
>> HEAD and (hopefully) we'll have more early adopters that (a) and (b)
>> combined really soon, I think the default should be
>> "reasonably-new-but-stable".
>>
>> Also, pinning a revision on the LKGR master sounds like something that'd
>> require a master restart for each roll?
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Timur Iskhodzhanov, 2014-06-16 15:34:00]

Reid, can you please work with Nico on a solution that works well for all
the parties involved?
I'm sorry I couldn't finish this as I got sick after we talked last time...

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2014-06-17 19:38:21]

A revert of this CL has been created in
https://codereview.chromium.org/342533002/ by thakis@chromium.org.

The reason for reverting is: This was landed despite an explicit "not lgtm".

[chromium-reviews, 2014-06-17 20:26:42]

I was also sick so I didn't do anything yesterday.  I'm still digging
myself out of email backlog.


On Mon, Jun 16, 2014 at 8:33 AM, Timur Iskhodzhanov <timurrrr@chromium.org>
wrote:

> Reid, can you please work with Nico on a solution that works well for all
> the parties involved?
> I'm sorry I couldn't finish this as I got sick after we talked last time...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.