Please allow issues on https://foss.heptapod.net/mercurial/mercurial-devel/-/issues

Mon Feb 10 14:40:38 UTC 2025

Moving the bug tracking to the Heptapod make sense. I personally find 
bugzilla fine, but that "one extra thing to maintain and moderate for 
the admin" and "yet another account to deal with for contributor", now 
that contribution of almost entirely heptapod driven, doing things there 
seems like a good idea. In addition, it present a much more modern face to.

As Georges pointed out, there is not bugzilla -> gitlab importer, So 
that's a bit of a problem. The workaround of freezing bugzilla and 
manually making sure the issue number will align on heptapod seems like 
a good compromise.

We will have to look into how to free the bugzilla however, nothing too 
complicated, but probably not going to happens before the freeze.

Please note that this is just my opinion, I am not sure how and by whom 
the final decision should be made.

Ps: if someone has a spare interne to throw on the data migration, 
please raise your hand.

On 1/28/25 15:31, Georges Racinet wrote:
> 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
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at lists.mercurial-scm.org
> https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel

-- 
Pierre-Yves David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20250210/74e77100/attachment.htm>