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. Possible criteria for acceptance

This is a draft of our policy to accept extension in core. Experimental extensions could be dropped off the core repository if they stop matching theses criteria.

Criteria have not been formally validated in this form yet.

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

• please fill me.

4. Current Candidate extensions

• NarrowHG extension,
• Evolve extension,
• Topic extension.
• watchman

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