4.2 Sprint

Subscribe to this page so you don't miss updates!

1. Date and location

The sprint will be held at the Google office in Mountain View, California, March 10-12. The address is: 501 Ellis Street, Mountain View, CA (see below for a Google maps link)

Plan to arrive on Friday between 9:00 and 10:00 AM.

Location point of contact: Martin von Zweigbergk (martinvonz), martinvonz@google.com

If you need a formal invitation for visa purpose, contact the person above.

2. Arrival Logistics

We are going to be at 501 Ellis Street, Mountain View, CA. We are going to be in the north west corner of the building. The entrance is on the west side of the building. The doors will probably be locked, but we'll check frequently in the morning if anyone is waiting. Otherwise just ping us (there's an open GoogleGuest wifi), for example martinvonz@google.com on hangouts or 650-814-8116. Worst case, knock on the windows

There is plenty of parking on the south side of the building.

The best light rail stop is Middlefield, which is a 7-minute walk from the office.

3. Attendance

Everyone is welcome from core developer to aspiring contributor. Attending a Mercurial sprint is usually a good way to kickstart your contributions are you'll get a large amount of help available for 3 days.

4. Sponsors

We need funds to pay flights and hotel for a few independent contributors.

Recent sprints sponsoring budgets were around $10,000.

Sponsoring Company:

• Google
• Facebook

• Please offer your sponsoring

Sponsor point of contact: Please offer your service

5. Meals

Having Food delivered for Lunch is usually preferred as it help keeping the timing under control. Dinner is usually taken outside to help people cool off after a day of work.

(Don't forget vegetarian and vegan option)

Meal point of contact: Please offer your service

6. Possible Topics

Important things we want to discuss: (add your own)

6.1. Steering Committee and Donations

We really need a clear (and fast) picture here. It's been frustrating that we (Bitbucket) have money to donate but nobody seems to know what to do.

6.2. friendlyhg

• We really need to do this, soon.

• Add options to core, make friendlyhg primarily an hgrc file instead of extension?

• One of the most important (KyleLippincott's opinion): a way for users to sanely enable --check on update by default.

• Direction of patch in "hg revert -r -i"
• Getting "hg rebase -d @ -r 'draft()' --evolve"

• Homepage update (JunWu's opinion): Features better than git like revsets, templates, phases should be visible directly from homepage.

6.3. Python 3

• Making hacking on py3 compat easier
• Making setup.py work
• Using type hints
• CI

6.4. SHA-1 Replacement

• SHA-1 collisions are now attainable. We need to move away from SHA-1 for content indexing in the name of security.
• bundled largefiles extension uses SHA-1 of file contents directly (hglf, too?), and this causes unintentional unification of largefiles at checking them out

• See SHA1TransitionPlan for more

6.5. TLS Libraries

• urllib3 can use pyOpenSSL and do modern TLS on old Pythons
• We could also use pyOpenSSL directly
• Should we investigate this?

6.6. Summer of Code

• We need mentors and ideas.

6.7. Interaction between freeze and running from @

• Facebook builds and deploys @ to all its users; the end of the 4.1 freeze was painful for us, because everything broke. What can Facebook do to ensure that the end of the freeze isn't painful for us?
• Side topic - we have a huge dataset about use of Mercurial at Facebook; is there any data that the community would like us to collect for you?

6.8. Corruption on Windows

• Bitbucket is seeing what looks like a correlation between repo revlog corruption and Windows-based projects on both old and new repos.
• What can Bitbucket do to help address this?

6.9. Evolution

• rebasing evolution changesets CEDRebase

• Small task force to tighten the list for CEDVocabulary
• Obsmarker Exchange
  • Making it faster
  • Making it more user friendly (in particular pruning)

6.10. Enhanced repoview

• New "archived" phase - Source of truth of "computehidden"
• Meta History - See how DAG, bookmarks, obsmarks, phases change over time
• UI: --view=metarev:phasename
  • --view=previousrev to see previous state
  • --view=archived is equivalent to --hidden today
  • "phase --archived X" will be an implementation of "strip X"

• See this mail for the initial idea

• Slide: http://files.lihdd.net/repoview.pdf

• Code (POC, very hacky but somehow works): https://bitbucket.org/quark-zju/hg-draft/commits/5f035f5e7

6.11. Versioning Scheme

Mercurial version numbers don't really mean anything. Can we switch to a date-based versioning scheme so when people see the version "number" in command output they have an idea how old their Mercurial client is?

6.12. Local Storage Optimizations

Facebook has been experimenting with some form of pack files. Indygreg has ideas for improving revlogs. There's also PackedRepoPlan. Jun has ideas for improving changelog storage/indexing, linkrev storage, etc. There is also a desire to facilitate reader locks.

Let's have a discussion about the future of local storage.

6.13. Configuration Consolidation

• See ConfigConsolidationPlan

6.14. Topic 1

• (Please copy this section)

• sub topic 1.a

• sub topic 1.b

7. Sprint Notes

Live Notes (drop the anti spam part): https://public.etherpad-mozilla.org/p/sprint-hg4.2-NOSPAMREMOVETHATLASTPART

Collected to: 4.2sprint/Notes

8. Photo!

I'm sharing 360-degree photos in "The last night of Mercurial 4.2 sprint in Mountain View" (by foozy)

---

CategoryMeetings