Differences between revisions 2 and 3
Revision 2 as of 2015-12-22 00:56:55
Size: 3276
Comment:
Revision 3 as of 2016-02-21 15:43:33
Size: 3289
Comment: add hgwatchman as possible -in-core-repo-extensions-
Deletions are marked like this. Additions are marked like this.
Line 74: Line 74:
 * watchman

Note:

This page is primarily intended for developers of Mercurial.

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 we would not garantee BC on them (to the point we could just remove 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. Drawback

2.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.

2.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.

2.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.

2.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.

3. Possible Solutions

3.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.

3.2. Constraint on review process

We could have direct push for the experimental extensions.

We do not seem to have a consensus here.

3.3. Constraint on release cycle

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

3.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.

4. Current Candidate extensions

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


CategoryDeveloper CategoryNewFeatures

ExperimentalExtensionsPlan (last edited 2016-06-29 18:00:08 by MartijnPieters)