Experimental Extensions

Plan to define a way to have some experimental extensions part of the core Mercurial repository.

Such extensions would be marked as experimental and BC (backward compatibility) is not guaranteed (to the point we could just remove them entirely).

1. Rational

Having extensions in the main Mercurial repository have some advantage:

• Exposure to more users (shipped with all our users),
• Easier to contribute (same process and testing as the rest of the core work).

2. Criteria for acceptance

The general philosophy of accepting experimental extension is:

• Extension should have an owner,
• Development should stay active,
• This code should not get into other people way,
• There should be a plan to get this out of experimental.

This translate into the following more concrete criteria:

• There is a clear owner for this extensions,
• This owner continuously enforce these criteria,
• The code of the extensions fits Mercurial code-style (no test-check*.t breaking),
• The test coverage of the extensions is descent and people are confident about it,
• There is a final target for this extension "in-core" or "as official extensions"
• The blocker/path to get this extension to that target are clearly stated somewhere on this wiki,
• Regular progress are made toward this goal and we are confident it will eventually happen.
• Be reasonably robust and non-invasive. So that the frequency it break from unrelated changes does not slow down the rest of Mercurial development compared to the value it brings to it,

3. Current Experimental Extensions

3.1. AutoMV

• Owner: MartijnPieters

• Code status: style in compliance, good test coverage (97%).
• Will be included as experimental in 3.8, goal to be official in 3.9. Points to hash out:

  • Perhaps the --no-automv switch is redundant and --similarity 0 suffices

  • Should the automv.similarity configuration option be merged with the --similarity command-line option to hg addremove? What would a config option for the latter look like, how would that work?

3.2. FSMonitor

• Owner: MartijnPieters

• Formerly known as hgwatchman

• Code status: style in compliance. Tests rely on running the test suite with a blacklist and the extension enabled
• To be included as experimental in 3.8, goal to be official in 3.9. Points to hash out:
  • Standalone canary test suite, to be run as part of the full test suite.

3.3. JournalExtension

• Owner: MartijnPieters

• Formerly known as reflog
• Code status: style in compliance, good test coverage (94%)
• To be included as experimental in 3.9, goal to be official in 3.10. Points to hash out:
  • The output format may need adjusting
  • The formatter and template options may need reworking if the output format changes

4. Current Candidate extensions

• NarrowHG extension,
• Evolve extension,
• Topic extension,
• keyring,

• LogToProcess (expanded on below)

4.1. LogToProcess

• Owner: MartijnPieters

• Code status: style in compliance, good test coverage (in the high 90s, but double-forking and windows-specific code make this hard to measure exactly).
• Could be included as experimental in 3.8 if patch is accepted, goal to be official in 3.9. Plan:
  • Wider exposure to kick the tires; this needs some wider use, especially on Windows, to see how this holds up.

5. Possible Drawback

5.1. Constraint on Code Quality

Extensions are used to make dirty prototypical extensions were code quality is not up our standard. And then to clean up architecture and code when they move into core (eg: that for phase, obsmarkers, etc).

Being able to freely experiment is important to converge to a good solution quickly.

Experimental code often have narrower target in term of OS and Python version. The would be an issue for the tests.

Finally moving the load of update crappy code to better API when we rework core from the author of the crappy code to the author of the factory cleanup is probably a loss.

5.2. Constraint on review process

Our patch flow is still not great, review process and latency can significantly slow down development. We need a solution to ensure maximum velocity for experiments.

5.3. Constraint on release cycle

This is the main issue here, 3 month latency is far too long for experiment. The goal of experimental extensions are to ship potential new feature to the user quickly. Version are usually made the same week an important feature is added. Multiple version to adjust the behavior might happen in the same month. Experimental extensions are likely to have show-stopper bugs that prevent user to user Mercurial until it is fixed.

5.4. Constraint on release target

In addition, the target user base does not necessary run the latest mercurial. as a result extensions are often compatible with multiple older version (eg: Evolve is compatible down to 3.4 for this purposes)

This would be hard to test and implement once trapped in Mercurial main repository.

6. Possible Solutions

6.1. Code Quality

We could have lower code quality norm for the experimental extensions. This does not solve the tests issue, but we could throw enough condition to skip them for anything unsupported (even skipping check-code?).

We seem to have some consensus on that.

6.2. Constraint on review process

We could have direct push for the experimental extensions.

We do not seem to have a consensus here.

6.3. Constraint on release cycle

This is a hard one. Could we have some extra package containing stable + latest extension (require some branch witchcraft).

6.4. Constraint on release target

This is a harder one. Maybe this requirement need to be relaxed (with then, more filtering on what extensions are eligible).

We can probably also work around that with bigger branches witchcraft in a dedicated repository.

---

CategoryDeveloper CategoryNewFeatures