4.6 Sprint

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

1. Date and location

March 2-4 2018 at Google Cambridge.

355 Main Street, Cambridge, MA 02142 United States

Picture of entrance: https://photos.app.goo.gl/3nkRdhI2eKcYYBBP2, sign next to entrance: https://photos.app.goo.gl/kgOC1dSHrdaaeFBW2. Please enter and hang out in there (instead of going left or right towards the receptionists); there's more seats here :). Someone who can let you in should be around by 9am each day.

1.1. Attendance

Everyone is welcome, from core developers to aspiring contributors. We've got room booked for around 30 people, so if you're past person 25 or so to register here maybe check with AugieFackler before making travel arrangements.

1.2. Logistics

Plan to arrive between 9 and 9:30 on Friday morning.

We've got a slack that we're using for slightly-more-real-time communication. Contact AugieFackler if you want to be added to the slack.

2. Possible Topics

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

Notes in 4.6sprint/Notes and Etherpad.

2.1. remotefilelog and partial clone

AugieFackler would like to get remotefilelog (or similar functionality) in core. This obviously requires some careful consideration, so hopefully we can spend some time working that out.

A lot of the discussion revolves around storage of repository data (what the .hg/ directory looks like when partial clones are in play).

2.2. `hg fix`?

Is it worth having another discussion about hg fix? See AutomaticFormattingPlan.

2.3. Google Summer of Code

We are participating under PSF. Need mentors and project ideas.

2.4. Infinitepush and workspaces

indygreg has very nice ideas about using bundle store on servers to replace the forks. The infinitepush extension very much helps us in achieving that. Discussion around what should be the path forward and how to utilize infinitepush extension for various use cases.

2.5. Hiddenness as a revset, not a filter

Someone from FB suggested removing the repo filtering concept and replacing it by revsets (so e.g. plain hg log would default to intersect revisions with the visible() revset). Shortest revision hash prefixes could also be improved to, by default, only considered filtered revisions - maybe could pass revset to shortest? maybe allow specifying a "default" revset that everything filters by (e.g. hidden by default, some companies might want their own definition of "smart", etc.)?

2.6. Oxidation

Let's talk about Rust and OxidationPlan.

2.7. Log aliases / templates / etc

There are some nice log aliases and templates out there that maybe we could ship with the friendly flag (in the same vein as 'hg show').

2.8. Performance tracking and regression process

We are tracking performance both in the CI system and on http://perf.octobus.net/. How do we handle performance regression report, what kind of information do we need to reproduce and fix, who should be in charge of it?

BorisFeld would also like to discuss what is the ideal workflow we should target for performance related patches? Could we ask people to write a new performance test when they fix a performance issue?

2.9. Funding of community projects

There are some community-driven projects that seem interesting and beneficial for the whole community. How do we fund them, prioritize them and give them visibility for them to be successful?

2.10. Stack (definition, workflow)

BorisFeld and PulkitGoyal have recently worked on moving stack definition capabilities into core. The end-goal is to have the possibility to have the same commands no matter how we materialize our stacks, branches, bookmarks, topics, remotenames. The end-goal is to consolidate in core, the good ideas related to the concept of stack. This way we will provide a coherent and efficient way of managing stacks in core.

CategoryMeetings