I also think that the 'knowfailures' can serve as a good place for new contributors.
I don't want to check-in all the failures and leave them unfixed. It's like I don't know which one I will be able to fix and I have a reproduction which can help others.

In D3896#65986, @spectral wrote:

Any updates on this? I'm poking at updating this function in core, and not too excited to have to also modify the copy in evolve that seems to have spawned :/

Thanks @phillco for the review.

In D4053#62855, @av6 wrote:

Are you sure you're not just using hgwebdir_mod? hgweb_mod is for cases when you don't use --web-conf flag, at least that seems to be the logic that hgweb.createapp() uses to pick one of the two modules.

I also have been here a lot of times and I was unable to found what's wrong. Kudos for fixing this.

In D4125#64732, @durin42 wrote:

Seems fine to me, though thinking we should probably spend some time to make sure the sparse and narrow patterns are cross-compatible like this change seems to hope for.

In D4099#64270, @durin42 wrote:

In D4099#64268, @pulkit wrote:

In D4099#64266, @durin42 wrote:

There are non-Google users of narrow at this point (recall we've gotten non-Googler patches), so please publish the temporary migration hack someplace for the benefit of the other users.

(A phabricator review that we immediately abandon would probably be fine, but we should definitely make a note in the relnotes for 4.8)

Yes, we might roll-out narrow with mercurial 4.7 first, so this script will be of great help. (BTW, isn't it just a move of file?)

It's "just" a move, but typically the way we handle these migrations at Google is we write an extension that does one of the following:

1. Hijacks reads for the new file and reads the old file
2. Hijacks reads for the new file if it doesn't exist and moves the new file
   
   we run in mode 1 when we're doing the rollout and might roll back, then switch to mode 2 when we're past the rubicon on the rollout and can finalize the data migration. Once everyone has run the extension in mode 2 for a while, we reap the extension.

In D4099#64266, @durin42 wrote:

There are non-Google users of narrow at this point (recall we've gotten non-Googler patches), so please publish the temporary migration hack someplace for the benefit of the other users.

(A phabricator review that we immediately abandon would probably be fine, but we should definitely make a note in the relnotes for 4.8)

In D2679#64079, @lothiraldan wrote:

In D2679#62662, @pulkit wrote:

These patches were result of a very extensive discussion about what ways we have to start supporting obsmarkers by default. I will like to push these changesets so that we can try these in this cycle. If I don't hear any concern in a week, I will push them.

We made a series with Ryan during the sprint that had the advantage of not requiring to delete obs-markers. I will undust it, rebase it and send it here for making the discussion go forward.

Please add about this config option in the releasenotes page for 4.8 at https://www.mercurial-scm.org/wiki/Release4.8.

Updated the commit message in flight to follow the updated version of patch.

The commit message says you used hg debugdirstate but looking at changes, you used hg files. I think the commit message needs to be updated.

Sorry for the noise. I managed to email it using my personal laptop.