Hi, On 2024-12-23 09:14, Matt Harbison wrote:
Thank you Pierre for all the effort you are putting in the packaging, and into making Mercurial more attractive.On Dec 20, 2024, at 9:14 AM, Pierre-Yves David <pierre-yves.da...@octobus.net> wrote:On 12/20/24 13:20, PIERRE AUGIER wrote:I'm debugging a bad behavior of Windows wheels, which are quite broken because ofhttps://foss.heptapod.net/mercurial/mercurial-devel/-/blob/branch/default/hg andhttps://foss.heptapod.net/mercurial/mercurial-devel/-/blob/branch/default/contrib/win32/hg.bat and because `hg` is not an entrypoint. I need to open an issue where these things can be discussed. Improving Mercurial in term of packaging is already difficult but if one cannot fully usehttps://foss.heptapod.net/mercurial/mercurial-devel, that's beyond me.
I’m fine with using heptapod for bug tracking. Idk how much work it is to import the existing bugs with the same numbers (for ease of searching and/or cross referencing, and not starting over at 1).Really, for the point of view of users and contributors,https://bz.mercurial-scm.org/ is bad. I understand that it has to stay there but at least openhttps://foss.heptapod.net/mercurial/mercurial-devel/-/issues for people used to more modern and integrated issue trackers.I am not sure `https://bz.mercurial-scm.org/` "has to stay". I think we don't want to have two issue trackers, but migrating from bz to Heptapod could make sense. Especially now that most development and CI happens on Heptapod. We migrated from roundup to Bugzilla in the past, we could migrate from Bugzilla to Heptapod.What does other developer things about that ?
I can understand how this old bugzilla could be a deterrent, especially for new users.
Personally, I find using bz.mercurial-scm.org for bug reporting to be painful enough that I am sometimes too lazy to do it. I am very biased of course. For instance, foss.heptapod.net representes the lowest imaginable effort to me, as I am always logged in.
I am a bit wary about importing the existing bugs, as these things tend to represent way more work than one would imagine and I suppose (almost) nobody here would have the time to do that. That being said, one thing would be easy and could be a first step : start issues on Heptapod at a suffficiently large number. It just requires bumping the underlying PostgreSQL sequence, I would happily do it.
For completeness, there is a Bugzilla integration in GitLab, hence Heptapod. But I don't know if the version used by Mercurial would be compatible, and, frankly, I'd see it more like something to help keep on using Bugzilla, and that would not be my choice.
The only other issue I can think of is the current commit message format of “(issueXYZ)” auto closes the issue. I’ve been using “(fixes #xyz)” in thg to get that functionality. It would be nice to stick to the former for consistency, and it’s slightly shorter.
Yes, it is shorter because it lacks a verb.
The issue recognition pattern can be customized for the whole instance*, I have no problem adding `issue(\d+)' to it, but that would still require something like `fixes issueXYZ`. Not sure it is worth the effort.Not sure how to teach that to heptapod though.
* https://docs.gitlab.com/ce/administration/issue_closing_pattern.html Best, -- Georges Racinet https://orbeet.io/a-propos/cloudcrane,https://heptapod.net GPG: 09719FFE0B476DC26923F8EEB8EB20361976F291
OpenPGP_0xB8EB20361976F291.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
