MantisBT - Doomseeker
View Issue Details
0003701Doomseeker[All Projects] Epicpublic2019-08-20 15:472020-07-09 10:42
Zalewa 
Blzut3 
highblockN/A
resolvedfixed 
1.3 
1.3.11.3.1 
0003701: Bitbucket will stop supporting Mercurial on June 1, 2020
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket [^]

We will have to migrate to Git or to a different hosting platform.
https://j11g.com/2019/08/21/git-is-eating-the-world/ [^]
https://news.ycombinator.com/item?id=20745393 [^]
https://lobste.rs/s/xuppr2/sunsetting_mercurial_support_bitbucket [^]
https://old.reddit.com/r/programming/comments/csy2tf/bitbucket_kills_mercurial_support/ [^]
https://www.theregister.co.uk/2019/08/21/bitbucket_mercurial_repositories/ [^]
No tags attached.
parent of 0003704resolved WubTheCaptain Doomseeker Pull requests on Bitbucket's Mercurial repositories may be lost on June 1, 2020 
parent of 0003708closed WubTheCaptain Doomseeker Mercurial repository is not operative from the URI documented in stable release 
has duplicate 0003702closed WubTheCaptain Doomseeker Bitbucket to drop Mercurial support in June 2020 
related to 0003700resolved AOSP Zandronum Bitbucket to drop Mercurial support 
related to 0003750resolved Zalewa Doomseeker Download page still refers to Mercurial 
Issue History
2019-08-20 15:47ZalewaNew Issue
2019-08-20 16:11ZalewaSummaryBitbucket will stop supporting Mercurial one June 1, 2020 => Bitbucket will stop supporting Mercurial on June 1, 2020
2019-08-20 16:20AOSPRelationship addedrelated to 0003700
2019-08-20 23:40Blzut3Note Added: 0020965
2019-08-21 07:57ZalewaNote Added: 0020969
2019-08-23 16:34WubTheCaptainRelationship addedhas duplicate 0003702
2019-08-23 16:35WubTheCaptainPrioritynone => high
2019-08-23 16:35WubTheCaptainSeverityminor => block
2019-08-23 16:35WubTheCaptainStatusnew => acknowledged
2019-08-23 17:36WubTheCaptainNote Added: 0020975
2019-08-23 17:36WubTheCaptainNote Edited: 0020975bug_revision_view_page.php?bugnote_id=20975#r12776
2019-08-23 17:36WubTheCaptainNote Edited: 0020975bug_revision_view_page.php?bugnote_id=20975#r12777
2019-08-23 17:36WubTheCaptainNote Added: 0020976
2019-08-23 17:42WubTheCaptainNote Edited: 0020976bug_revision_view_page.php?bugnote_id=20976#r12779
2019-08-24 05:04Blzut3Note Added: 0020988
2019-08-24 12:00Pol MNote Added: 0020991
2019-08-24 12:18ZalewaNote Added: 0020992
2019-08-24 16:18WubTheCaptainNote Added: 0020993
2019-08-24 16:19WubTheCaptainNote Added: 0020994
2019-08-24 16:19WubTheCaptainNote Added: 0020995
2019-08-24 16:19WubTheCaptainNote Added: 0020996
2019-08-24 16:29WubTheCaptainNote Edited: 0020996bug_revision_view_page.php?bugnote_id=20996#r12796
2019-08-24 16:30WubTheCaptainNote Edited: 0020996bug_revision_view_page.php?bugnote_id=20996#r12797
2019-08-24 17:16WubTheCaptainNote Added: 0020998
2019-08-24 18:20WubTheCaptainNote Added: 0021002
2019-08-24 18:24WubTheCaptainRelationship addedparent of 0003704
2019-08-24 20:51WubTheCaptainAdditional Information Updatedbug_revision_view_page.php?rev_id=12808#r12808
2019-08-24 20:53WubTheCaptainNote Added: 0021005
2019-08-24 22:01ZalewaNote Added: 0021006
2019-08-24 22:05ZalewaNote Edited: 0021006bug_revision_view_page.php?bugnote_id=21006#r12810
2019-08-24 22:17ZalewaNote Edited: 0021006bug_revision_view_page.php?bugnote_id=21006#r12811
2019-08-24 23:20Blzut3Note Added: 0021008
2019-08-25 02:40WubTheCaptainNote Added: 0021010
2019-08-25 02:50WubTheCaptainNote Added: 0021011
2019-08-25 02:53WubTheCaptainNote Edited: 0021010bug_revision_view_page.php?bugnote_id=21010#r12813
2019-08-25 02:54WubTheCaptainNote Edited: 0021010bug_revision_view_page.php?bugnote_id=21010#r12814
2019-08-25 03:07WubTheCaptainNote Edited: 0021010bug_revision_view_page.php?bugnote_id=21010#r12815
2019-08-29 19:25WubTheCaptainNote Added: 0021013
2019-08-29 19:25WubTheCaptainStatusacknowledged => confirmed
2019-09-10 01:28Blzut3Note Added: 0021019
2019-09-10 08:11Pol MNote Added: 0021020
2019-09-15 02:28Blzut3Assigned To => Blzut3
2019-09-15 02:28Blzut3Statusconfirmed => assigned
2019-09-15 20:24Blzut3Note Added: 0021021
2019-09-15 20:24Blzut3Statusassigned => needs review
2019-09-16 13:56WubTheCaptainNote Added: 0021024
2019-09-16 13:57WubTheCaptainNote Edited: 0021024bug_revision_view_page.php?bugnote_id=21024#r12823
2019-09-16 13:57WubTheCaptainNote Edited: 0021024bug_revision_view_page.php?bugnote_id=21024#r12824
2019-09-16 14:03WubTheCaptainRelationship addedparent of 0003708
2019-09-19 05:33ZalewaNote Added: 0021030
2019-09-26 15:56WubTheCaptainNote Added: 0021047
2019-09-26 15:56WubTheCaptainStatusneeds review => needs testing
2019-09-26 22:41Blzut3Note Added: 0021048
2019-09-26 22:41Blzut3Statusneeds testing => resolved
2019-09-26 22:41Blzut3Fixed in Version => 1.4
2019-09-26 22:41Blzut3Resolutionopen => fixed
2019-09-27 17:46WubTheCaptainTarget Version => 1.4
2019-09-30 18:29WubTheCaptainNote Added: 0021053
2019-09-30 18:30WubTheCaptainNote Edited: 0021053bug_revision_view_page.php?bugnote_id=21053#r12868
2020-01-27 20:43WubTheCaptainProduct Version => 1.3
2020-01-27 20:43WubTheCaptainFixed in Version1.4 => 1.3.1
2020-01-27 20:43WubTheCaptainTarget Version1.4 => 1.3.1
2020-01-30 17:00WubTheCaptainRelationship addedrelated to 0003750
2020-06-04 16:54WubTheCaptainNote Added: 0021349
2020-06-04 16:56WubTheCaptainNote Edited: 0021349bug_revision_view_page.php?bugnote_id=21349#r13096
2020-07-07 05:22WubTheCaptainNote Added: 0021488
2020-07-09 09:41WubTheCaptainNote Added: 0021489
2020-07-09 10:42Pol MNote Added: 0021490

Notes
(0020965)
Blzut3   
2019-08-20 23:40   
Sad day. :(

Given that Bitbucket was THE place to use Mercurial I'd say we're well past "the writing is on the wall for Hg." So switching to Git is something we're pretty much forced into. So the question becomes do we stay on Bitbucket or migrate to GitHub. I do like how Bitbucket allows for some organization of auxiliary repositories within a team, so I'm inclined to say stay there. But I'm happy to hear arguments to move.
(0020969)
Zalewa   
2019-08-21 07:57   
We can stay on Bitbucket. There's no reason to move out and we're organized there pretty nicely. To be honest Mercurial has been irking me more and more when it comes to organizing the PRs. Even considering that Mercurial seemingly has the same functionality as Git, it still has some rigidness when it comes to "histedit" where in Git the interactive rebase is much more flexible. I will not cry about losing Hg.
(0020975)
WubTheCaptain   
2019-08-23 17:36   
I'll bring up some real issues to consider that affect Doomseeker.

Although I prefer working with Git, I'd rather keep Doomseeker in Mercurial for easy referencing to Mercurial commits from a historical perspective. It is what it is, unless a new project with Git was announced like "Doomseeker 2", existentially baleeting the knowledge about Doomseeker 1.x.

If Git will be chosen, I'd bring up 0003321 to be reconsidered. (This is up for another ticket to discuss.)

Anything other than Bitbucket would mean changing the documentation in Doomseeker with new URIs in future releases, given that we don't usually backport changes to older versions.

(0020976)
WubTheCaptain   
2019-08-23 17:36   
(edited on: 2019-08-23 17:42)
Now, I'll hijack this for a moment to express my personal incoherent ramblings and holy wars.

Whatever this will be, please no GitHub. I've never liked their data protection practices, although since the GDPR they've improved upon that a bit. (I'm a bit hypocritical because I have never received knowledge about my rights as a data subject when signing up to this tracker, and the tracker is currently running on a very old and possibly vulnerable version of MantisBT 1.x.)

Both Atlassian (Bitbucket) and GitHub seem to bundle multiple legal bases into one privacy statement, making them difficult to understand & bundling shouldn't be legally allowed. Bitbucket also says people with non-agreement to their data protection practices shouldn't use the service, when those people should rather complain to the supervisory authority in EU. etc. I have not ever signed up on Bitbucket, and I have terminated my account on GitHub last year (June 2018: GitHub User Migration for @WubTheCaptain). I've formerly also terminated an account on NotABug.org Git hosting over a data protection dispute.

On the tracker, I've always voted opposition on issues concerned with Bitbucket's "pipelines". I hate vendor lock-in. Vendor lock-in would also be a thing on GitHub, in multiple different ways (CI, the issue/PR tracker, etc). I don't know what to say about GitLab.

I've not always had the best experience with Bitbucket with JavaScript disabled, however the same could be said about GitHub in some less visited places.

I'm personally inclined to avoid discussing and using the services mentioned before, because they are stressful to me; I do not feel comfortable using those services. I am more likely to give up with a service than arguing and spending effort on a legal process to correct wrongdoing in a disagreement, shamefully so. I will, however, continue submitting patches via this Zandronum tracker in lieu of a mailing list because so far it hasn't been too stressful to me.

I am supporting the idea of self-hosting or with (small) non-profit organizations for the revision control. I've been in favor of mailing lists all the time, as it gives the user (developer) with freedom to choose their federated email hosting provider to trust (or host their own). Mailing lists are associated with "bad" UX from decades ago, however. Git itself has always been federated and mostly tied to email, it's a shame I can't use some great features of it such as git-send-email(1) (alsohttps://git-send-email.io/ [^]).

Unrelated to this ticket, but my greatest fear has for long been losing access to issues on this tracker due to the centralized nature (vs. email's federation); the issue is somewhat alleviated by grabbing WARC captures from the tracker few times a year & uploading them to Internet Archive, or directly via Wayback Machine (also "bad" UX). I'm not so glad of the proposals taking the centralized approach in above comments by Zalewa and Blzut3 again with version control, but the project is deeply rooted into it.

I know Git in particular has git-request-pull(1); I don't know of equivalent in Mercurial.

"sir hat" (sr.ht) or as it's known now, "sourcehut" (sourcehut.org), has been in better light for me due to... well, SirCmpwn himself. (I don't always like him personally, but I like what he does.) And some UNIX-y hacker things. No privacy practice, though (which could be asked for). Just noticed the new blog post Sourcehut welcomes Bitbucket refugees.

(0020988)
Blzut3   
2019-08-24 05:04   
The problem with email based systems is that seemingly most people (as of years ago when a developer mailing list was seriously considered) in the Doom community do not want to use email/don't want their email to be public. Github and Bitbucket both allow using fake email addresses while remaining full featured. So besides the UX issues mailing lists really only work in older communities or those which have built around the use of email as primary communication.

I think your objection to GitHub makes the solution of use Git with Bitbucket the obvious one. The repo conversion can be done with hg-git so no history should be lost and the conversion should be bi-directional.

As I stated in my first comment, I think Bitbucket closing Mercurial support means that the Mercurial project is going to be on its last legs. It doesn't have to be like that but unless sr.ht blows up within the next year I find it highly unlikely that this won't cause Mercurial's market share to drop to the point where development on it effectively halts. Nothing lasts forever, I'm sure something will eventually replace Git in the future.

That's not even counting that Zalewa has become less fond of Mercurial and the fact that it has become a sticking point as far as using free CI services. I know you consider that vendor lock-in but since CI isn't a dependency on anything it's not really a lock-in. Sure some projects at my day job rely on the CI tools to produce a usable result, but I can never understand why some people find it so hard to just make their build systems work agnostic to the environment. So hopefully no open source project ever finds themselves in that situation.

I would still like to hear from Pol M before doing anything, but we should probably get the conversion out of the way sooner than later.
(0020991)
Pol M   
2019-08-24 12:00   
Hg support has been terrible as far as I've worked with it. Don't get me wrong, I like mercurial a lot, and it's strip extension makes dealing with oopsies a good experience. But it's clear to me that mercurial has been getting a bad treatment from the part of Bitbucket (IDE extensions don't work, hg features getting dropped in newer UI of the webpage...) and also CI providers. Git is most certainly the way to go. About the hosting provider, I'd agree with Blzut3 that Bitbucket is the clear choice, but I'd certainly would consider keeping a repo up-to-date in GitHub due to the fact that everyone uses that. If we want other people to do extra contributions in the future, having a foot in "Open-source Land" should be a no brainier, plus being as easy as just pushing the main branch whenever it gets updated. I hope Wub will find it acceptable.

About CI, we have a docker image with what we need, and the build steps are easy to port to any other CI, plus we can live without it temporarily. If we make the switch to git, we should also look into other CI providers that offer us a better deal. TravisCI could also be put in the table if we were to push to Github.
(0020992)
Zalewa   
2019-08-24 12:18   
I concur - the CI is a non-issue due to reasons as stated by Blzut and Pol.

So:

- Mecurial -> Git
- Bitbucket -> Bitbucket

Sadly this means that all the commits referenced here will lose their commit hash anchor, where I agree with Wub that it will prove to be of some annoyance, but getting stuck in the past is worse. We moved from SVN to Hg, now it's time to move from Hg to Git.

Self-hosting incurs costs out of which money is the least concerning one. It also rejects all the convenience features that the hosting platforms provide. Compare bare emails to, for example, Gerrit Code Review system.
(0020993)
WubTheCaptain   
2019-08-24 16:18   
Quote from WubTheCaptain
No privacy practice, though (which could be asked for).


Correcting myself, there ishttps://man.sr.ht/privacy.md [^] but it's not up to par with GDPR by far, worse in comparison to the "big three" tech companies.
(0020994)
WubTheCaptain   
2019-08-24 16:19   
Quote from Blzut3
I think your objection to GitHub makes the solution of use Git with Bitbucket the obvious one.


I'd like to clarify I'm not in favor of either, but for the Doomseeker project using Bitbucket seems the easier (more obvious) choice way due to its historical roots.

Quote from Blzut3
As I stated in my first comment, I think Bitbucket closing Mercurial support means that the Mercurial project is going to be on its last legs.


Unless you mean the support of Mercurial on Bitbucket, then... Mercurial has had 8 stable releases this year alone and still seems to have an alive community.

Quote from Blzut3
the fact that it has become a sticking point as far as using free CI services


Which I believe the "big three" (Bitbucket, GitHub, and maybe GitLab?) and sourcehut support. For self-hosting choices:
  • BitBucket pipelines seems to be proprietary;
  • GitHub's Travis CI is technically free but "enterprise" (https://blog.travis-ci.com/2015-06-19-how-we-improved-travis-ci-installation/);
  • GitLab I have no idea;
  • builds.sr.ht is meant to be hosted on KVM QEMU + docker (https://man.sr.ht/builds.sr.ht/installation.md).


Quote from Blzut3
I can never understand why some people find it so hard to just make their build systems work agnostic to the environment.


It's only a small concern.

I see it may invite the contributors to use the platform for the CI features, especially if passing the CI tests is mandatory for acceptance. The better explanation for vendor lock-in may be something like Travis CI is that it's not easy to self-host, should GitHub shut down at some point (and it was sold to Microsoft lately). With Bitbucket's proprietary (?) pipelines, it may be nigh impossible and creates additional work to setup again for a new system.

It all comes down to choices.
(0020995)
WubTheCaptain   
2019-08-24 16:19   
Quote from Pol M
I hope Wub will find it acceptable.


I don't, but I don't use those services so the effect has been limited to me as long as I've been allowed to contribute via the tracker. It's nice of you that I've been continued to be allowed to do so, thank you.

Where the source code (revision control like hg/git) is hosted to be cloned doesn't really matter for my ability to contribute; mirrors even less so.

Quote from Pol M
About CI, we have a docker image with what we need, and the build steps are easy to port to any other CI, plus we can live without it temporarily. If we make the switch to git, we should also look into other CI providers that offer us a better deal. TravisCI could also be put in the table if we were to push to Github.


See what I wrote above to Blzut3.
(0020996)
WubTheCaptain   
2019-08-24 16:19   
(edited on: 2019-08-24 16:30)
Quote from Zalewa
- Mecurial -> Git
- Bitbucket -> Bitbucket


I'm in favor of this solution for the Doomseeker project with no personal biases.

My personal biases would guide me to use Mercurial or Git (either) on a service that is not any of the above, with slight bias on sourcehut (possibly alternatively GitLab) due to better societal good.

Quote from Zalewa
Self-hosting incurs costs out of which money is the least concerning one. It also rejects all the convenience features that the hosting platforms provide. Compare bare emails to, for example, Gerrit Code Review system.


It may not be an issue with self-hosting, but the tools commonly associated with self-hosting Git, wiki, tracker, etc. (Phabricator, Gogs / Gitea, GitLab, stagit or cgit. Code review. Issue tracker, if not included. Wiki, if not included. Place to discuss, such as mailing list.)

sourcehut might just be one example of a service integrating email tightly with all the convenience features you're probably referring to; issue tracking without an account too, which is different to the current situation but not necessary to discuss right now.

(0020998)
WubTheCaptain   
2019-08-24 17:16   
If the switch to Git happens, it may be nice to find a place to host a read-only archive of the Mercurial repository despite hg-git conversion (for commit anchors).
(0021002)
WubTheCaptain   
2019-08-24 18:20   
Pull requests submitted on Bitbucket to existing Mercurial repositories may be lost. I'm reading from Atlassian Community forums there's no way to convert existing hosting repositories on Bitbucket from HG to Git and keep the PRs doing that.

There's some 5 pages of them for the Doomseeker project. I'm creating a child issue for this.
(0021005)
WubTheCaptain   
2019-08-24 20:53   
(Added relevant further reading to additional information in OP.)
(0021006)
Zalewa   
2019-08-24 22:01   
(edited on: 2019-08-24 22:17)
Since we're now making a significant change in the VCS department, I'm inclined to "ride the wave" here and reconsider 0003321 in favor of "The seven rules of a great Git commit message".

https://chris.beams.io/posts/git-commit/ [^]

The hyphen-based commit message was meant to be used as changelog, but it has turned out that simply aggregating commit messages will make a poor changelog. The changelog needs to be kept separately. Moreover, various UI tools don't like how we conduct our commit messages (including TortoiseHg, where the log viewer still cannot auto-wrap long lines). The tools are rather programmed to fit to the mentioned seven rules, especially the 80-column limit.

(0021008)
Blzut3   
2019-08-24 23:20   
Quote from WubTheCaptain
My personal biases would guide me to use Mercurial or Git (either) on a service that is not any of the above, with slight bias on sourcehut (possibly alternatively GitLab) due to better societal good.

I'm a little confused on your statement of "better societal good" when the sourcehut website states that it will not be free:https://sourcehut.org/alpha-details/ [^]
Quote from SourceHut
Payment is optional now but will be required later

When the beta begins, unpaid accounts will be limited. Affected users will be emailed 60 days in advance of the transition. Of course, users hosting their own instance of Sourcehut on their own servers are unaffected by this.

So based on that it would seem that sr.ht is not going to build the community that Bitbucket/GitHub are able to do. Yes it's free to self host but that goes back to all the usual issues with self hosting something like this (i.e. discarding the social aspect of open source).

I get why they'd want to do that model, but on the topic of Mercurial still being alive, I think it only strengthens my view that Mercurial is heading into a situation where there's no real "GitHub equivalent" which will slowly but surely kill it off. Mercurial still has some big names using it, but big names couldn't save Subversion.
Quote from Pol M
but I'd certainly would consider keeping a repo up-to-date in GitHub due to the fact that everyone uses that.

While I'm not really against it, I will note that Zandronum had a GitHub mirror at one point to see if people would be willing to contribute more through there. I don't think it lasted very long.
(0021010)
WubTheCaptain   
2019-08-25 02:40   
(edited on: 2019-08-25 03:07)
Quote from Blzut3
I'm a little confused on your statement of "better societal good" when the sourcehut website states that it will not be [gratis]


See 0003700:0021000.

Quote from Blzut3
So based on that it would seem that sr.ht is not going to build the community that Bitbucket/GitHub are able to do. Yes it's free to self host but that goes back to all the usual issues with self hosting something like this (i.e. discarding the social aspect of open source).


I didn't even consider this, it's a fair point. Though not obvious from that alpha page, it seems people would still be able to participate socially to things such as issue tickets (via email) without paying for an account.

Or in case of Git, git-request-pull(1) with email as intended. It's just a different approach, but still social.

(0021011)
WubTheCaptain   
2019-08-25 02:50   
I should disclose I have no affiliation to any of the services listed above, including sourcehut; I don't even have an account there.
(0021013)
WubTheCaptain   
2019-08-29 19:25   
(Confirming the issue, because we pretty much know how much this will affect us and where to go from here.)
(0021019)
Blzut3   
2019-09-10 01:28   
Performed the Git conversion on ECWolf last weekend. Potentially looking at Sunday to do Doomseeker unless there are any objections.
(0021020)
Pol M   
2019-09-10 08:11   
Cool, no problems here
(0021021)
Blzut3   
2019-09-15 20:24   
Should all be converted.
(0021024)
WubTheCaptain   
2019-09-16 13:56   
(edited on: 2019-09-16 13:57)
I saw the proposal to do it on Sunday, but didn't see a need to reply before now.

Blzut3: For 0003704 (archival task), would you please move the Doomseeker & blobs repositories to doomseeker*-git and move doomseeker*-hg repositories back to doomseeker* for the time being?

Obviously, I have no opposition for development going to those doomseeker*-git repositories for the time being.

If I may add, the current stable release's documentation refers to clone with Mercurial from said URIs and that instruction is now also broken.

(0021030)
Zalewa   
2019-09-19 05:33   
Thanks for the conversion Blzut, all is fine on my side.
(0021047)
WubTheCaptain   
2019-09-26 15:56   
All child issues are resolved at this time.
(0021048)
Blzut3   
2019-09-26 22:41   
Given that Zalewa has acknowledge that "all is fine" for him, I'm going to mark this as resolved.
(0021053)
WubTheCaptain   
2019-09-30 18:29   
(edited on: 2019-09-30 18:30)
Quote from https://github.com/flathub/com.zandronum.Zandronum/blob/master/com.zandronum.Zandronum.yaml
    # Current upstream system makes use of Mercurial. There are plans
    # to migrate to Git, but at the time this works easiest.
    - sed -i 's/HG_REVISION_HASH_STRING/"Flatpak Edition"/g' ./src/core/version.cpp
    - sed -i 's/HG_REVISION_NUMBER/'$(date +%s)'/g' ./src/core/version.cpp
    - sed -i 's/HG_TIME/"'$(date --iso-8601=seconds)'"/g' ./src/core/version.cpp


it uses the stable 1.3 tarball though, so this breakage for 1.4 might be fine.

(0021349)
WubTheCaptain   
2020-06-04 16:54   
(edited on: 2020-06-04 16:56)
BitBucket has extended the timeline until July 1, 2020.
https://bitbucket.org/Doomseeker/doomseeker-hg/ [^] will work for the time being for Mercurial.

(0021488)
WubTheCaptain   
2020-07-07 05:22   
Quote from Bitbucket
[Update July 1, 2020] Today, mercurial repositories, snippets, and wikis will turn to read-only mode. After July 8th, 2020 they will no longer be accessible.

Closing this issue after tomorrow, should nothing deviate from this announcement.
(0021489)
WubTheCaptain   
2020-07-09 09:41   
https://bitbucket.org/Doomseeker/doomseeker-hg/ [^] is still accessible, though the deadline from Bitbucket has passed. 🤔
(0021490)
Pol M   
2020-07-09 10:42   
A glitch in the matrix :)