www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D Language Foundation Monthly Meeting for February 2022

reply Mike Parker <aldacron gmail.com> writes:

The D Language Foundation's monthly meeting for February 2022 
took place on February 4 and lasted around 1.5 hours. The 
following foundation members, contractors, and contributors 
attended:

Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Martin Kinkelin
Mathias Lang
Átila Neves
Razvan Nitu
Vladimir Panteleev
Mike Parker


I opened the meeting with a question for Walter. After [a recent 
forum 
discussion](https://forum.dlang.org/post/aarigbnntabwbcuqsuzg forum.dlang.org),
someone had [submitted a DIP](https://github.com/dlang/DIPs/pull/222) that
would change the runtime behavior of the default `toString` implementation in
the `Exception` class such that it generates stack trace output only when an
environment variable is set. Should this be a DIP or an enhancement request in
Bugzilla? We had a brief discussion.

Vladimir pointed out that stack trace output is only useful when 
debug symbols are enabled.

Ali suggested that perhaps it could be configurable for 
`Exception`, but `Error` should always print. Átila and Mathias 
noted that anyone who wants this can just catch all `Exception`s 
in `main`. This doesn't handle static constructors, but they both 
said that static constructors that aren't `nothrow` are probably 
wrong anyway.

Walter said a DIP isn't needed---it's fine to post it in Bugzilla 
as an enhancement request.

Later, at the end of the meeting, Martin said he had looked into 
the DRuntime source. The stack trace handler is configurable by 
the user, so there may be no need for an enhancement request. It 
should be sufficient for the user to set the trace handler to a 
function that returns null.


Martin said he was eager to see news about the 2.099 release. He 
felt it was the right time for the stable branch to be updated as 
some important breaking changes had recently made it into the 
compiler. This brought about a discussion about the number of the 
next version after 2.099: should it be 2.0100 or 2.100? The 
latter would match what we did with the pre-1.0 releases, which 
[went up to 
0.178](https://digitalmars.com/d/1.0/changelog2.html). We moved 
on quickly from this discussion without any definitive statement, 
but my impression is that we're leaning toward 2.100.

The beta for 2.099 [was announced on February 
17](https://forum.dlang.org/thread/vlyynedwupodqcytjptn forum.dlang.org).

Martin later reported that he has worked on template emission in 
unit test mode. When compiling with `-unittest`, it used to 
behave similarly to `-allinst`, but now emissions have been 
significantly reduced. The best benchmark of ~20 projects from 
Átila showed a 36% reduction in memory usage and compile time. 
There are still some things that can be culled even more.


Iain said the most productive thing he'd done over the previous 
month was removing ~5,000 LOC from DRuntime in the form of 
redundant bindings. Other than that, he agreed with Martin about 
the stable branch.


Vladimir opened with a progress report. Back in December, [we 
discussed migrating our Bugzilla issues to 
Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwqehz forum.dlang.org). An
alternative solution is to [upgrade to Bugzilla
Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been
contributing to for some time. After that meeting, we agreed that Robert
Schadek would move forward with implementing his migration script, while
Vladimir would get the new Bugzilla instance set up so we can test it out in
the interim.

Unfortunately, he reported that he has encountered a blocker. He 
needs the configuration files for our active Bugzilla instance, 
but the maintainer has so far been unresponsive. For now, he will 
continue working on Bugzilla and will keep trying to get the 
configuration files. (On a side note, this is one reason why we 
plan to get all of the services in our ecosystem under one roof 
with access for multiple admins. We're thankful for all of the 
work the volunteers in our community have put into maintaining 
services for us, but we've grown well beyond the point where we 
can live with having a single point of failure for every service 
in the ecosystem.)


Ali reported that he finished his [Programming in 
D](https://ddili.org/ders/d.en/index.html) edits, saying that the 
physical book is updated as well.


Razvan gave us a report on the status of [the leaderboard for the 
Bugzilla rewards](https://bot.dlang.io/contributor_stats. He 
added asterisks next to the names of those ineligible to receive 
rewards, and he also added another page: 
https://bot.dlang.io/contributor_stats shows overall stats, and 
https://bot.dlang.io/contributor_stats_cycle shows the stats for 
the current cycle. He told us he was thinking of theming the page 
based on the DConf logo and colors from 2016/17 in Berlin, and he 
has since done so.

He also brought up the vision document.

In [the discussion thread of our September 2021 meeting 
summary](https://forum.dlang.org/post/yybthlissupxlgsgjupl forum.dlang.org), I
said the following in response to a question about the vision document:


 ...in the process of revising it, I realized it needs a 
 complete rewrite. The document we ended up with isn't what we 
 said we wanted.

 The rewrite will be a high priority for me once I wrap up the 
 DConf Online Q & A videos and get the DIP queue moving again


At the time of the meeting, I was still working on the last DConf 
Online video (the AUA), so I wasn't quite ready to turn my 
attention to it yet. I had intended at some point to propose a 
special meeting to discuss it, but since Razvan brought it up I 
suggested we hold that meeting on February 18. Everyone agreed. 
We did have the meeting, and you'll find a brief summary of it 
below.


Átila had nothing to report.


Mathias brought up [a PR he had submitted to 
dmc](https://github.com/DigitalMars/Compiler/pull/13) a year ago. 
It adds CI. He asked if Walter could provide feedback on it. 
Walter asked him to send him an email with the link, and Mathias 
said he would do so as soon as he rebased the PR.

While putting together this summary, I followed up with Mathias. 
He has now rebased the PR, and I've sent Walter the link.



**ImportC**
Walter told us how he thinks ImportC is going to be a big deal 
for D. He wants to get us "over the hump" with getting it working 
properly. He thinks his C extension to allow importing D files in 
C is working out far better than he expected, and he's 
considering proposing it to the C committee. The biggest 
difficulty with ImportC is compiler extensions that we either 
have to implement or give up on.

Walter asked Iain and Martin if they were going to implement 
ImportC in GDC and LDC.

Iain explained that it will be used when importing a C header 
into a D program, but any C files passed on the command line will 
go through the GCC driver and be handed off to the C compiler. 
Walter asked if GDC could get a command-line flag to bypass the 
driver and pass C files to ImportC instead of GCC, and Iain said 
that's not possible. He and Walter brainstormed ways to do it, 
but Iain said GDC has no control over the `main` function. He 
also noted that GCC is already a good C compiler, so he doesn't 
see a reason to bypass it.

Martin said you can currently import C headers and compile C 
source with ImportC in LDC, but he hasn't yet implemented the two 
new AST nodes that Walter implemented for ImportC in DMD's 
backend (initializer lists and bitfields). He hopes to handle 
those in the glue layer and output errors saying LDC currently 
has limited ImportC support. Implementing bitfields is going to 
take a bit of work.

Walter said he now thinks having the C initializers flowing 
through to the backend in a new AST node was a mistake. He plans 
to change the implementation so that the frontend semantic 
routines translate them into D initializers.

**Bitfields**
Walter then brought up bitfields in D. He had expected it was 
going to be an obvious, uncontroversial feature, and was 
surprised by the resistance to it.

The number one objection he's seen is that it would break the 
reflection API. He noted that bitfields will work with the 
reflection API without breaking anything (callers will get a 
field that is a union of the bitfields, so its address can be 
taken, and it will have a name derived from "bitfields"). We can 
add a traits feature that specifically fetches a bitfield.

Martin said he was satisfied with that solution, but wondered 
what would happen when taking the address of a bitfield. Walter 
said that would fail to compile. Martin feels this hurts the 
elegance of the language just for the sake of a rare case for 
which there has been no big demand and for which we already have 
a library solution ("not great", but it works). This went into a 
long discussion about opportunities for compression of data 
structures (particularly in DMD), whether or not that's 
beneficial for DMD, compatibility with C, library vs. language 
solutions, experience reports (Mathias described how his company 
handled bitfields in bindings not using the library solution), 
improving the library solution so that it's more elegant, the 
bitfield implementation in ImportC, C compiler bitfield layouts, 
and quite a bit more.

**128-bit integers**
Finally, Walter said he has looked at implementing 128-bit 
integers (cent and ucent), but implementing them in DMD would be 
a nightmare. After more thought, he has decided it's probably 
better to implement them as a library type. He mentioned how 
complex numbers were ripped out of the compiler and implemented 
as a library feature. The work that has already been done on 
`cent`/`ucent` will not be wasted, as it can still be built on to 
implement the library type.


Max on a whim began implementing the string interpolation of [the 
DIP under development](https://github.com/John-Colvin/YAIDIP) 
(not yet submitted) by Andrei and John. He asked if it's okay to 
go ahead and finish it up and put it behind a preview switch. 
Walter hadn't seen the DIP yet but noted that he was strongly 
opposed to any complicated string interpolation feature. The 
implementation of string interpolation should be easy to explain 
to anyone. Anything that is complicated to explain just isn't 
going to work. He will need to review the DIP before deciding on 
allowing a preview switch.

I suggested finishing the named arguments implementation should 
be a higher priority right now, and Walter agreed. Walter 
stressed that named arguments need to be interchangeable with 
struct initializers. We'll have to keep struct initializers 
around for backward compatibility, but he wants named arguments 
to replace them generally.



The vision meeting took place on February 18 at 15:00 UTC. The 
following members attended:

Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Mathias Lang
Átila Neves
Razvan Nitu
Vladimir Panteleev
Mike Parker
Robert Schadek

One of the things we were missing from our initial conversations 
about the vision document last year was an overarching Vision 
Statement. This is the elevator pitch that describes where D is 
going. It isn't down at the level of specific details, but far up 
above. It's a broad, general statement about our long-term goals 
for the language. This will sit at the top of the vision 
document. While the rest of the document will change as 
priorities shift and tasks are completed, the vision statement 
should remain fairly constant. The more specific details in the 
rest of the document should all be there because they are sending 
us on the path described by the vision statement.

I asked everyone present to brainstorm. What do you want for D? 
Where are we going with it? If there were an end goal, what would 
it be? No idea, no matter how broad or how specific, was 
off-limits. The more information I have to draw from, the better.

Each person has their own ideas about the specifics of where we 
need to go, but I was confident we could find a consensus at a 
higher level. I'm not going to copy here every item on the list 
or summarize the entire discussion. The meeting lasted over an 
hour and we covered quite a bit of ground. However, many of the 
items fall under broader categories related to the usability of 
the language and the quality of the overall user experience 
(i.e., the ecosystem, Phobos).

I haven't gotten to it yet, but the next step is on me. I'll 
draft three or four different vision statements, then we'll hone 
in on something that makes us happy. Once we have that, I can 
start assembling the details for the rest of the document. My 
current plan is to lay it out in three sections:

**Current Focus**: This describes where Walter and Átila are 
currently directing their attention and what their end goals are. 
It also serves as a guide for volunteer contributors looking to 
fix bugs or make other contributions, e.g., bug categories 
related to Walter and Átila's work, suggestions for how to test 
related language features, ideas for projects that can help reach 
their end goals, etc.

**Future Focus**: This describes possible directions toward which 
Walter and Átila would like to turn their attention in the 
future, also with suggestions for volunteer contributors. Those 
who feel their skills are better applied toward one of these 
areas than those of the current focus can do so knowing that 
their work will move us toward the desired goal.

**Wishlist**: This is a grab bag of ideas ranging from small 
tasks to large projects. Some of them will be things that would 
be nice to have, but that Walter and Átila will never have time 
to work on. Some may be important tasks that don't fit into the 
broader focus categories above, things that either Walter or 
Átila will have to do at some point if no one else does. Some of 
these may be set up as paid contract work.

I can't say with any certainty how long it will take us to get 
all of this together. I know many in the community are eager to 
see it. Speaking for myself, it's not my highest priority at the 
moment. I'm sure that's true for everyone else whose input will 
be required to get to the final version. But I *am* making sure 
it gets done, step-by-step, section-by-section. My loose goal is 
to have it completed before DConf.


I'm quite late putting this summary out, so it's already almost 
time for our next meeting. We're scheduled to hold it on March 4 
at 15:00 UTC. I plan to put forward a proposal about the next 
step in getting our services under one roof with multiple admins. 
If you have an idea or issue you'd like to bring to us at this or 
a future meeting, please contact me at social dlang.org and I'll 
see about getting it on the agenda.
Feb 27 2022
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:

 **128-bit integers**
 Finally, Walter said he has looked at implementing 128-bit 
 integers (cent and ucent), but implementing them in DMD would 
 be a nightmare. After more thought, he has decided it's 
 probably better to implement them as a library type. He 
 mentioned how complex numbers were ripped out of the compiler 
 and implemented as a library feature. The work that has already 
 been done on `cent`/`ucent` will not be wasted, as it can still 
 be built on to implement the library type.


128-bit soft cent/ucent here:
https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d
Feb 27 2022
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:

 **ImportC**
 Walter told us how he thinks ImportC is going to be a big deal 
 for D. He wants to get us "over the hump" with getting it 
 working properly. He thinks his C extension to allow importing 
 D files in C is working out far better than he expected, and 
 he's considering proposing it to the C committee.


The idea that the legendarily-conservative C committee would be 
willing to consider something like `__import` for standardization 
strikes me as...extremely optimistic, to say the least.
Feb 27 2022
prev sibling next sibling parent __StarCanopy <starcanopy protonmail.com> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:

 implementation of string interpolation should be easy to 
 explain to anyone.


I'm a very unimpressive programmer, and I have a reasonable 
understanding of the referenced DIP, so I hope Walter will give 
his blessing.
Leveraging D's strengths such as the DIP does is quite cool, and 
if a user wants something that's similar to the typical 
implementation used by some other languages, then invoking `text` 
with an interpolated string is easy, and it will produce the 
expected result.
Feb 27 2022
prev sibling next sibling parent reply meta <meta gmail.com> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:


 Vladimir opened with a progress report. Back in December, [we 
 discussed migrating our Bugzilla issues to 
 Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwqehz forum.dlang.org). An
alternative solution is to [upgrade to Bugzilla
Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been
contributing to for some time. After that meeting, we agreed that Robert
Schadek would move forward with implementing his migration script, while
Vladimir would get the new Bugzilla instance set up so we can test it out in
the interim.


I was looking forward the Github migration.. I'm not liking the 
constant switch from Github/bugzilla, referencing/looking for 
issues is also a major pain..


LLVM recently migrated fully to Github/Github Issues, that's is 
the way to go in my opinion..

Can't beat the nice integration and ease of access Github 
provides, we need stay fresh to attract new younger souls
Feb 28 2022
parent reply bauss <jj_1337 live.dk> writes:
On Monday, 28 February 2022 at 08:52:37 UTC, meta wrote:

 On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:


 Vladimir opened with a progress report. Back in December, [we 
 discussed migrating our Bugzilla issues to 
 Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwqehz forum.dlang.org). An
alternative solution is to [upgrade to Bugzilla
Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been
contributing to for some time. After that meeting, we agreed that Robert
Schadek would move forward with implementing his migration script, while
Vladimir would get the new Bugzilla instance set up so we can test it out in
the interim.


 I was looking forward the Github migration.. I'm not liking the 
 constant switch from Github/bugzilla, referencing/looking for 
 issues is also a major pain..


 LLVM recently migrated fully to Github/Github Issues, that's is 
 the way to go in my opinion..

 Can't beat the nice integration and ease of access Github 
 provides, we need stay fresh to attract new younger souls


I sort of agree with that. I usually don't bother reporting 
anything because I don't like bugzilla, it would just be much 
more convenient to use Github.
Mar 01 2022
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 1 March 2022 at 08:12:43 UTC, bauss wrote:

 Can't beat the nice integration and ease of access Github 
 provides, we need stay fresh to attract new younger souls


 I sort of agree with that. I usually don't bother reporting 
 anything because I don't like bugzilla, it would just be much 
 more convenient to use Github.


New Bugzilla is much nicer (preview: https://dbugs.k3.1azy.net/), 
but I agree that it's not possible to beat GitHub's integration 
with GitHub (and GitHub does not provide the opportunity for 
better integration either unlike some libre competitors). On the 
other hand with Bugzilla we are fully in control and own our 
data, which allows doing a few things not possible with GitHub. 
This is why we're doing both approaches in parallel (Bugzilla 
work is currently waiting on obtaining the issues.dlang.org 
configuration files).
Mar 03 2022
parent reply Arun <aruncxy gmail.com> writes:
On Thursday, 3 March 2022 at 14:33:54 UTC, Vladimir Panteleev 
wrote:

 On Tuesday, 1 March 2022 at 08:12:43 UTC, bauss wrote:

 [...]


 I sort of agree with that. I usually don't bother reporting 
 anything because I don't like bugzilla, it would just be much 
 more convenient to use Github.


 New Bugzilla is much nicer (preview: 
 https://dbugs.k3.1azy.net/), but I agree that it's not possible 
 to beat GitHub's integration with GitHub (and GitHub does not 
 provide the opportunity for better integration either unlike 
 some libre competitors). On the other hand with Bugzilla we are 
 fully in control and own our data, which allows doing a few 
 things not possible with GitHub. This is why we're doing both 
 approaches in parallel (Bugzilla work is currently waiting on 
 obtaining the issues.dlang.org configuration files).


Just curious if we looked at GitLab as an alternative to both 
GitHub and Bugzilla.
Mar 03 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote:


 Just curious if we looked at GitLab as an alternative to both 
 GitHub and Bugzilla.


We're happy on GitHub and have no plans to move to GitLab.
Mar 03 2022
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 4 March 2022 at 07:10:05 UTC, Mike Parker wrote:

 On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote:


 Just curious if we looked at GitLab as an alternative to both 
 GitHub and Bugzilla.


 We're happy on GitHub and have no plans to move to GitLab.


Quoting Vladimir, "On the other hand with Bugzilla we are fully 
in control and own our data, which allows doing a few things not 
possible with GitHub".

GitLab il free software, available and installable on a private 
server, like Bugzilla, so both the chicken and the eggs.

But I fully understand that a migration to GilHub is just fine 
right now.
Mar 04 2022
prev sibling parent reply Arun <aruncxy gmail.com> writes:
On Friday, 4 March 2022 at 07:10:05 UTC, Mike Parker wrote:

 On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote:


 Just curious if we looked at GitLab as an alternative to both 
 GitHub and Bugzilla.


 We're happy on GitHub and have no plans to move to GitLab.


Sure. You mean, GitHub + Bugzilla?
Mar 04 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 4 March 2022 at 21:44:56 UTC, Arun wrote:

 On Friday, 4 March 2022 at 07:10:05 UTC, Mike Parker wrote:

 On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote:


 Just curious if we looked at GitLab as an alternative to both 
 GitHub and Bugzilla.


 We're happy on GitHub and have no plans to move to GitLab.


 Sure. You mean, GitHub + Bugzilla?


No, I mean GitHub. We're not happy with the our version of 
Bugzilla anymore, which is why we want to either move the issues 
to GitHub or see if the Bugzilla Harmony is good for us. But we 
have no reason to move the D projects away from GitHub to GitLab. 
GitLab has never entered the conversation.
Mar 04 2022
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote:

 But we have no reason to move the D projects away from GitHub 
 to GitLab. GitLab has never entered the conversation.


Two reasons would be that
1) It already offers [an integration with 
bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html).
2) Being open source it can be installed on your own hardware, 
which is the main argument being made for using bugzilla.

It also has integrated CI.

— Bastiaan.
Mar 05 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 5 March 2022 at 12:39:39 UTC, Bastiaan Veelo wrote:

 On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote:

 But we have no reason to move the D projects away from GitHub 
 to GitLab. GitLab has never entered the conversation.


 Two reasons would be that
 1) It already offers [an integration with 
 bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html).
 2) Being open source it can be installed on your own hardware, 
 which is the main argument being made for using bugzilla.

 It also has integrated CI.

 — Bastiaan.



benefit. We're aiming to integrate all of our services. As I see 
it, the less we have to manage ourselves, the better. If we did 
for some reason want to migrate to GitLab, my vote would be to 
let them host us.

But my point was, GitHub has worked well for us for years. 
There's no desire to move away that I'm aware of. If it ain't 
broke, don't fix it!
Mar 05 2022
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote:

 On Saturday, 5 March 2022 at 12:39:39 UTC, Bastiaan Veelo wrote:

 On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote:

 But we have no reason to move the D projects away from GitHub 
 to GitLab. GitLab has never entered the conversation.


 Two reasons would be that
 1) It already offers [an integration with 
 bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html).
 2) Being open source it can be installed on your own hardware, 
 which is the main argument being made for using bugzilla.

 It also has integrated CI.

 — Bastiaan.



 a benefit. We're aiming to integrate all of our services. As I 
 see it, the less we have to manage ourselves, the better. If we 
 did for some reason want to migrate to GitLab, my vote would be 
 to let them host us.

 But my point was, GitHub has worked well for us for years. 
 There's no desire to move away that I'm aware of. If it ain't 
 broke, don't fix it!


Definitely. Personally I think moving the tickets to GitHub is a 
good idea, I just felt these points needed to be made for 
completeness.

— Bastiaan.
Mar 05 2022
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote:

 On Saturday, 5 March 2022 at 12:39:39 UTC, Bastiaan Veelo wrote:

 On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote:

 But we have no reason to move the D projects away from GitHub 
 to GitLab. GitLab has never entered the conversation.


 Two reasons would be that
 1) It already offers [an integration with 
 bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html).
 2) Being open source it can be installed on your own hardware, 
 which is the main argument being made for using bugzilla.

 It also has integrated CI.

 — Bastiaan.



 a benefit. We're aiming to integrate all of our services. As I 
 see it, the less we have to manage ourselves, the better. If we 
 did for some reason want to migrate to GitLab, my vote would be 
 to let them host us.

 But my point was, GitHub has worked well for us for years. 
 There's no desire to move away that I'm aware of. If it ain't 
 broke, don't fix it!


I agree, I personally only use Github, so for me it's preferable 
that D stays on Github.
Mar 05 2022
prev sibling parent reply forkit <forkit gmail.com> writes:
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote:

 But my point was, GitHub has worked well for us for years. 
 There's no desire to move away that I'm aware of. If it ain't 
 broke, don't fix it!


"If it ain't broke, don't fix it!"

Well.. There's 'fixing it' and there's 'improving it'.

They are not the same thing.
Mar 07 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 7 March 2022 at 08:07:11 UTC, forkit wrote:


 "If it ain't broke, don't fix it!"

 Well.. There's 'fixing it' and there's 'improving it'.

 They are not the same thing.


In my opinion, gitlab is not an improvement.
Mar 07 2022
parent reply forkit <forkit gmail.com> writes:
On Monday, 7 March 2022 at 08:47:00 UTC, Mike Parker wrote:

 On Monday, 7 March 2022 at 08:07:11 UTC, forkit wrote:


 "If it ain't broke, don't fix it!"

 Well.. There's 'fixing it' and there's 'improving it'.

 They are not the same thing.


 In my opinion, gitlab is not an improvement.


I agree ;-)

I just wanted to point out, that using 'if it ain't broke, don't 
fix it' is not a useful rebuttal to suggestions for 'improvement'.
Mar 07 2022
parent bauss <jj_1337 live.dk> writes:
On Monday, 7 March 2022 at 09:58:32 UTC, forkit wrote:

 On Monday, 7 March 2022 at 08:47:00 UTC, Mike Parker wrote:

 On Monday, 7 March 2022 at 08:07:11 UTC, forkit wrote:


 "If it ain't broke, don't fix it!"

 Well.. There's 'fixing it' and there's 'improving it'.

 They are not the same thing.


 In my opinion, gitlab is not an improvement.


 I agree ;-)

 I just wanted to point out, that using 'if it ain't broke, 
 don't fix it' is not a useful rebuttal to suggestions for 
 'improvement'.


A lot of things wouldn't have to be added to D if D followed that 
philosophy for everything.
Mar 07 2022
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:




Just letting you know that it is posts like these  that I look 
forward to the most, and I very much appreciate the work that 
goes into them.

Thanks!
— Bastiaan.
Feb 28 2022
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 28 February 2022 at 22:00:09 UTC, Bastiaan Veelo wrote:

 On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:




 Just letting you know that it is posts like these  that I look 
 forward to the most, and I very much appreciate the work that 
 goes into them.

 Thanks!
 — Bastiaan.


Thank you. I'll try to get back on with my original intent to 
publish them a week after the meetings.
Mar 02 2022