5.2 Sprint

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

1. Date and location

The sprint will be held October 4-6, 2019 near Jane Street, New York in New York, USA.

The address is 102 North End Avenue, New York, NY 10282 (Conrad New York Downtown), google maps.

Location point of contact: Valentin Gatien-Baron, vgatien-baron@janestreet.com

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

1.1. Arrival Logistics

Hours are 8am to 6pm. Go to the address above, and the hotel concierge will indicate the way (it's on the second floor, the main room is called studio 6).

1.2. Attendance

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

NOTE: Sponsorship funding is typically limited. Priority will be given to students and volunteers. If you are paid by your employer to work on Mercurial you should expect to pay your own way, since it's part of your business.

2. Sponsors

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

Recent sprints sponsoring budgets were around $10,000. (<!> review this number)

Sponsoring Company:

• Facebook ($5000)
• Google (enough to reimburse the people we have already agreed to reimburse)

Sponsor point of contact: durin42 at gmail dot com

3. Meals

Jane Street will provide lunch on-site all 3 days. There will be vegetarian, vegan and gluten-free options.

Breakfast and dinner will not be provided.

Dinner is usually taken outside to help people cool off after a day of work.

(Don't forget vegetarian and vegan options)

Meal point of contact: Please offer your service

4. Possible Topics

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

4.1. Automatic Source Code Formatting

• Convergence of fix and format-source extension

• Can we allow more advanced "fixer tools" by providing a working directory, instead of just code on stdin/stdout? Should we?
  • In-repo formatter config files (e.g. be able to honor a .clang-format file in the ctx being fixed)
  • Cross-file static analysis (e.g. be able to fix "functionFromOtherFile(false);" into "functionFromOtherFile(/*paramName=*/false);")
  • Fixes that affect a file other than the one changed (e.g. propagate paramName changes to /*paramName=*/ comments)
  • Or is all of this the domain of an "hg run" command?

4.2. Python 3

• Can we start using unicode strings more, at least for things like **kwargs keys and doc. How about allowing ui.write() (etc) with unicode?

• How and when do get rid of the source transformer?
• Get out of Beta state before 2019 ends?
• packaging:
  • fedora requires explicit python2 or python3 shebangs
  • no packages currently using python3, no rules written to do so
  • installation directories likely need to change (even off of the default: setup.py prefers 3.x directories while we would probably want "any py3 directory"?)

  • hg shebang line at the root of the repo should probably change - generate this file instead of having it be committed to the repo?

4.3. Rust aka Oxidation

• (gracinet) I'd like to make a short retrospective of one year of Rust development in Mercurial since Stockholm, and start a discussion about what we'll do in the forthcoming year.

4.4. Hosting

• (gracinet) presentation about Heptapod, the friendly fork of GitLab that supports Mercurial

• things we can do to help hosting services supporting mercurial

4.5. hg-git

• What's its current state ? How important is it to the Mercurial project itself ?
• What about the proposal for core inclusion ?
• hgit, it's status and path forward

4.6. Documentation

• Overtime, we developed a lot of nice features and we are in a state where there is relatively less documentations on how to use advanced things like narrow, remotefilelog extensions, try experimental options like zstd.
• This also applies to nice things which we introduce and enable by default like sparse-revlog, aggressive-merge-deltas etc. There is quite less text on how to work with old versions of repository and how to enable them.
• Similarly, command documentation could use significant work and customizability.
  • Features enabled don't change the documentation:

    • hg help commit claims that you can't amend changesets that have children, even if you're using evolve.

    • hg help uncommit claims that you need to pass --keep to keep the commit, even with experimental.uncommit.keep

      • should probably also invert the --keep option and show --no-keep

    • Basically: it'd be really nice if there was a sane/standard way for feature flags/settings to override the hg help <command> docs, including the flags.

  • Confusing/Garden Path documentation:

    • hg help rebase could use an overhaul.

      • There's some confusing terminology ("move" makes sense. "graft" can probably be understood. "merged" seems.. out of place)

      • Describing some -- but nowhere near all -- config options is probably best done by redirecting to hg help config.rebase?

      • Source selection (-r, -s, -b) is documented "accurately" but not "clearly". Even experienced Mercurial users are confused by -s and -b.

4.7. PR

• Do-over of the website's design
• Landing page with an overview of newer features, who is using Mercurial, why, etc.
• Integrate the improved documentation from above

4.8. Graduating experimental features

A good number of things which goes into releases is marked as experimental and they get into the experimental trap. It's unclear what each feature needs to be get out of experimental. We have also lost track on what all are the things under experimental tag.

4.9. Add Your Own Topic

• sub topic 1.a

• sub topic 1.b

5. Sprint Notes

General overview (drop the anti spam part): https://public.etherpad-mozilla.org/p/sprint-hgx.y-NOSPAMREMOVETHATLASTPAST ( update URL)

The table below is an attempt to gather written summary of discussion

CategoryMeetings