Heptapod 0.6.0 released

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Heptapod 0.6.0 released

Georges Racinet-2
Hi,

We're glad to announce the release of version 0.6.0 of Heptapod, 
the adaptation of GitLab CE for Mercurial.
It is available on Docker Hub
(https://cloud.docker.com/u/octobus/repository/docker/octobus/heptapod).

You can also read this announcement on the official Heptapod website 
(https://heptapod.net/heptapod-060-released.html#heptapod-060-released).

This version adds workflow and import features, and makes contributing
easier.

While the 0.5 series was mostly about fixing the automatic detection
of merges done by pushing public changesets directly from the command
line, this new version should allow Heptapod user base to grow beyond its
current core of early adopters, thanks to two important user features:

1. The intended default simple and elegant workflow of 
   https://octobus.net/blog/2019-09-04-heptapod-workflow.html is provided
   out of the box.
2. The standard GitLab "import from URL" feature has been finally
   ported to Mercurial.

On top of that, we made some preparations to make it easier to
contribute to Heptapod (lots of low hanging fruits in the UI!),
had a minor base GitLab version bump for the
first time, and of course fixed a handful of bugs.

A traditional changelog is provided in the full description of the
Docker image, with emphasis on backwards compatibility. In the
remainings of this post, we'd like to focus on the possibilities that
this new version opens.

Workflow
~~~~~~~~

The creators of Heptapod had this vision from the
beginning of the project: not only to provide the Merge Request
centric workflow that is currently the paradigm of open development
but also to have it integrated by default with the
non-destructive history rewriting capabilities of current Mercurial
with changeset evolution and topics:
safe and easy squashes, splits, rebases, you name it. No need to be a
DVCS expert, no need to jeopardize a whole project by force pushing on
a regular basis.

This is done by a series of server side decisions. All of these are
explained and motivated in the Heptapod workflow blog post at 
https://octobus.net/blog/2019-09-04-heptapod-workflow.html

The end result is that

- topics are for short-lived feature branches, they are fully
  rewritable (``draft`` phase).
- non-topic changesets are completely immutable, as in
  traditional Mercurial, and writable to the project Master role only.

For projects that can't or won't work in this way, be it for deep
reasons or transitional in nature, the server-side settings that enforce this
can be changed, see the FAQ workflow section (https://heptapod.net/pages/faq.html#workflow).


Import from URL
~~~~~~~~~~~~~~~

Because of various timeouts that can't be reasonably set to very long
values, creating a new Project by a direct push is not realistic for
large projects. Fortunately, GitLab comes with the machinery to import
from various Git sources, and in particular from BitBucket.

In this version, we started with the most generic import: creating a
Project by the HTTP URL of a remote repository.

People interested into migrating from Bitbucket and needing to carry
issues, merge requests etc. over can already use it for an early test,
knowing that the full Bitbucket import is probably just around the corner.


Limitations
-----------
This Mercurial import is rather young and we know
there's a good variety of pathological cases around, so we don't
expect it to work in all situations.

- the import feature has its own timeout, set by default to 800 seconds,
  that can be modified by the instance's systems administrator.
- the import can fail on **repositories with instability**
  orphan changesets, divergent ones. Try and have the most of
  instability resolved before importing.

We'll fix problematic cases in the forthcoming releases, but for that,
we need them to be reported on https://dev.heptapod.net, and if it's
about publically available repositories, you won't even need to send
us the logs, the URL will be enough.

Development process
~~~~~~~~~~~~~~~~~~~

Various actions were taken to make it easier to integrate external
contributors and to streamline our development.

Project management
------------------

In this cycle we also started to

- rework our milestones (https://dev.heptapod.net/groups/heptapod/milestones>). These will
  serve as a roadmap for the time being, but we won't hesitate to
  postpone issues.
- put labels (https://dev.heptapod.net/groups/heptapod/labels) on
  our issues

Developer tools
---------------

- the full description of the heptapod-dev
  (https://cloud.docker.com/u/octobus/repository/docker/octobus/heptapod-dev)
  Docker image will serve as a contributor's guide
- the build-launch (https://dev.heptapod.net/heptapod/omnibus) script
  makes it easier to get working on a local Docker container.

-- 
Georges Racinet
https://octobus.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

signature.asc (849 bytes) Download Attachment