|
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. |
|
|
|
|
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) (also'https://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. |
|
|
|
|
Quote from WubTheCaptain
No privacy practice, though (which could be asked for).
Correcting myself, there is'https://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. |
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
|
|
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). |
|
|
|
|
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. |
|
|
|
|
|
(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.
|
|
|
|
|
|
I should disclose I have no affiliation to any of the services listed above, including sourcehut; I don't even have an account there. |
|
|
|
|
|
(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
|
|
|
|
|
(0021021)
|
|
Blzut3
|
|
2019-09-15 20:24
|
|
|
|
|
(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. |
|
|
|
|
|
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) |
|
|
|
|
|
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. |
|
|
|
|
|
|
|
(0021490)
|
|
Pol M
|
|
2020-07-09 10:42
|
|
|
A glitch in the matrix :) |
|