On 21/2/17 4:23 am, Richard Newman wrote:
I'm hoping for a complete diff against m-c; Part 1 is just scaffolding,
IIRC, and it would be nice to see the totality of what's expected to land.
the elm twig has the current state of what we expect to land, not
including the work I mentioned that is remaining.
(I presume you're planning to land rebased commits rather than try to
merge elm with merge commits into m-c, so a PR with that stack on GitHub
would also do the trick.)
Yes - that's what elm has today, and I continue to rebase against
central and pushing to elm. I plan to land this as the multiple patches
on the tip of elm (without a merge commit) rather than squashing them
into one monolithic patch.
Sadly I can't see how to make hg.mozilla.org show a diff between 2
different revisions, and I also can't see how to make reviewboard show a
"collapsed" view of multiple patches, but I didn't look that hard -
YMMV. You could also pull elm locally - it should only have a handful of
revisions that aren't on mozilla-central. I can't push it to github as
we are using hg with the "evolve" extension for this work.
Cheers,
Mark.
FYSA it's Presidents' Day in the US today.
On Sun, Feb 19, 2017 at 10:32 PM -0800, "Mark Hammond"
<[email protected] <mailto:[email protected]>> wrote:
Work has been proceeding well on the desktop bookmark repair work
(bug 1317223
<https://bugzilla.mozilla.org/show_bug.cgi?id=1317223>). The current
status is:
* All current work is on the elm twig
<https://treeherder.mozilla.org/#/jobs?repo=elm>, which is
continuously running the full test suite. This is regularly
being updated against mozilla-central, so no rebasing surprises
are expected.
* Almost all patches have been fully reviewed, with a couple of
exceptions:
o rnewman has a review request on "part 1", which I expect he
will complete soon, and while he might raise some issues
I've no reason to believe they will be difficult to resolve.
o Thom is still working on a couple of patches we've
identified we need - one to prevent multiple requests being
started at the same time from different devices, and another
to ensure we don't repair while in an inconsistent state. I
expect these to be done early this week.
o Kit is working on integration tests, which are proving a
little tricker. If this looks like not being complete this
week we may consider landing without these tests, but treat
the tests as a high-priority after landing.
* The code is setup such that the code which /initiates /a repair
will not ride the trains past Aurora (although the code that
/responds/ will ride the trains)
* The repair process writes detailed event telemetry and is
controlled via a single preference, so we can easily disable the
entire repair process is necessary, and should be able to get
good insights into how successful the repair is.
Our plan is to land this in the next week or so, at which time we
will do the following:
* Update the documentation for the repair process as a guide for
the iOS implementation.
* Arrange to see telemetry for repairs that happen and monitor the
success.
* Work on identified followups
* Tweak the process based on telemetry results
* profit?
Please let me know if there are any questions about this.
Cheers,
Mark
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
