Week One

[Eric Seidel]

The repository seems to be mostly up and working and commits are coming in.

I suspect many of you have already reviewed the WebKit -> Blink
developer transition cheatsheet:
http://www.chromium.org/blink/conversion-cheatsheet


Our focus this first week is to make sure everyone gets up and running
smoothly. Our awesome infrastructure folks have gotten us most of the
way there, but there is also some additional tooling configuration,
and general acclimation left to work through. :)

I would encourage folks to hold off on large functional changes until
we have everything up and we know that all the relevant test bots are
functioning.


We also have a bunch of dead-code removal changes which will be
landing shortly once we know the bots are up enough to catch any
accidental breakages.

Thanks for your patience.

[Thiago Farina]

On Wed, Apr 3, 2013 at 10:17 PM, Eric Seidel <ese...@chromium.org> wrote:
> We also have a bunch of dead-code removal changes which will be
> landing shortly once we know the bots are up enough to catch any
> accidental breakages.
>

Are the Blink bots running on
https://chromium-build.appspot.com/p/chromium/console? Otherwise where
they will be running?

--
Thiago

[Dirk Pranke]

Note that the 'fetch' command (and the recommended git+svn "NewGit" config) is still not working ... this is a known issue and we're actively working on it.

[Eric Seidel]

The bots all already exist. The question is making sure that Chromium
DEPS is moved to use src.chromium.org/blink instead of svn.webkit.org,
and making sure they're clean-ish before we go crazy. :)

[Dirk Pranke]

On Wed, Apr 3, 2013 at 6:21 PM, Thiago Farina <tfa...@chromium.org> wrote:

We will have a chromium.blink waterfall that will replace the chromium.webkit waterfall. It's not up yet.

-- Dirk

 

--
Thiago

[Stephen White]

Once all the cruft has been removed, are we planning to trim the git repo to exclude those directories?  I'm thinking of the non-Chromium LayoutTests in particular.  This would make the initial sync much smaller/faster.

Stephen

[Eric Seidel]

We've discussed with the infrastructure folks the idea of re-writing
git history to remove all files that Chromium has never used. We'll
have to wait until the removals calm down, as you suggest.

[Dirk Pranke]

I was just talking to the infrastructure folks about this. We have several ideas for both making the initial sync much smaller and faster, and for trimming the repo. Stay tuned :).

-- Dirk

[Adam Barth]

I'm interested what you all have in mind.  If we're going to do a history re-write (e.g., filter-branch), we might want to do it at the same time as we move to src/blink since that will require people to do a fresh clone anyway (unless gclient is smarter about repo moves that I remember).

Adam

[Stephen White]

You can specify an --ignore-paths argument when building the git mirror, to specify paths to be excluded from the repo.  Something like this:

git svn clone svn://svn.chromium.org/blink --ignore-paths 'LayoutTests/platform/(^do|^not|^want)' blink

Stephen

[Jonathan Dixon]

On Friday, 5 April 2013, Adam Barth <aba...@chromium.org> wrote:
> I'm interested what you all have in mind.  If we're going to do a history re-write (e.g., filter-branch), we might want to do it at the same time as we move to src/blink since that will require people to do a fresh clone anyway (unless gclient is smarter about repo moves that I remember).

+1. And again, remember not everyone impacted uses gclient. repo for example, is not smart enough to avoid a fresh clone when the checkout location moves.

[Dirk Pranke]

On Fri, Apr 5, 2013 at 10:25 PM, Adam Barth <aba...@chromium.org> wrote:

I'm interested what you all have in mind.

The two first things we've been talking about are providing a faster way to bootstrap the initial checkout (it turns out git spends a lot of time computing the deltas for the repo, and so it should be much faster to just retrieve a pre-created bare repo and then checkout and fetch any updates), and to provide a "shallow" copy (only the last N revisions) for those people that might not want the full history; obviously we'd still make the full history available.

 

 If we're going to do a history re-write (e.g., filter-branch), we might want to do it at the same time as we move to src/blink since that will require people to do a fresh clone anyway (unless gclient is smarter about repo moves that I remember).

It may well make more sense to do a history rewrite rather than the shallow approach I just mentioned.

We can probably also automate the move to src/blink so that people don't have to recreate the checkouts (either by making gclient aware of the move or by doing something else) and we don't hammer the servers again :).

A couple other longer-term things to be aware of are that I'm working to reduce the number of cross-platform baselines we need (hopefully we can get down to one copy for the vast majority of of pixel tests), and we're hoping to replace a lot of the existing pixel tests with ref tests from the w3c; both of these will make a *very* big impact on the size of the checkout, since the LayoutTests are now 95% of the checkout :).

We may also eventually want to move the .pngs out of the repo altogether (possibly replacing them with placeholder checksum files that reference the PNGs in a separate repo or some form of content-addressed storage), but this idea is less appealling than just getting rid of them where possible, for fairly obvious reasons.

Other ideas are also welcomed, 

-- Dirk

[Ojan Vafai]

On Sat, Apr 6, 2013 at 8:02 PM, Dirk Pranke <dpr...@chromium.org> wrote:

A couple other longer-term things to be aware of are that I'm working to reduce the number of cross-platform baselines we need (hopefully we can get down to one copy for the vast majority of of pixel tests), and we're hoping to replace a lot of the existing pixel tests with ref tests from the w3c; both of these will make a *very* big impact on the size of the checkout, since the LayoutTests are now 95% of the checkout :).

We may also eventually want to move the .pngs out of the repo altogether (possibly replacing them with placeholder checksum files that reference the PNGs in a separate repo or some form of content-addressed storage), but this idea is less appealling than just getting rid of them where possible, for fairly obvious reasons.

+1. I think your limited time is much better spent reducing the number of pixel tests / pngs in the tree than it is trying to trim down the repo. The former would be a an enormous improvement to the team's forward velocity and in reducing the frustrations of working on patches that affect pixel test results. The latter is valuable, but much less so IMO.