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.
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:
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.
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?
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).
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?
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:
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.
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.