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