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