Migration of development to Heptapod

Organisation
8

Change is always complicated but Tryton needs this change and Heptapod seems the best solution.

9

In principle I welcome very much the move to a standard and up-to-date platform.

Open questions worth to be evaluated/answered:

Since it is a major effort to migrate to a new platform and major changes to the repository structure have to be done anyway I would be interested what still is the major benefit of staying with mercurial vs. git. In the interests to migrate to a best possible solution in terms of durabililty and sustainability here some observations from my part:

With heptapod we would be using a layer over original gitlab that could bring some complications.

aszs
How do you manage your fork vis a vis upstream gitlab? It seems challenging considering how complicated gitlab is.

Hi ! Heptapod maintainer here. Logilab is one of our users and a sponsor, indeed. Yes technically it is a serious effort

  • the very same company octobus is also responsible of a substantial part of the maintenance of mercurial itself (commit history of mercurial)

So while there is no doubt about the skills of the heptapod developers for me there is still the now even more important question if it is not finally the time to rely on a more future proof stack: why not use the original (gitlab) if the effort has to be done anyway?

1 Like
10

We have been reassured by our talk with Octobus that indeed this layer is very thin and limited to a small part of Gitlab. So it is mainly Gitlab that will be run.

But as good Open Source citizen the Foundation will take his responsibility and support the provider financially to ensure a part of his sustainability.
Similar though can be applied to Tryton so…

Have you a proposal with a quotation to propose for such migration? (as it has been asked for years to anyone who make such request).

Finally changing from mercurial to git will be an even bigger effort. We will have to rewrite all the existing tools. And the majority of core developers do not want to switch to Git and prefer the clean and simplicity of mercurial.

1 Like
11

Re. possible history rewrite and Conversion script: I did some repository conversions using reposurgeon. The IMHO most important feature is that conversion can be scripted and thus easily tested and adjusted.

When I used it some years ago, it was written in Python (but an ugly piece of code), meanwhile it has been rewritten in golang :frowning:

12

…and gitlab as well of course.

My question really doesn’t go into the direction of preferences, but pure future proofness of the chosen tool. Gathering statistics covers this side of the problem.

For all I see mercurial is actually much less used and - the more important fact - constantly decreasing over the last years. May be we will see this discussion in few years again…

13

If software choice was really a popularity contest then nobody should be here.
I have no doubt in the future of Mercurial. Its development is still going on, they pushed new concepts like phase, topics and rust implementation over the last years. It used by big players.

1 Like
14

While I am a big fan of mono-reposotories, and I think they are worth the effort regardless of an Heptapod/whatever migration, I don’t quite undrestand why this is a requirement. But I’ll celebrate this.

I think the point is: if Tryton considers moving from development platform, by replacing Mercurial with Git it would be possible to take advantatge of even more platforms, which could lead to other quotations if this was something that could be discussed.

A Mercurial to Git conversion is pretty straightforward, so that a final quotation would be pretty similar the one under discussion. Probably such a quotation has never been presented due to the upfront confrontation this idea recieves, and not due to viability reasons.

I am unaware of the extent of the tooling, but I can imagine that dropping DroneCI and embracing a mono-repo and Heptapod will deprecate most of it anyway.

Precisely, the tool has created a niche that keeps away potential contributors that despise the tool and would vouch for a change. Current Tryton contributors and the use of Mercurial are a circular phallacy.

That said, I think Heptapod is a huge step in the right direction. Lately I have been interacting with some projects in that plaform and I look forward to seeing Tryton hosted there. Is there any update in this regard?

15

I think that if people that want to contribute are rebutted by the fact of using a different DVCS, they are not worth the pain of migrating to git.

When I need to submit a patch on a project using github, I use github ; they use gitlab ? OK I’ll use gitlab. SQLite is using their own DVCS and it didn’t prevent them to be a big success (and if I have a fix for SQLite one day, I’ll use fossil).

All in all, the DVCS should be a minor point when choosing to use / contribute to a project.

16

Totally, it should be a minor point. Yet, the platforms have a huge impact on new contributor engagement. Tryton’s current platform is specially cumbersome, and I hope moving to Heptapod will be a boost for the community regardless of the underlying VCS.

2 Likes
17

We decided to not rewrite the history because the disadvantage (of loosing changeset reference) is much bigger than the gain of create links with the issue (which could be found by copying the id).

We decided to use: -

We already have one working but we may wait for the next mercurial release to reduce the number of commit on closed branch because it is not allowed to commit with close option on a closed branch. So we have to do a merge and than another commit.
The conversion last for 7:30.

18

Also the easy contributor workflow is getting worked on, it will be integrated before the end of the year but probably will not be there when we do the switch.

19

Today we pushed the converted repository on https://foss.heptapod.net/ and start working on configuring the CI. We have succeeded to launch tests for trytond and country module using PostgreSQL as service.
The next week we will work on detecting which tests must be run.

Our initial tests on this topic seems to be working.

1 Like
20

For the migration of the bugtracker, we can convert the component into labels.
I think it is less interesting in a mono-repository to use the module name as label. I think we should use the same set of names as for the discourse tags.
So I wrote a script that convert the current components into labels:

#!/bin/env python

import sys

rename = {
    'ldap_authentication': 'authentication_ldap',
    'ldap_connection': 'authentication_ldap',
    'neso': 'tryton',
    'google_maps': 'gis',
    'google_translate': 'trytond'
    }
labels = {
    'account': "accounting",
    'analytic': "accounting",
    'chronos': "timesheet",
    'sale': "sales",
    'purchase': "purchasing",
    }


def convert(name):
    name = rename.get(name, name)
    prefix = name.split('_', 1)[0]
    if name.startswith('web'):
        prefix = '-'.join(name.split('_', 2)[:2])
    elif name.startswith('trytond_'):
        prefix = name.split('_', 2)[1]
    return labels.get(prefix, prefix.lower())


if __name__ == '__main__':
    print(convert(sys.argv[1]))
21

Today I manage to have the build of documentation with intersphinx to work only locally (this will avoid breakage when cross reference doc is added in the same topic).
Also I made it skip to check the demo URL (sometimes the server is not available and anyway this does not ensure that the URL is correct).
I uploaded on Issue 445341003: tryton-cookiecutter: Migrate to Heptapod - Code Review the generic changes that will be needed for the modules.

I tested the first delivery of the migration script of the bugtracker.
The open questions are what to do with the status, type and priority. I’m in favor of just keeping the type as label like type::crash.
There are still some issue that prevent to migrate some issues and we need to find a way to make plain text message compatible with the markdown format of GitLab.

@htgoebel has started to work on triggering the readthedocs build.

We still need to update the release scripts and create a script for developers to relaunch pipe with the secrets (like Stripe keys etc).

22

What will be the usage of such labels? Do we keep just for historical reasons or the idea is to force new users to introduce such labels? I’m not sure if we can enforce new users to introduce them for new issues.

23

We can not force to fill them but the group can try to fill it.
Personally I find it useful to prioritize the work. A crash is much more important to me than a new feature for example.

1 Like
24

Ok, but does it make sense to migrate both tree fields as label with all the selections values?
Probably we just need to have: crash, bug, wrong behaviour, feature request, wish, performance and then merge old values to new values.

For the status I’m wondering if it will be possible to just add a label when a MR is created related to the issue. That will be able to link the issues on “testing” status but also “in-progress” if there is some WIP text in the MR description.

25

No as I said I propose to only migrate the type.

For now octobus is migrating the status also as a label. But I think we do not need anymore because the open/close of GitLab is enough. So we will remove them after the migration.
I do not think we need neither something for the merge-request as a link will be made automatically (and they are displayed on the list) but also with GitLab we have assignation, reviewers etc. So the workflow and notification will be simpler as they are integrated.

Any way I’m in favor to try to minimize as much as possible to customization of GitLab to simplify the maintenance. The usage will tell us if we really need something more.

2 Likes
26

The CI configuration is almost ready (thanks to the help of @htgoebel). There is just a minor detail about the condition to trigger the documentation build.
For the record, we will need to create a doc/conf.py file for all modules (even if it is not yet updated to the current guidelines) and the configuration on readthedocs must be updated to define the python configuration file.

I created some reviews:

https://codereview.tryton.org/445341003/
https://codereview.tryton.org/436121005/
https://codereview.tryton.org/421951003

to_release must still be adapted (waiting instruction from Octobus).

The bugtracker migration has still some issues (I could migrate the 3K first issues).

And we are still waiting from Octobus a script for developer to trigger pipelines with the secrets.

So I would say that we are at about 85% of completeness (skipping the personal topics).

3 Likes
27

I finished testing the conversion, gitlab-ci and release scripts.
So there is just the bugtracker migration that is still pending before we can schedule the migration.

6 Likes