Migration to Heptapod

We are thrilled to announce that the migration of Tryton from its self-hosted instance towards https://foss.heptapod.net will occur from December the 16th to the 19th.

While the migration is in progress access to https://bugs.tryton.org will be stopped and https://hg.tryton.org will be read-only.

To ease your account migration:

  • If you don’t have an account, you should register on heptapod using the email of the Tryton bug tracker.

  • If you already have an account there then you should make sure that the email on our bug tracker is also listed in your heptapod’s emails.

If you didn’t create an account before the migration, an account will be created for you. You will have to reset your password in order to gain access.

Developers planning to create merge requests will have to request access. Please refer to the comprehensive start guide provided by heptapod.
Pending code reviews should be transformed in merge requests.

The migration will preserve the number of the issues and the hash of the changesets. We will be able to put a redirection for the bugs.tryton.org URLs and we will keep the readonly web server for the mercurial repositories. This way hard-coded links will still work.

The codereview server will be kept active but with only the free resource provided by Google.

With our switch to heptapod all merge requests will trigger a testing pipeline. We will be using some shared runners from heptapod’s service and our existing testing server. The more runners we have to shorter the feedback loop for each merge request. So if you have any CPU cycle to share please contact @ced to set up this.

We will keep updating this post with the status of the migration as it happens:

Procedure to convert codereview into merge request

  1. Apply the patch on the new repository in the default branch
  2. Commit into a new topic including the comment Closes #12345 (where 12345 is the issue id) in the commit message
  3. Push and create merge request
  4. Add a comment on the codereview Moved to https://foss.heptapod.net/tryton/tryton/-/merge_requests/1234 (where 1234 is the merge request id)
  5. Close the codereview

Do we have a schedule before the codereview server is shutdown?
I have a lot of reviews on the old codereview server which and it will take some time until I can submit them to the new merge request format.

The plan is to keep it as long as possible but based only on free resource. So this means that from time to time if there is too much traffic, it will not be available.

1 Like

Very excited about this event!

From Heptapod – Merge Request Quick Start Guide

First, you need an account on your Heptapod instance with Developer rights or above on the project you are targeting. Projects can be setup to add a button to request permissions at the top of the page, if not, ask one of the maintainers to grant you that right.

I think that button would be worth it. Otherwise, how are the permissions requested? Ok, I finally found it just now. A somewhat discrete button TBH.

I think it’d also be worth mentioning this explicitly in the contributing guide Tryton - How to Develop as I can imagine new contributors are precisely the main target of those pages.

If you already have an account there [bugs.tryton.org] then you should make sure that the email on our bug tracker is also listed in your heptapod’s emails

I am quite a mess with my accounts. What’s the worst that can happen if I can’t fullfill this condition? My former issues being unrelated to my heptapod account?

If you had already an account but with different emails, then you have now 2 accounts on Heptapod.

They are linked to the account created with the email address used on roundup.

The new project on Heptapod is now fully operational.
There are still few minor things that will be fixed in the follow weeks (ex: migrate the secondary bug trackers).


That’s great!

I see that the tryton repository has the modules at the root. Is there a plan to move it into trytond/trytond/modules? It seems it would make development somewhat easier?

Otherwise how do you suggest to handle the development of new features?

No it is good to be able to choose “installed” modules in development mode. But also it will be harder to know when to make a release.

As usual.

JFTR if anyone searches for the mercurial dev setup like me:

How to Develop advises to use mercurial topics for development. The setup of the extension was not so straightforward since it is not part of mercurial core. I had to do at least:

$ pip install --user hg-evolve

and different from Changeset Evolution with Mercurial — evolve extension for Mercurial I had to insert the explicit path to the extension(s)

evolve = /home/username/.local/lib/python3.10/site-packages/hgext3rd/evolve/
topic = /home/username/.local/lib/python3.10/site-packages/hgext3rd/topic

It’s strange we have probably almost the same setup as I’m also a debian user (I use sid) yet I wasn’t required to use the full path of the module when installing with pip install --user.

Mercurial extensions must be installed with the same Python version that hg command is using.

I don’t found how to add in an issue:

  • add modules at the issue (labels?)
  • add you in noisy list (participants?)

Somebody could you explain? thanks

We use labels to categorize per module familly

There is a “Notifications” check box.

Any updates on the progress of the github mirror?

It is completed synchronized. I also put relatorio, python-sql and goocalendar.

I tried to disable the billing for the app engine but this prevents to use it because the free storage quota is 1GB and we have 6.2GB. So I restored the billing for now.
Instead I would urge everyone who has still pending reviews (and not yet converted into merge request) to take action as soon as possible.
The plan is now to make the data store readonly by the end of the month, make a copy of the data and then disable the billing. This way in case of need we could still re-enable the billing exceptionally to retrieve some missing information.

Maybe we can just store download all the open patches in a folder so anyone can pick them in the future and convert into heptapod. As this is plan text we may store it on one of our servers, so everything can be restored latter if needed.

I think that people who will not migrate their review during the month, does not care about it any more. So I do not think we should work harder and spend more resource than the actual plan for people who does not care.


Could you add me as a Developer? Thanks!