www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bugzilla to GitHub Issues Migration

reply Mike Parker <aldacron gmail.com> writes:
We're much closer now to pulling the trigger on the Bugzilla to 
GitHub issues migration. Robert has fixed the blocker in the app 
he wrote to perform it, and he and I have both confirmed that it 
works as expected on a test repository.

We have a planning session scheduled this week. Before I initiate 
the migration, I need to make sure we're aware of all of the 
consequences and how to handle them (e.g., dlang-bot, moving 
Bugzilla to read-only, any instructions on the Wiki, etc.).

If you're aware of anything out there that we need to consider 
once the issues are migrated, please let us know here.

Once we've got a handle on everything, I'll set a date to 
initiate the migration. Hopefully the first or second week of 
July. I plan to start with the small stuff, like tools and 
visuald to make sure there are no problems with tying things off 
in Bugzilla (the app won't close the migrated issues, but will 
leave comments on them noting that they've been migrated, with a 
link to the GH issue). I'll keep a thread running here noting 
when I'm starting on each Bugzilla component (tools, phobos, dmd, 
etc.) and when it's finished.

The whole process should take a few days. We have to be mindful 
of rate limits on API usage, which means some of the components 
will take quite a while to migrate. I doubt I'll run them all 
back to back, but we'll see how it goes.
Jun 21 2023
next sibling parent reply Johan <j j.nl> writes:
On Wednesday, 21 June 2023 at 16:46:06 UTC, Mike Parker wrote:

 We're much closer now to pulling the trigger on the Bugzilla to 
 GitHub issues migration. Robert has fixed the blocker in the 
 app he wrote to perform it, and he and I have both confirmed 
 that it works as expected on a test repository.

 We have a planning session scheduled this week. Before I 
 initiate the migration, I need to make sure we're aware of all 
 of the consequences and how to handle them (e.g., dlang-bot, 
 moving Bugzilla to read-only, any instructions on the Wiki, 
 etc.).

 If you're aware of anything out there that we need to consider 
 once the issues are migrated, please let us know here.


I think your sentence here should read: "...that we need to 
consider *before* the issues are migrated..."

Do you have a link to a document that describes what the 
migration will do? (e.g. what will be done with the keywords, 
numbering, people on CC list, etc.)

-Johan
Jun 21 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 21 June 2023 at 16:51:13 UTC, Johan wrote:


 Do you have a link to a document that describes what the 
 migration will do? (e.g. what will be done with the keywords, 
 numbering, people on CC list, etc.)


No, there's no document. I've made the test repository public so 
you can see what the issues look like on GH:

https://github.com/dlang/bz2gh-test/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

All of the issues there come from the 'tools' component in 
Bugzilla. It appears nothing is done with the keywords, and I 
don't recall any discussion about it. Do you think they should 
become labels, or perhaps added as a list in the text of the GH 
issue? Do we *need* to keep them on the GH issue?

There's a command-line option I'll use when I do the migration 
that leaves a comment on each migrated Bugzilla issue, so the CC 
list should be notified of that. It will also ` ` mention people 
on GH, but I'm not sure if that includes those on the CC list.

I'll defer to Robert for more details.
Jun 21 2023
next sibling parent Robert Schadek <rschadek symmetryinvestments.com> writes:
On Thursday, 22 June 2023 at 02:34:46 UTC, Mike Parker wrote:

 I'll defer to Robert for more details.


The tool is rather simple,

1. Download all open bug from bugzilla, and get all the labels 
and stuff.
2. Send the stuff to github, and wait for an hour when github 
tells it off, because it reached the rate limit.
3. Write a comment into the bugzilla issue containing a link to 
the github issue.

The biggest part of the work was to match bugzilla profiles to 
github profiles.
Most code I wrote was figure that out. Many people have multiple 
bugzilla and multiple github profiles.
The stuff I wrote matched quite a few automatically, the rest I 
matched by hand and gave Michael that mapping table.

Will this mapping be perfect, no, but then I think I can never 
be, and also I think it doesn't need to be.
To make it perfect, I'll likely would need access to everybodies 
email ;-)
Jun 22 2023
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 02:34:46 UTC, Mike Parker wrote:

 On Wednesday, 21 June 2023 at 16:51:13 UTC, Johan wrote:


 Do you have a link to a document that describes what the 
 migration will do? (e.g. what will be done with the keywords, 
 numbering, people on CC list, etc.)


 No, there's no document. I've made the test repository public 
 so you can see what the issues look like on GH:

 https://github.com/dlang/bz2gh-test/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc


I still see some issues:

- Please import one BZ comment as one GH comment, so that it's 
still possible to link to a comment. Comments to links should be 
converted to point to the right comment, or else we may lose 
context.

- Please put the description and every comment in a Markdown 
block, otherwise things are going to be corrupted due to the 
Markdown formatting.

- Please try it with some bugs from the DMD project before doing 
the real migration. You should see a much higher variety of 
"interesting" bug reports that you would not see otherwise.

- Make sure to actually try moving ALL bugs to a private test 
repository before doing the real migration, for the same reasons.

- Have you considered using the same software that the LLVM 
project used for their migration? Writing our own tool seems 
wasteful if existing proven software exists.

- We have agreed that a prerequisite of doing this migration was 
ensuring that we can still download the entire data off of 
GitHub, and/or that we maintain a live independent copy/backup in 
case we lose access to the data. Has this been done?
Jun 22 2023
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 15:50:06 UTC, Vladimir Panteleev 
wrote:

 - Please put the description and every comment in a Markdown 
 block, otherwise things are going to be corrupted due to the 
 Markdown formatting.


Markdown code block*

Case in point:
https://github.com/dlang/bz2gh-test/issues/104
Jun 22 2023
prev sibling next sibling parent reply Robert Schadek <rschadek symmetryinvestments.com> writes:
On Thursday, 22 June 2023 at 15:50:06 UTC, Vladimir Panteleev 
wrote:

 I still see some issues:

 - Please import one BZ comment as one GH comment, so that it's 
 still possible to link to a comment. Comments to links should 
 be converted to point to the right comment, or else we may lose 
 context.


No, github is rate limited, 100 writes per ip per hour. One 
comment at a time
will end this migration project.


 - Please put the description and every comment in a Markdown 
 block, otherwise things are going to be corrupted due to the 
 Markdown formatting.

 - Please try it with some bugs from the DMD project before 
 doing the real migration. You should see a much higher variety 
 of "interesting" bug reports that you would not see otherwise.

 - Make sure to actually try moving ALL bugs to a private test 
 repository before doing the real migration, for the same 
 reasons.


I think this is just stalling stuff, nobody has time to take a 
meaningful look at all the dmd issues. Nothing is lost in the 
migration as the old data still exists in the same place.


 - Have you considered using the same software that the LLVM 
 project used for their migration? Writing our own tool seems 
 wasteful if existing proven software exists.


They have no software they have people 
https://github.com/llvm/llvm-iwg/issues/56#issuecomment-1001707975 basically
they have github people doing the have lifting.


 - We have agreed that a prerequisite of doing this migration 
 was ensuring that we can still download the entire data off of 
 GitHub, and/or that we maintain a live independent copy/backup 
 in case we lose access to the data. Has this been done?


Live was never on the table. I have not written the tool. But 
that tool is easy.
Jun 23 2023
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 23 June 2023 at 08:34:43 UTC, Robert Schadek wrote:

 No, github is rate limited, 100 writes per ip per hour. One 
 comment at a time will end this migration project.

 [...]

 They have no software they have people 
 https://github.com/llvm/llvm-iwg/issues/56#issuecomment-1001707975 basically
they have github people doing the have lifting.


It's surely both, right?

In any case, have we tried reaching out to GitHub to see if they 
can do the same for us?

If that doesn't work, we can do an incremental migration, with 
issues being moved one by one. Then, it is not time constrained.


 nobody has time to take a meaningful look at all the dmd issues.


We definitely shouldn't look at all of them, but a good sample of 
combinations of various interesting things like attachments or 
different formatting of example programs would be useful to check.


 Nothing is lost in the migration as the old data still exists 
 in the same place.


You're right that it should be possible to improve the formatting 
of imported issues after-the-fact, by editing the issue 
descriptions and comments. So, we should focus on things that 
will be difficult to change after-the-fact, such as URLs, 
preserving issue numbers, and preserving the comments-to-comments 
mapping.


 I think this is just stalling stuff


No. Please, let's get this right. If you are not interested in 
ensuring we do everything to get it right, please let me know and 
I'll continue from here.

As I mentioned at the meeting from 2021, I'm not against 
migrating, but it needs to be done well so that we have no 
regrets afterwards.
Jun 23 2023
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 6/23/23 10:42, Vladimir Panteleev wrote:

 

 I think this is just stalling stuff


 
 No. Please, let's get this right. If you are not interested in ensuring 
 we do everything to get it right, please let me know and I'll continue 
 from here.
 
 As I mentioned at the meeting from 2021, I'm not against migrating, but 
 it needs to be done well so that we have no regrets afterwards.


+1.
Jun 23 2023
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 22 June 2023 at 15:50:06 UTC, Vladimir Panteleev 
wrote:


 I still see some issues:

 - Please import one BZ comment as one GH comment, so that it's 
 still possible to link to a comment. Comments to links should 
 be converted to point to the right comment, or else we may lose 
 context.

 - Please put the description and every comment in a Markdown 
 block, otherwise things are going to be corrupted due to the 
 Markdown formatting.


Sounds good. I'll discuss it with Robert.


 - Please try it with some bugs from the DMD project before 
 doing the real migration. You should see a much higher variety 
 of "interesting" bug reports that you would not see otherwise.

 - Make sure to actually try moving ALL bugs to a private test 
 repository before doing the real migration, for the same 
 reasons.


Agreed.



 - Have you considered using the same software that the LLVM 
 project used for their migration? Writing our own tool seems 
 wasteful if existing proven software exists.


I didn't look into it. I think Mathias did when he first explored 
this a couple years ago, but I may be wrong.


 - We have agreed that a prerequisite of doing this migration 
 was ensuring that we can still download the entire data off of 
 GitHub, and/or that we maintain a live independent copy/backup 
 in case we lose access to the data. Has this been done?


There are a few different options out there for this. We can 
download everything anytime via GitHub's API. GH actually 
[released a tool for 
this](https://github.com/github/github-artifact-exporter) a 
couple of years ago, but archived the repo a few months back. 
However, I'm leaning toward a paid service that makes regular 
backups of designated repositories to a cloud storage provider 
(which would be Google Drive in our case).
Jun 23 2023
prev sibling next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 02:34:46 UTC, Mike Parker wrote:

 It appears nothing is done with the keywords, and I don't 
 recall any discussion about it.


Yes, you need to migrate the keywords. Otherwise, it won't be 
possible to search for wrong-code or rejects-valid bugs.
Jun 22 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2023 7:34 PM, Mike Parker wrote:

 It appears 
 nothing is done with the keywords, and I don't recall any discussion about it. 
 Do you think they should become labels, or perhaps added as a list in the text 
 of the GH issue? Do we *need* to keep them on the GH issue?


I rely on them a lot. When I enter bug fixing mode for a particular topic, such 
as DLLs, I rely on the DLL keyword to give me an overview of all the issues
with 
DLLs. It takes a bit to get up to speed on a particular topic, so it's more 
efficient to deal with several closely related issues at a time.

So, yes, I need them, and converting them to labels sounds ideal.
Jun 22 2023
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Jun 21, 2023 at 04:46:06PM +0000, Mike Parker via Digitalmars-d wrote:

 We're much closer now to pulling the trigger on the Bugzilla to GitHub
 issues migration. Robert has fixed the blocker in the app he wrote to
 perform it, and he and I have both confirmed that it works as expected
 on a test repository.
 
 We have a planning session scheduled this week. Before I initiate the
 migration, I need to make sure we're aware of all of the consequences
 and how to handle them (e.g., dlang-bot, moving Bugzilla to read-only,
 any instructions on the Wiki, etc.).
 
 If you're aware of anything out there that we need to consider once
 the issues are migrated, please let us know here.


[...]

How will existing accounts on Bugzilla be handled?  I have a list of
issues I'm monitoring on Bugzilla, but I don't think there will be an
easy way to import these to Github.  It will not be automatic, for sure,
since I use different credentials for both.  But it will be painful to
have to manually resubscribe to individual issues on my monitor list. Is
there any way to semi-automate this?


T

-- 
Маленькие детки - маленькие бедки.
Jun 21 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 21 June 2023 at 17:01:31 UTC, H. S. Teoh wrote:


 How will existing accounts on Bugzilla be handled?  I have a 
 list of issues I'm monitoring on Bugzilla, but I don't think 
 there will be an easy way to import these to Github.  It will 
 not be automatic, for sure, since I use different credentials 
 for both.  But it will be painful to have to manually 
 resubscribe to individual issues on my monitor list. Is there 
 any way to semi-automate this?


There's a JSON file that matches Bugzilla IDs with GH IDs. Yours 
are in there. I don't know if there's a way via the GH API to 
automatically subscribe users to specific issues, or if the app 
does it. If there is and it doesn't, then that seems like 
something we should consider adding.

Again, I'll defer to Robert for the details.
Jun 21 2023
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 22 June 2023 at 02:40:01 UTC, Mike Parker wrote:

 On Wednesday, 21 June 2023 at 17:01:31 UTC, H. S. Teoh wrote:


 How will existing accounts on Bugzilla be handled?  I have a 
 list of issues I'm monitoring on Bugzilla, but I don't think 
 there will be an easy way to import these to Github.  It will 
 not be automatic, for sure, since I use different credentials 
 for both.  But it will be painful to have to manually 
 resubscribe to individual issues on my monitor list. Is there 
 any way to semi-automate this?


 There's a JSON file that matches Bugzilla IDs with GH IDs. 
 Yours are in there. I don't know if there's a way via the GH 
 API to automatically subscribe users to specific issues, or if 
 the app does it. If there is and it doesn't, then that seems 
 like something we should consider adding.

 Again, I'll defer to Robert for the details.


Will this work with email address's that are not the primary in 
GH? My Bugzilla email is different than my GH, so I added my 
Bugzilla email as a secondary email in GH.
Jun 22 2023
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 22 June 2023 at 08:33:24 UTC, Adam Wilson wrote:

 On Thursday, 22 June 2023 at 02:40:01 UTC, Mike Parker wrote:

 There's a JSON file that matches Bugzilla IDs with GH IDs. 
 Yours are in there. I don't know if there's a way via the GH 
 API to automatically subscribe users to specific issues, or if 
 the app does it. If there is and it doesn't, then that seems 
 like something we should consider adding.

 Again, I'll defer to Robert for the details.


 Will this work with email address's that are not the primary in 
 GH? My Bugzilla email is different than my GH, so I added my 
 Bugzilla email as a secondary email in GH.


Not sure what the "this" in your question refers to.
Jun 22 2023
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Wednesday, 21 June 2023 at 16:46:06 UTC, Mike Parker wrote:

 If you're aware of anything out there that we need to consider 
 once the issues are migrated, please let us know here.


Will probably need to update the website to let people know where 
to file bugs: https://dlang.org/bugstats.html

Also the `Report a bug` button that's shown on every page.

----

One thing that will be hard to keep track of is finding the list 
of active bugs that a person has filed since the issue author on 
Github will be different.

But maybe that's not a problem if we let Bugzilla stay up in 
read-only mode?

Otherwise if Bugzilla will be shut down I'd suggest adding 
something like `reported-by: <user>` in the transferred issue's 
comment to perhaps make it easy to search using the Github UI?

This shouldn't block migration, a comment like this can easily be 
added later on.

The use-case here is I like to keep track of bugs I've opened to 
see if any have been resolved. When they get resolved I can 
remove any relevant workarounds in my code.
Jun 21 2023
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Jun 22, 2023 at 03:17:35AM +0000, Andrej Mitrovic via Digitalmars-d
wrote:
[...]

 One thing that will be hard to keep track of is finding the list of
 active bugs that a person has filed since the issue author on Github
 will be different.
 
 But maybe that's not a problem if we let Bugzilla stay up in read-only
 mode?
 
 Otherwise if Bugzilla will be shut down I'd suggest adding something
 like `reported-by: <user>` in the transferred issue's comment to
 perhaps make it easy to search using the Github UI?
 
 This shouldn't block migration, a comment like this can easily be
 added later on.
 
 The use-case here is I like to keep track of bugs I've opened to see
 if any have been resolved. When they get resolved I can remove any
 relevant workarounds in my code.


Me too!

Perhaps Bugzilla get stay up temporarily during the transition period,
read-only to users but perhaps writeable to say the dlang bot, so that
when github issues get closed Bugzilla can be updated too? It would be
annoying to track otherwise.  I have several projects with version()'d
workarounds named like `version(bug12345)`; when the bugzilla issue is
closed I can search for these and disable them.  But after the GH
migration issue numbers will change, and this makes it hard to track
what's fixed.


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Jun 21 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 22 June 2023 at 04:31:42 UTC, H. S. Teoh wrote:

 On Thu, Jun 22, 2023 at 03:17:35AM +0000, Andrej Mitrovic via 
 Digitalmars-d wrote: [...]

 One thing that will be hard to keep track of is finding the 
 list of active bugs that a person has filed since the issue 
 author on Github will be different.
 
 But maybe that's not a problem if we let Bugzilla stay up in 
 read-only mode?
 
 Otherwise if Bugzilla will be shut down I'd suggest adding 
 something like `reported-by: <user>` in the transferred 
 issue's comment to perhaps make it easy to search using the 
 Github UI?
 
 This shouldn't block migration, a comment like this can easily 
 be added later on.
 
 The use-case here is I like to keep track of bugs I've opened 
 to see if any have been resolved. When they get resolved I can 
 remove any relevant workarounds in my code.


 Me too!

 Perhaps Bugzilla get stay up temporarily during the transition 
 period, read-only to users but perhaps writeable to say the 
 dlang bot, so that when github issues get closed Bugzilla can 
 be updated too? It would be annoying to track otherwise.  I 
 have several projects with version()'d workarounds named like 
 `version(bug12345)`; when the bugzilla issue is closed I can 
 search for these and disable them.  But after the GH migration 
 issue numbers will change, and this makes it hard to track 
 what's fixed.


The Bugzilla instance isn't going anywhere. At some point, we 
need to get it migrated away from Brad's server to a DLF server 
so that we can have full admin access and ensure that it stays 
around. I like the idea of keeping dlang-bot's write access once 
it goes read-only. All of that's going to require coordinating 
with Brad, so I can't really put it on a timeline.
Jun 22 2023
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 07:03:00 UTC, Mike Parker wrote:

 All of that's going to require coordinating with Brad, so I 
 can't really put it on a timeline.


I have been waiting for over a year now to get the missing files 
from Brad for the new Bugzilla, so we probably probably shouldn't 
hold our breath on this.
Jun 22 2023
parent reply Brad Roberts <braddr puremagic.com> writes:
On 6/22/2023 9:10 AM, Vladimir Panteleev via Digitalmars-d wrote:

 On Thursday, 22 June 2023 at 07:03:00 UTC, Mike Parker wrote:

 All of that's going to require coordinating with Brad, so I can't 
 really put it on a timeline.


 
 I have been waiting for over a year now to get the missing files from 
 Brad for the new Bugzilla, so we probably probably shouldn't hold our 
 breath on this.


What files are you seeking?  More or less everything about the 
configuration, aside from things like the database host name, uid, and 
password for the db are managed inside the instance itself, all of which 
is visible through the ui, and those aren't particularly useful to have.
Jun 22 2023
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 20:22:46 UTC, Brad Roberts wrote:

 What files are you seeking?  More or less everything about the 
 configuration, aside from things like the database host name, 
 uid, and password for the db are managed inside the instance 
 itself, all of which is visible through the ui, and those 
 aren't particularly useful to have.


Hi Brad!

Looking at my records, I am missing the files localconfig and 
data/params.

Yes, the files contain parameters which can be configured from 
the user interface, however they also contain things which are 
not available from the user interface. One of these, for example, 
is a key which is used when calculating users' credentials. 
Without it, we would need to force everyone to reset their 
passwords (which may be a problem for people who no longer have 
access to the email address they use to log in to Bugzilla).

Thanks!
Jun 22 2023
parent reply Brad Roberts <braddr puremagic.com> writes:
On 6/22/2023 1:35 PM, Vladimir Panteleev via Digitalmars-d wrote:

 On Thursday, 22 June 2023 at 20:22:46 UTC, Brad Roberts wrote:

 What files are you seeking?  More or less everything about the 
 configuration, aside from things like the database host name, uid, and 
 password for the db are managed inside the instance itself, all of 
 which is visible through the ui, and those aren't particularly useful 
 to have.


 
 Hi Brad!
 
 Looking at my records, I am missing the files localconfig and data/params.
 
 Yes, the files contain parameters which can be configured from the user 
 interface, however they also contain things which are not available from 
 the user interface. One of these, for example, is a key which is used 
 when calculating users' credentials. Without it, we would need to force 
 everyone to reset their passwords (which may be a problem for people who 
 no longer have access to the email address they use to log in to Bugzilla).
 
 Thanks!


I don't understand why you need that key or to mess with users accounts 
or passwords at all.  That sounds like a pretty major security and trust 
violation to me.  Everything else in localconfig is just site specific 
params (like paths to various executables).  data/params is all 
available in the ui, but here:

%param = (
            'LDAPBaseDN' => '',
            'LDAPbinddn' => '',
            'LDAPfilter' => '',
            'LDAPmailattribute' => 'mail',
            'LDAPserver' => '',
            'LDAPstarttls' => 0,
            'LDAPuidattribute' => 'uid',
            'RADIUS_NAS_IP' => '',
            'RADIUS_email_suffix' => '',
            'RADIUS_secret' => '',
            'RADIUS_server' => '',
            'ajax_user_autocompletion' => '1',
            'allow_attachment_deletion' => 0,
            'allow_attachment_display' => 0,
            'allowbugdeletion' => '0',
            'allowemailchange' => 1,
            'allowuserdeletion' => 0,
            'announcehtml' => '',
            'attachment_base' => '',
            'auth_env_email' => '',
            'auth_env_id' => '',
            'auth_env_realname' => '',
            'bonsai_url' => '',
            'chartgroup' => 'editbugs',
            'commentonchange_resolution' => 0,
            'commentonduplicate' => 0,
            'confirmuniqueusermatch' => 1,
            'cookiedomain' => '',
            'cookiepath' => '/',
            'createemailregexp' => '.*',
            'cvsroot' => '',
            'cvsroot_get' => '',
            'debug_group' => 'admin',
            'default_search_limit' => '500',
            'defaultopsys' => '',
            'defaultplatform' => '',
            'defaultpriority' => '---',
            'defaultquery' => 
'resolution=---&emailassigned_to1=1&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailqa_contact2=1&emaillongdesc3=1&order=Importance&long_desc_type=substring',
            'defaultseverity' => 'enhancement',
            'docs_urlbase' => 'docs/%lang%/html/',
            'duplicate_or_move_bug_status' => 'RESOLVED',
            'emailregexp' => '^[\\w\\.\\+\\-=]+ [\\w\\.\\-]+\\.[\\w\\-]+$',
            'emailregexpdesc' => 'A legal address must contain exactly 
one \' \', and at least one \'.\' after the  .',
            'emailsuffix' => '',
            'globalwatchers' => '',
            'inbound_proxies' => '',
            'insidergroup' => '',
            'letsubmitterchoosemilestone' => 1,
            'letsubmitterchoosepriority' => 1,
            'lxr_root' => '',
            'lxr_url' => '',
            'mail_delivery_method' => 'SMTP',
            'mailfrom' => 'd-bugmail puremagic.com',
            'maintainer' => 'braddr puremagic.com',
            'makeproductgroups' => 0,
            'max_search_results' => '10000',
            'maxattachmentsize' => '1000',
            'maxlocalattachment' => '0',
            'maxusermatches' => '1000',
            'mostfreqthreshold' => '2',
            'musthavemilestoneonaccept' => 0,
            'mybugstemplate' => 
'buglist.cgi?resolution=---&amp;emailassigned_to1=1&amp;emailreporter1=1&amp;emailtype1=exact&amp;email1=%userid%',
            'noresolveonopenblockers' => 0,
            'password_complexity' => 'no_constraints',
            'proxy_url' => '',
            'querysharegroup' => 'editbugs',
            'quip_list_entry_control' => 'moderated',
            'rememberlogin' => 'on',
            'requirelogin' => '0',
            'search_allow_no_criteria' => 1,
            'shadowdb' => '',
            'shadowdbhost' => '',
            'shadowdbport' => '3306',
            'shadowdbsock' => '',
            'shutdownhtml' => '',
            'smtp_debug' => '0',
            'smtp_password' => '',
            'smtp_ssl' => '0',
            'smtp_username' => '',
            'smtpserver' => 'mail.puremagic.com',
            'ssl_redirect' => '1',
            'sslbase' => 'https://issues.dlang.org/',
            'strict_isolation' => 0,
            'strict_transport_security' => 'off',
            'timetrackinggroup' => '',
            'upgrade_notification' => 'latest_stable_release',
            'urlbase' => 'https://issues.dlang.org/',
            'use_mailer_queue' => '1',
            'use_see_also' => 1,
            'useclassification' => 0,
            'usemenuforusers' => '0',
            'useqacontact' => 0,
            'user_info_class' => 'CGI',
            'user_verify_class' => 'DB',
            'usestatuswhiteboard' => 0,
            'usetargetmilestone' => 0,
            'usevisibilitygroups' => 0,
            'utf8' => 1,
            'webdotbase' => '/usr/bin/dot',
            'whinedays' => 7
          );
Jun 22 2023
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 20:48:25 UTC, Brad Roberts wrote:

 I don't understand why you need that key or to mess with users 
 accounts or passwords at all.  That sounds like a pretty major 
 security and trust violation to me.


Well, because the ultimate goal is moving the entire 
installation, and making it seamless. The DFL needs access to the 
key for the same reason that you have access to the key right now.

If you don't want *me* to have access to the key, that's fine, I 
can work with someone else from the DFL on a IaC setup where I 
don't have access to production data, but let's clear up where 
the problem is first?

If it helps, I run the D forum and wiki, so not much would change 
in the trust model.


 data/params is all available in the ui, but here:


Thanks! It's good to have it in text form anyway.
Jun 22 2023
prev sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 03:17:35 UTC, Andrej Mitrovic wrote:

 One thing that will be hard to keep track of is finding the 
 list of active bugs that a person has filed since the issue 
 author on Github will be different.


When the LLVM project moved from Bugzilla to GitHub, they used 
something that allowed Bugzilla contributors to link their 
imported contributions with their GitHub account, so that the 
issue was posted in their name. Everyone else was posted with 
their Bugzilla name but as a special "mannequin" kind of user.

https://github.com/burner/D_bugzilla_to_github/issues/1

Robert, have you looked into this?
Jun 22 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2023 9:46 AM, Mike Parker wrote:

 If you're aware of anything out there that we need to consider once the issues 
 are migrated, please let us know here.


Need an algorithm where links to bugzilla will be converted to the correct 
github issue link.
Jun 22 2023
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 18:56:19 UTC, Walter Bright wrote:

 On 6/21/2023 9:46 AM, Mike Parker wrote:

 If you're aware of anything out there that we need to consider 
 once the issues are migrated, please let us know here.


 Need an algorithm where links to bugzilla will be converted to 
 the correct github issue link.


I think this is doable in the following way:

1. Create a new GitHub repository, e.g. github.com/dlang/issues
2. Transfer the issues from Bugzilla, taking care to preserve the 
issue number. So, https://issues.dlang.org/show_bug.cgi?id=12345 
is recreated at https://github.com/dlang/issues/issues/12345
3. Move the issue from the issues project to the corresponding 
project (e.g. dmd).

Moving the issue will leave behind a redirect, so that 
https://github.com/dlang/issues/issues/12345 will continue to 
work and therefore allow a trivial remapping. This will be useful 
should we eventually decide to completely retire Bugzilla and 
replace it with a site that only hosts redirects.
Jun 22 2023
prev sibling parent reply CM <celestialmachinist proton.me> writes:
On Wednesday, 21 June 2023 at 16:46:06 UTC, Mike Parker wrote:

 We're much closer now to pulling the trigger on the Bugzilla to 
 GitHub issues migration. Robert has fixed the blocker in the 
 app he wrote to perform it, and he and I have both confirmed 
 that it works as expected on a test repository.

 [...]


May one assume that the investigation into using a newer version 
of bugzilla (e.g. mozilla's instance) didn't pan out well? Just 
curious is all.
Jun 22 2023
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 20:09:54 UTC, CM wrote:

 On Wednesday, 21 June 2023 at 16:46:06 UTC, Mike Parker wrote:

 We're much closer now to pulling the trigger on the Bugzilla 
 to GitHub issues migration. Robert has fixed the blocker in 
 the app he wrote to perform it, and he and I have both 
 confirmed that it works as expected on a test repository.

 [...]


 May one assume that the investigation into using a newer 
 version of bugzilla (e.g. mozilla's instance) didn't pan out 
 well? Just curious is all.


1. I never received the missing data from the current Bugzilla's 
admin... :(

2. Ideologically, it's an uphill battle as almost everyone just 
wants to use GitHub, and would not prefer to use Bugzilla no 
matter how good it is.
Jun 22 2023
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, June 22, 2023 2:12:34 PM MDT Vladimir Panteleev via Digitalmars-d 
wrote:

 2. Ideologically, it's an uphill battle as almost everyone just
 wants to use GitHub, and would not prefer to use Bugzilla no
 matter how good it is.


I've never understood why some folks have kept pushing for us to use github
issues. They're nice if you're setting up a github repo and don't want to go
to the trouble of setting up and hosting a bugzilla instance elsewhere, but
they're not as sophisticated as bugzilla.

- Jonathan M Davis
Jun 22 2023
next sibling parent reply Elias <desisma heidel.beer> writes:
On Thursday, 22 June 2023 at 20:48:09 UTC, Jonathan M Davis wrote:

 but they're not as sophisticated as bugzilla.


Though GitHub seems to have a more sophisticated spam 
“protection” strategy than straight out blocking all Gmail 
addresses.

Feel free to choose whether
- those in charge didn’t bother to fix it resp. where unavailable
- or were unable/incapable to fix.
That makes no difference. There’ve been complaints about this 
policy for years. And effectively, they fell on deaf ears – in 
terms of outcome.

Getting people to create yet another account (for the Bugzilla 
instance) is one thing, forcing them to create an additional 
email account is another. From that perspective I’d say, GitHub 
issues is a huge win for us all.
Jun 22 2023
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 22 June 2023 at 21:40:34 UTC, Elias wrote:

 On Thursday, 22 June 2023 at 20:48:09 UTC, Jonathan M Davis 
 wrote:

 but they're not as sophisticated as bugzilla.


 Though GitHub seems to have a more sophisticated spam 
 “protection” strategy than straight out blocking all Gmail 
 addresses.

 Feel free to choose whether
 - those in charge didn’t bother to fix it resp. where 
 unavailable
 - or were unable/incapable to fix.
 That makes no difference. There’ve been complaints about this 
 policy for years. And effectively, they fell on deaf ears – in 
 terms of outcome.


I'm sorry about banning Gmail addresses. It was the best way to 
stop the flood of spam that I could find at the time. I only have 
limited access to the Bugzilla server, and Brad was too busy with 
other things to do something more sophisticated.


 From that perspective I’d say, GitHub issues is a huge win for 
 us all.


On newer Bugzilla versions, you can log in with your GitHub 
account. You can try it on https://bugzilla.mozilla.org/.

The crude spam measures like the Gmail ban would also hopefully 
not be needed once the DLF runs the Bugzilla instance.
Jun 22 2023
prev sibling parent reply Robert Schadek <rschadek symmetryinvestments.com> writes:
On Thursday, 22 June 2023 at 20:48:09 UTC, Jonathan M Davis wrote:


 I've never understood why some folks have kept pushing for us 
 to use github issues. They're nice if you're setting up a 
 github repo and don't want to go to the trouble of setting up 
 and hosting a bugzilla instance elsewhere, but they're not as 
 sophisticated as bugzilla.

 - Jonathan M Davis


Because its not about the features, its about the people. D's 
bugzilla has none, github has all of them.
Jun 23 2023
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, June 23, 2023 2:14:29 AM MDT Robert Schadek via Digitalmars-d 
wrote:

 On Thursday, 22 June 2023 at 20:48:09 UTC, Jonathan M Davis wrote:

 I've never understood why some folks have kept pushing for us
 to use github issues. They're nice if you're setting up a
 github repo and don't want to go to the trouble of setting up
 and hosting a bugzilla instance elsewhere, but they're not as
 sophisticated as bugzilla.

 - Jonathan M Davis


 Because its not about the features, its about the people. D's
 bugzilla has none, github has all of them.


I'm afraid that I don't understand your logic. When you want to report a bug
for a project, you go to wherever that project handles bug reports. In that
respect, whether it's bugzilla or github or wherever is irrelevant. I don't
see how the fact that a lot of people use github for code has anything do
with how we handle bug reports.

Walter and company will decide whatever they decide for this, and if that
means going to github issues, I guess that it means going to github issues,
but it seems to me that it's making things worse, because we'll be switching
to an inferior tool. And I truly don't understand how any of it is about the
people. Are you afraid that people are too lazy to report bugs via bugzilla
or something and that using github issues will somehow overcome that?

- Jonathan M Davis
Jun 23 2023
next sibling parent reply Robert Schadek <rschadek symmetryinvestments.com> writes:
On Friday, 23 June 2023 at 08:59:56 UTC, Jonathan M Davis wrote:

 I'm afraid that I don't understand your logic. When you want to 
 report a bug for a project, you go to wherever that project 
 handles bug reports. In that respect, whether it's bugzilla or 
 github or wherever is irrelevant. I don't see how the fact that 
 a lot of people use github for code has anything do with how we 
 handle bug reports.


I fear you're wrong.
If a regular (not on this forum person) goes to actually write a 
bug-report.
They go like.

1. google dlang
2. WAT issues are in a tool I have to log in that is not github; 
I can not be bothered.


 Walter and company will decide whatever they decide for this, 
 and if that means going to github issues, I guess that it means 
 going to github issues, but it seems to me that it's making 
 things worse, because we'll be switching to an inferior tool. 
 And I truly don't understand how any of it is about the people. 
 Are you afraid that people are too lazy to report bugs via 
 bugzilla or something and that using github issues will somehow 
 overcome that?


I'm not afraid that people are too lazy, I'm convinced, and IMHO 
right, that people are too lazy report anywhere but github.
Github helps as everybody knows it, and there is no friction at 
all.
Jun 23 2023
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 6/23/23 11:53, Robert Schadek wrote:

 Walter and company will decide whatever they decide for this, and if 
 that means going to github issues, I guess that it means going to 
 github issues, but it seems to me that it's making things worse, 
 because we'll be switching to an inferior tool. And I truly don't 
 understand how any of it is about the people. Are you afraid that 
 people are too lazy to report bugs via bugzilla or something and that 
 using github issues will somehow overcome that?


 
 I'm not afraid that people are too lazy, I'm convinced, and IMHO right, 
 that people are too lazy report anywhere but github.
 Github helps as everybody knows it, and there is no friction at all.
 


Yes, unfortunately it is true that many people won't report issues on 
bugzilla. Preserving the existing issues is still really important as 
well. Those are issues reported by _enthusiastic people who let 
themselves be assed to report on bugzilla_, and we owe them to treat 
their issues well. In particular, I think moving issues to github issues 
and giving all the github contributions/authorship for those issues to 
yourself and Mike is a terrible way to move forward, even if the issues 
are technically in the public domain and/or belong to DLF.
Jun 23 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 23 June 2023 at 12:31:39 UTC, Timon Gehr wrote:

 On 6/23/23 11:53, Robert Schadek wrote:







 Yes, unfortunately it is true that many people won't report 
 issues on bugzilla. Preserving the existing issues is still 
 really important as well. Those are issues reported by 
 _enthusiastic people who let themselves be assed to report on 
 bugzilla_, and we owe them to treat their issues well. In 
 particular, I think moving issues to github issues and giving 
 all the github contributions/authorship for those issues to 
 yourself and Mike is a terrible way to move forward, even if 
 the issues are technically in the public domain and/or belong 
 to DLF.


For the record, I intend to create a special account for adding 
the issues to GitHub (e.g., "bugzilla_migration"). I certainly 
don't want them all in my name. I don't see how we can post them 
as the original user, though. From what I understand, it requires 
the id and a token.



 Jun 23 2023



 next sibling parent  Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Friday, 23 June 2023 at 13:01:35 UTC, Mike Parker wrote:

 I don't see how we can post them as the original user, though. 
 From what I understand, it requires the id and a token.


The LLVM folks did it:

https://github.com/burner/D_bugzilla_to_github/issues/1

You can "claim your contributions", in which case they will 
appear as your personal GitHub account. If you don't do that, 
they will still be posted with the original user's name, as a 
special GitHub "mannequin" user.

We should research the possibility too.



 Jun 23 2023



prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 6/23/23 15:01, Mike Parker wrote:

 On Friday, 23 June 2023 at 12:31:39 UTC, Timon Gehr wrote:

 On 6/23/23 11:53, Robert Schadek wrote:






 

 Yes, unfortunately it is true that many people won't report issues on 
 bugzilla. Preserving the existing issues is still really important as 
 well. Those are issues reported by _enthusiastic people who let 
 themselves be assed to report on bugzilla_, and we owe them to treat 
 their issues well. In particular, I think moving issues to github 
 issues and giving all the github contributions/authorship for those 
 issues to yourself and Mike is a terrible way to move forward, even if 
 the issues are technically in the public domain and/or belong to DLF.


 
 For the record, I intend to create a special account for adding the 
 issues to GitHub (e.g., "bugzilla_migration"). I certainly don't want 
 them all in my name. I don't see how we can post them as the original 
 user, though. From what I understand, it requires the id and a token.


My preference order:
1. Migrate all information that has a correspondence on github perfectly
2. Keep bugzilla, additionally allow github issues for new reports, 
synch issues into bugzilla
3. Keep status quo
4. Migrate single comments as bugzilla_migration user
5. ...

Of course, that's just my preference, not all of those are the same 
amount of effort, and some effort has already been spent. It would be 
great to explore Vladimir's suggestions. If we can do what LLVM did, 
that would be awesome.



 Jun 23 2023



  parent reply Mike Parker <aldacron gmail.com>  writes:


On Friday, 23 June 2023 at 15:52:16 UTC, Timon Gehr wrote:


 My preference order:
 1. Migrate all information that has a correspondence on github 
 perfectly



 Of course, that's just my preference, not all of those are the 
 same amount of effort, and some effort has already been spent. 
 It would be great to explore Vladimir's suggestions. If we can 
 do what LLVM did, that would be awesome.


So we've put the brakes on things for now. Robert is going to 
reach out to GitHub to see if they can do something for us like 
they did for LLVM. Then we'll hopefully be able to push the 
issues to GitHub under the original poster's handle. Of the 
issues raised here, that's the one thing we can't manage on our 
own.



 Jun 23 2023



 next sibling parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 24/06/2023 4:02 AM, Mike Parker wrote:

 Robert is going to reach out to GitHub to see if they can do something 
 for us like they did for LLVM.


Hopefully they can also up the rate limit too!

Would be worth asking about, even if it did cost a little bit.



 Jun 23 2023



prev sibling  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Friday, 23 June 2023 at 16:02:53 UTC, Mike Parker wrote:

 So we've put the brakes on things for now. Robert is going to 
 reach out to GitHub to see if they can do something for us like 
 they did for LLVM. Then we'll hopefully be able to push the 
 issues to GitHub under the original poster's handle. Of the 
 issues raised here, that's the one thing we can't manage on our 
 own.


Hey, we also need to make sure our infra is ready for this. The 
bots and the changelog generator need to be updated, at least.

I think the following plan will work:

1. Update DBot to only accept "Fix Bugzilla" instead of "Fix 
Issue". Put up a warning if the old string is used.
2. Update the changelog generator to accept both.
3. When the next release is cut, open up GitHub issues for our 
projects. (This is orthogonal to migrating issues from Bugzilla, 
right?) Users can now start filing bugs on GitHub.
4. Change DBot to accept both "Fix Bugzilla" and "Fix #xxxxx" 
where the latter refers to a GitHub issue. GitHub can auto-close 
referenced issues itself, so we may not need DBot to do anything 
here.
5. Migrate the issues one by one, leaving behind links on 
Bugzilla.
6. Make Bugzilla read-only.

I could work on DBot and the changelog generator?



 Jun 23 2023



  parent reply Mike Parker <aldacron gmail.com>  writes:


On Friday, 23 June 2023 at 17:56:44 UTC, Vladimir Panteleev wrote:

 On Friday, 23 June 2023 at 16:02:53 UTC, Mike Parker wrote:

 So we've put the brakes on things for now. Robert is going to 
 reach out to GitHub to see if they can do something for us 
 like they did for LLVM. Then we'll hopefully be able to push 
 the issues to GitHub under the original poster's handle. Of 
 the issues raised here, that's the one thing we can't manage 
 on our own.


 Hey, we also need to make sure our infra is ready for this. The 
 bots and the changelog generator need to be updated, at least.


Yes, we've discussed the bot, but the changelog generator hasn't 
come up. We need to be aware of anything in the ecosystem that 
may be affected. If you know of anything else, please let us know.


 I think the following plan will work:

 1. Update DBot to only accept "Fix Bugzilla" instead of "Fix 
 Issue". Put up a warning if the old string is used.
 2. Update the changelog generator to accept both.
 3. When the next release is cut, open up GitHub issues for our 
 projects. (This is orthogonal to migrating issues from 
 Bugzilla, right?) Users can now start filing bugs on GitHub.
 4. Change DBot to accept both "Fix Bugzilla" and "Fix #xxxxx" 
 where the latter refers to a GitHub issue. GitHub can 
 auto-close referenced issues itself, so we may not need DBot to 
 do anything here.
 5. Migrate the issues one by one, leaving behind links on 
 Bugzilla.
 6. Make Bugzilla read-only.


That looks like a good approach.


 I could work on DBot and the changelog generator?


I would love that. I'll pull you into our next discussion about 
it.



 Jun 23 2023



  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Saturday, 24 June 2023 at 01:55:11 UTC, Mike Parker wrote:

 If you know of anything else, please let us know.


Contributor documentation (CONTRIBUTING.md, maybe the wiki?).


 I think the following plan will work:

 1. Update DBot to only accept "Fix Bugzilla" instead of "Fix 
 Issue". Put up a warning if the old string is used.
 2. Update the changelog generator to accept both.
 3. When the next release is cut, open up GitHub issues for our 
 projects. (This is orthogonal to migrating issues from 
 Bugzilla, right?) Users can now start filing bugs on GitHub.
 4. Change DBot to accept both "Fix Bugzilla" and "Fix #xxxxx" 
 where the latter refers to a GitHub issue. GitHub can 
 auto-close referenced issues itself, so we may not need DBot 
 to do anything here.
 5. Migrate the issues one by one, leaving behind links on 
 Bugzilla.
 6. Make Bugzilla read-only.


 That looks like a good approach.


Here are the first two:

https://github.com/dlang/dlang-bot/pull/302
https://github.com/dlang/tools/pull/461



 Jun 24 2023



  parent  matheus <matheus gmail.com>  writes:


On Saturday, 24 June 2023 at 07:08:36 UTC, Vladimir Panteleev 
wrote:

 ...
 Here are the first two:
 ...


Awesomeand I think It would be cool if this proccess was recorded 
to be used later as how this migration problem was fuxed as a 
showcase for the D community.

Matheus



 Jun 24 2023



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 6/23/2023 6:01 AM, Mike Parker wrote:

 For the record, I intend to create a special account for adding the issues to 
 GitHub (e.g., "bugzilla_migration"). I certainly don't want them all in my
name. 
 I don't see how we can post them as the original user, though. From what I 
 understand, it requires the id and a token.


Can we add the original contributor as a comment?



 Jun 23 2023



  parent  Mike Parker <aldacron gmail.com>  writes:


On Friday, 23 June 2023 at 18:29:53 UTC, Walter Bright wrote:

 On 6/23/2023 6:01 AM, Mike Parker wrote:

 For the record, I intend to create a special account for 
 adding the issues to GitHub (e.g., "bugzilla_migration"). I 
 certainly don't want them all in my name. I don't see how we 
 can post them as the original user, though. From what I 
 understand, it requires the id and a token.


 Can we add the original contributor as a comment?


That already happens. The comment has a header with the 
contributor's name and the date it was submitted. E.g.,

https://github.com/dlang/bz2gh-test/issues/109

In the actual migration, the GitHub contributor and everyone on 
the CC list will get ` ` tagged in the comment.

However, it will be much better if we can submit the issue in the 
contributor's name.



 Jun 23 2023



prev sibling  parent reply Elias <desisma heidel.beer>  writes:


On Friday, 23 June 2023 at 08:59:56 UTC, Jonathan M Davis wrote:

 And I truly don't understand how any of it is about the people. 
 Are you afraid that people are too lazy to report bugs via 
 bugzilla or something and that using github issues will somehow 
 overcome that?


While my original comment about the spam defense issue wasn’t 
directed at you and I’ve been only using your comment as 
reference for my sarcastic remark, I’d like to invite you to come 
to Discord and throw “Gmail” into the search there.

… or actually… I don’t want to bother you with this… so I did the 
busywork for you :)




 For bugzilla, besides gmail restriction, are there any others?





 Because all our code is at GH, if you have a GH account you 
 don't need to create a Bugzilla account just to file, some 
 developers won't touch Bugzilla, we don't have direct admin 
 access to our Bugzilla (the admin disabled account creation 
 with gmail addresses because of spam), etc.


^ which btw also implies that the Bugzilla instance isn’t even 
exactly run by the DLF


 The gmail thing is truly egregious. I still don't understand it.



 Tons of people have gmail addresses […]. To exclude all of them 
 from posting bugs gives off the impression that we don’t care 
 about our bugs.





 i don't have bugzilla account 😦 and I remember it had some 
 troubles with gmail.. […]





 I bet the number of would-be bug reporters that have gmail 
 addresses that just don't do it is in the dozens by now. Is 
 this seriously still an issue?



 gmail can't post issue on zilla y?





 So I create a gmail account to register to the bugzilla, I mean 
 here it says that you can use Gmail: [screenshot]

 We recommend using a secondary account or free web email 
 service (such as Gmail, Yahoo, Hotmail, or similar) to avoid 
 receiving spam at your primary email address.


 
 So I have to go through the hassle of making a new google 
 account linking it with my phone to get notifications from the 
 bugzilla just to get told that they don't accept gmail after it 
 was clearly stated that I could use gmail?
 I'm done with this





 Okay, but I can't do that since I can't make an account there 
 (since it doesn't accept gmail)





 We really need to fix the "no gmail addresses on bugzilla" 
 problem.




1. > Is bugzilla the place to report phobos bugs?
1. > yes
    > issues.dlang.org
1. > The e-mail address you entered (blah.blah gmail.com) didn't 
pass our syntax checking for a legal email address. A legal 
address must contain exactly one ' ', and at least one '.' after 
the  . Currently, registering using Gmail addresses is not 
allowed due to spam. It also must not contain any illegal 
characters.
1. > you will need to post on the N.G. to get an account created 
manually
1. > Well in case anyone who has an account feels like reporting 
it.
std.experimental.logger broke


 Hey Mike, we had somebody get a deny on creating a bugzilla 
 account due to gmail email account






 Robert's argument for the move (and those who supported on it) 
 is that GitHub is where the developers are. We currently 
 require anyone submitting Bugzilla issues to create an account, 
 and account creation is currently disabled by the maintainer 
 for anyone with a gmail address because of spam!





 the issue tracker: "we recommend using gmail to avoid spam"
 also the issue tracker, but only after you enter a gmail 
 address: "Currently, registering using Gmail addresses is not 
 allowed due to spam."
 trolled



 blocking gmail adresses seems like a great idea




It comes up regulary.



 Jun 23 2023



 next sibling parent reply Elias <desisma heidel.beer>  writes:


On Friday, 23 June 2023 at 13:03:44 UTC, Elias wrote:

 Because all our code is at GH, if you have a GH account you 
 don't need to create a Bugzilla account just to file, some 
 developers won't touch Bugzilla, we don't have direct admin 
 access to our Bugzilla (the admin disabled account creation 
 with gmail addresses because of spam), etc.


 ^ which btw also implies that the Bugzilla instance isn’t even 
 exactly run by the DLF


To clarify:
I fail to see the advantage of a webservice that isn’t run by the 
DLF and where the DLF lacks essentials admin permissions is any 
better than the services provided by the forge that also hosts 
the DLF repos already.



 Jun 23 2023



 next sibling parent  Elias <desisma heidel.beer>  writes:


errata:


 I fail to see the advantage of a webservice that isn’t run by 
 the DLF and where the DLF lacks essentials admin permissions 
 [plus how it] is any better than the services provided by the 
 forge that also hosts the DLF repos already.





 Jun 23 2023



prev sibling  parent reply Mike Parker <aldacron gmail.com>  writes:


On Friday, 23 June 2023 at 13:10:04 UTC, Elias wrote:


 To clarify:
 I fail to see the advantage of a webservice that isn’t run by 
 the DLF and where the DLF lacks essentials admin permissions is 
 any better than the services provided by the forge that also 
 hosts the DLF repos already.


Keep in mind that all of our infrastructure was built up by 
volunteers with their own accounts on various services. We've had 
direct admin access to very little of it. We're in the process of 
bringing as much of it as we can under DLF control. So there was 
never a question of keeping the current Bugzilla instance 
forever. The question was, do we migrate to a new Bugzilla 
instance under our control, or to GitHub? We opted for GitHhub.



 Jun 23 2023



  parent  Elias <desisma heidel.beer>  writes:


On Friday, 23 June 2023 at 13:19:36 UTC, Mike Parker wrote:

 Keep in mind that all of our infrastructure was built up by 
 volunteers with their own accounts on various services.


Please don’t me wrong on that. My gratefulness and thanks to all 
of them who have invested their time and/or money into keeping up 
the infrastructure so far.



 Jun 23 2023



prev sibling  parent reply Vladimir Panteleev <thecybershadow.lists gmail.com>  writes:


On Friday, 23 June 2023 at 13:03:44 UTC, Elias wrote:

 While my original comment about the spam defense issue wasn’t 
 directed at you and I’ve been only using your comment as 
 reference for my sarcastic remark, I’d like to invite you to 
 come to Discord and throw “Gmail” into the search there.

 … or actually… I don’t want to bother you with this… so I did 
 the busywork for you :)


Oof, this is pretty bad. Each one of these should have been a 
prod to reevaluate the situation.

If our direction isn't clarified in the next few days, I'm going 
to try removing the ban. Hopefully we won't immediately drown in 
spam.


 Hey Mike, we had somebody get a deny on creating a bugzilla 
 account due to gmail email account




I assume Mike is Mike Parker? Mike, were you getting these?


 blocking gmail adresses seems like a great idea




Unfortunately, letting the spammers have free reign would have 
been much worse :(



 Jun 23 2023



  parent  "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz>  writes:


On 24/06/2023 3:11 AM, Vladimir Panteleev wrote:

         Hey Mike, we had somebody get a deny on creating a bugzilla
         account due to gmail email account
 
 I assume Mike is Mike Parker? Mike, were you getting these?


On 9/6/2022 I raised this on Discord with Mike about finding a solution 
to gmail blocking.

So its a well known set of issues.



 Jun 23 2023



prev sibling next sibling parent  "H. S. Teoh" <hsteoh qfbox.info>  writes:


On Thu, Jun 22, 2023 at 02:48:09PM -0600, Jonathan M Davis via Digitalmars-d
wrote:

 On Thursday, June 22, 2023 2:12:34 PM MDT Vladimir Panteleev via Digitalmars-d 
 wrote:

 2. Ideologically, it's an uphill battle as almost everyone just
 wants to use GitHub, and would not prefer to use Bugzilla no
 matter how good it is.


 
 I've never understood why some folks have kept pushing for us to use
 github issues. They're nice if you're setting up a github repo and
 don't want to go to the trouble of setting up and hosting a bugzilla
 instance elsewhere, but they're not as sophisticated as bugzilla.


[...]

Personally I also prefer to use Bugzilla.  I find GH's UI rather klunky
to use, esp. when it comes to searching for specific things.

But since the move to GH seems inevitable, I guess I'll just cope with
it. It's not a big deal.


T

-- 
I've been around long enough to have seen an endless parade of magic new
techniques du jour, most of which purport to remove the necessity of
thought about your programming problem.  In the end they wind up
contributing one or two pieces to the collective wisdom, and fade away
in the rearview mirror. -- Walter Bright



 Jun 22 2023



prev sibling  parent  Robert Schadek <rschadek symmetryinvestments.com>  writes:


On Thursday, 22 June 2023 at 20:12:34 UTC, Vladimir Panteleev 
wrote:

 2. Ideologically, it's an uphill battle as almost everyone just 
 wants to use GitHub, and would not prefer to use Bugzilla no 
 matter how good it is.


Yes, as moving to github is the right move. D needs to be where 
the people are, which is github.



 Jun 23 2023