Please allow issues on https://foss.heptapod.net/mercurial/mercurial-devel/-/issues
Georges Racinet
georges.racinet at cloudcrane.io
Tue Jan 28 14:31:47 UTC 2025
Hi,
On 2024-12-23 09:14, Matt Harbison wrote:
>
>> On Dec 20, 2024, at 9:14 AM, Pierre-Yves David
>> <pierre-yves.david at 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.
Thank you Pierre for all the effort you are putting in the packaging,
and into making Mercurial more attractive.
>>>
>>> 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’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).
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.
> Not sure how to teach that to heptapod though.
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.
* https://docs.gitlab.com/ce/administration/issue_closing_pattern.html
Best,
--
Georges Racinet
https://orbeet.io/a-propos/cloudcrane,https://heptapod.net
GPG: 09719FFE0B476DC26923F8EEB8EB20361976F291
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20250128/34780fd1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB8EB20361976F291.asc
Type: application/pgp-keys
Size: 677 bytes
Desc: OpenPGP public key
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20250128/34780fd1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20250128/34780fd1/attachment.sig>
More information about the Mercurial-devel
mailing list