|
Size: 2140
Comment: Adding myself to Sprint
|
Size: 5516
Comment: Add link to etherpad
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| 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. |
|
| Line 21: | Line 23: |
| ||Josef "Jeff" Sipek ||Boston suburbs ||no || || || | ||Boris Feld ||Paris ||no || || Mar 2 - Mar 4 || ||Connor Sheehan || Toronto Area || no || Boston Marriott Cambridge || March 1-5 || ||DannyHooper || SF Bay Area ||no || Boston Marriott Cambridge || Mar 2 - Mar 6 || |
| Line 23: | Line 27: |
| ||DannyHooper || SF Bay Area ||no || Boston Marriott Cambridge || Mar 2 - Mar 6 || | |
| Line 25: | Line 28: |
| ||Josef "Jeff" Sipek ||Boston suburbs ||no || N/A || Mar 3-4 || ||Kevin Bullock ||Saint Paul ||yes ||Le Meridien Cambridge-MIT ||Mar 1 – 5 || ||KyleLippincott || SF Bay Area ||no || Boston Marriott Cambridge || March 1-5 || |
|
| Line 26: | Line 32: |
| ||MattDeVore || SF Bay Area || no || Boston Marriott Cambridge || Mar 2 - Mar 4 || ||Pulkit Goyal || India || yes || Le Meridien Cambridge-MIT || Feb 28 - Mar 5 || ||RodrigoDamazio || SF Bay Area || no || Residence Inn by Marriott Boston Cambridge || Mar 1 - Mar 5 || ||RyanMcElroy || London || no || Kendall Hotel|| Mar 1 – 5 || ||Sean Farley || SF Bay Area || no || || Feb 28 – Mar 6 || |
|
| Line 27: | Line 38: |
| ||Kevin Bullock ||Saint Paul ||yes ||Le Meridien Cambridge-MIT ||Mar 1 – 5 || ||RyanMcElroy || London || no || Kendall Hotel|| Mar 1 – 5 || ||KyleLippincott || SF Bay Area ||no || Boston Marriott Cambridge || March 1-5 || ||Connor Sheehan || Toronto Area || no || Boston Marriott Cambridge || March 1-5 || ||Pulkit Goyal || India || yes || Le Meridien Cambridge-MIT || Feb 28 - Mar 5 || ||MattDeVore || SF Bay Area || no || Boston Marriott Cambridge || Mar 2 - Mar 4 || ||RodrigoDamazio || SF Bay Area || no || Residence Inn by Marriott Boston Cambridge || Mar 1 - Mar 5 || |
=== Logistics === Plan to arrive between 9 and 9:30 on Friday morning. We've got a [[http://hgsprint.slack.com/|slack]] that we're using for slightly-more-real-time communication. Contact AugieFackler if you want to be added to the slack. |
| Line 38: | Line 48: |
| === remotefilelog === | Notes in [[https://public.etherpad-mozilla.org/p/sprint-hg4.6|Etherpad]] === remotefilelog and partial clone === |
| Line 42: | Line 54: |
| A lot of the discussion revolves around storage of repository data (what the .hg/ directory looks like when partial clones are in play). |
|
| Line 44: | Line 58: |
| Is it worth having another discussion about hg fix? | Is it worth having another discussion about hg fix? See AutomaticFormattingPlan. === Google Summer of Code === We are participating under PSF. Need mentors and project ideas. === Infinitepush and workspaces === indygreg has very nice [[https://phab.mercurial-scm.org/D2096#35158|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. === 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.)? === Oxidation === Let's talk about Rust and OxidationPlan. === 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'). === 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? === 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? === 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. |
| Line 46: | Line 96: |
Note:
This page is primarily intended for developers of Mercurial.
4.6 Sprint
Contents
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
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.
Name |
Coming from |
Need funding |
Hotel |
In town dates |
Augie Fackler |
Pittsburgh |
no |
Boston Marriott Cambridge |
Feb 28 - Mar 4 |
Boris Feld |
Paris |
no |
|
Mar 2 - Mar 4 |
Connor Sheehan |
Toronto Area |
no |
Boston Marriott Cambridge |
March 1-5 |
SF Bay Area |
no |
Boston Marriott Cambridge |
Mar 2 - Mar 6 |
|
Durham Goode |
SF |
no |
N/A |
Feb 28 - Mar 5 |
Gregory Szorc |
SF |
no |
Boston Marriott Cambridge |
Mar 1 - Mar 5 |
Josef "Jeff" Sipek |
Boston suburbs |
no |
N/A |
Mar 3-4 |
Kevin Bullock |
Saint Paul |
yes |
Le Meridien Cambridge-MIT |
Mar 1 – 5 |
SF Bay Area |
no |
Boston Marriott Cambridge |
March 1-5 |
|
Martin von Zweigbergk |
SF Bay Area |
no |
Boston Marriott Cambridge |
Mar 1 - Mar 4 |
SF Bay Area |
no |
Boston Marriott Cambridge |
Mar 2 - Mar 4 |
|
Pulkit Goyal |
India |
yes |
Le Meridien Cambridge-MIT |
Feb 28 - Mar 5 |
SF Bay Area |
no |
Residence Inn by Marriott Boston Cambridge |
Mar 1 - Mar 5 |
|
London |
no |
Kendall Hotel |
Mar 1 – 5 |
|
Sean Farley |
SF Bay Area |
no |
|
Feb 28 – Mar 6 |
Yuya Nishihara |
Japan |
yes |
Le Meridien Cambridge-MIT |
Feb 28 - Mar 4 |
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 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.