Bug 88680
| Summary: | [meta] remove ORWT when it's no longer needed / used | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Dirk Pranke <dpranke> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | abarth, ap, dbates, eric, fpizlo, ojan, ossy, rafael.lobo, rakuco |
| Priority: | P2 | Keywords: | NRWT |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 88841, 37956, 38756, 64645, 65268, 65834, 66308, 67777, 69118, 69310, 69360, 71634, 71688, 72489, 73843, 76957, 78127, 85446, 88702, 88875, 89108 | ||
| Bug Blocks: | 64491 | ||
Dirk Pranke
This is a tracking bug to identify all of the issues left with NRWT that keep people using ORWT. Once all of those are fixed, we should remove old-run-webkit-tests to reduce the code base size and cost of maintaining two tools.
There are currently two other NRWT tracking-related bugs,
bug 64491 ("Polish NRWT until it shines") which I think is a tracking bug for NRWT-related bugs generally, and
bug 34948 ("switch all webkit.org bots over") which is very specific (and currently all bots but apple win have switched over, I believe).
I would like to track all bugs that block removing ORWT here, and all non-blocking bugs can remain on bug 64491, if that's okay.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Filip Pizlo
Shouldn't bug 64491 block this one and not the other way around?
The point is, so long as NRWT is unpolished, it seems necessary to continue to support ORWT, which is at least more democratically hackable.
Ojan Vafai
(In reply to comment #1)
> Shouldn't bug 64491 block this one and not the other way around?
>
> The point is, so long as NRWT is unpolished, it seems necessary to continue to support ORWT, which is at least more democratically hackable.
Not really sure what you're trying to say here. Ignoring the specific definition of "polish", it makes sense to split the bug list into "must haves" and "nice to haves". This is the must haves list. The other one is the nice to haves.
Filip Pizlo
(In reply to comment #2)
> (In reply to comment #1)
> > Shouldn't bug 64491 block this one and not the other way around?
> >
> > The point is, so long as NRWT is unpolished, it seems necessary to continue to support ORWT, which is at least more democratically hackable.
>
> Not really sure what you're trying to say here. Ignoring the specific definition of "polish", it makes sense to split the bug list into "must haves" and "nice to haves". This is the must haves list. The other one is the nice to haves.
We should not remove ORWT until the nice-to-haves that are already present in ORWT are ported to NRWT.
The biggest "nice-to-have" in ORWT is that it is hackable.
NRWT is not hackable. It's a giant pile of complex code.
This can be fixed, and I was under the, perhaps mistaken, impression that bug 64491 was tracking this work.
Dirk Pranke
Replying out of order to your different points ...
(In reply to comment #3)
> We should not remove ORWT until the nice-to-haves that are already present in ORWT are ported to NRWT ... I was under the, perhaps mistaken, impression that bug 64491 was tracking this work.
Adam can say for certain what the intent of bug 64491 was.
However, in my vocabulary, "nice-to-haves" don't truly block things, only "must-haves" do. We also often using blocking bugs in bugzilla as umbrellas for grouping, and I think that's what we were (and are still) doing in bug 64491. Perhaps it would be more useful to create an NRWT keyword or something?
To perhaps be clearer about what I'm trying to address with this bug, though, I should say that removing ORWT is not a goal in and of itself. I have two other goals in mind:
1) people who are running NRWT (not hacking on it) should not feel like they can't use it or need to use ORWT because NRWT is missing something. This is clearly not yet true, and won't be true until the bugs I've listed so far as blockers are fixed.
2) People who want to make changes to the tools (NRWT but also DRT, WTR, etc.) can do so without feeling like we also need to add support for things to ORWT or worry about breaking ORWT.
We've already started down the path with (2), since ORWT doesn't support reftests and we have no plans to add that support. I can give other examples if that's useful.
It would be good to establish if we think (2) is already true today or not.
If (1) and (2) are true, then I don't care if we delete ORWT from the tree or not because it will not be imposing any cost to me or most others by keeping it around.
[ If it would help to change the subject of this bug somehow to make that clearer, I am open to suggestions. ]
> The biggest "nice-to-have" in ORWT is that it is hackable. NRWT is not hackable. It's a giant pile of complex code.
So, to restate what I think you're saying, you would like NRWT to be more hackable before you consider (2) to be true, right?
Dirk Pranke
resetting the owner in case someone else wants to take a look, as these bugs aren't on my immediate to-do list.
Csaba Osztrogonác
There is no ORWT long long time ago in trunk.