DLF September 2023 Planning Update

Mike Parker aldacron at gmail.com
Tue Nov 14 08:18:20 UTC 2023


In September 2023, we had one planning session. The major item on 
the agenda was editions. Other items were a new meeting format, 
the Bugzilla to GitHub migration, and the future of D.

## Attendees
The following people attended the session.

* Walter Bright
* Ali Çehreli
* Martin Kinkelin
* Dennis Korpel
* Átila Neves
* Razvan Nitu
* Mike Parker
* Robert Schadek

## Editions
We had agreed in [the September monthly 
meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywmyzc@forum.dlang.org) the week before that we need to define what editions will look like before we start deciding which features should go in any given edition. My goal with this session was to establish the first point on the timeline: a deadline for the editions proposal. I also thought it would be a good opportunity for all of us to clarify what editions are (there were some different ideas about that) and discuss aspects of the concept we need to consider.

Here are some points that came out of the discussion.

* Editions are essentially feature sets. Each edition can 
add/remove/deprecate features.
* Editions are entirely opt-in and only affect the source you 
explicitly apply them to, i.e., they are not transitive to 
dependencies.
* Editions will most likely be implemented via an attribute on 
the module declaration. We haven't discussed any details about 
that, but for now, just imagine something like `@edition(2024) 
module foo;`.
* Features cannot be opted into individually. When you apply an 
edition to a module, you get the whole thing.
* The default edition, meaning the code you have now, should 
compile forever.
* We should have a tool that automates as much as possible the 
migration of modules to new editions
* DMD-as-a-library is a critical component for that tool and 
other tools in the ecosystem. We need to put a priority on 
working out all the implementation issues Razvan has raised.
* Given that much of the D community uses code-d, we need to 
bring Jan Jurzitza into any discussions about DMD-as-a-library.

Átila took on the job of writing the proposal and we set November 
1st as the deadline. We've since moved it to mid-December.

One thing I'm looking forward to: editions will provide us with a 
framework to clearly define a roadmap for the language and the 
library.

## Workgroup sessions
Our monthly and quarterly meetings have no fixed agendas. These 
are opportunities for each participant to report what they're 
working on and raise issues they'd like to see resolved. Our 
planning sessions are shorter, more focused meetings in which we 
resolve or decide how to proceed with a specific set of agenda 
items. I proposed we start having what I called "workgroup 
sessions", meetings aimed at hammering out details on bigger 
problems that can't be resolved in one meeting or by one person.

DMD-as-a-library was a good example. This project had been in the 
works in one form or another for years. Razvan has been making an 
effort to get it to the finish line, but there were some critical 
issues to resolve in terms of interface and implementation. It 
took a large chunk of time in our September monthly meeting and 
external conversations with no resolution. Complex issues like 
this need a group of stakeholders focused on hammering out the 
details.

We agreed I should set up a meeting. I noted who was interested 
in participating and took suggestions for other invitations.

We ended up having two DMD-as-a-library meetings in October. I 
didn't participate, but I'll post an update on the outcome.

## Bugzilla to GitHub migration
I've already written about this as an update note in the 
September monthly meeting summary, but this was the session where 
we agreed that Robert should be running the migration script 
instead of me. He just needed admin access to our GitHub 
repositories, and there were no objections to granting it. We 
agreed with Robert's proposal to migrate the VisualD issues 
first, then each project in order from lowest to highest issue 
count.

I'll have more on this in upcoming summaries and updates.

## The future of D
Robert had been itching to talk about our long-term plans for D. 
I think most of us understood that he was talking in terms of 
language features, but in this session, he explained that's not 
what he meant. D started as a successor to C and C++, but he 
doesn't see the language that way. He sees it as the best parts 
of C, Haskell, and Python. Others may see it differently. So how 
do we define the language going forward? What role do we want it 
to play? Are we mostly concerned with C-style stuff where every 
bit counts? Do we see D as a great tool for one-off scripts that 
would normally be written in something like Python?

This prompted Walter to introduce the first draft of his 
Didactica, a list of the principles behind the language. That's 
the kind of thing Robert was looking for. Everyone looked them 
over and provided feedback.

As I noted in the September monthly meeting summary, Walter has 
since gone through multiple drafts of this list. Though he 
originally saw it as a set of principles behind the language, 
he's now come to see it more as the principles behind the DLF, 
guiding not just the development of the language, but also the 
ecosystem, community resources, and so on.

Once it's finalized, this list and the DLF's IVY statement should 
together serve as an aspirational filter for evolving the 
language, the ecosystem, and the community. Does a proposed 
language feature align? Is a current feature not in alignment? 
Are we falling short of our principles in any specific area?

## Wrapping up

We ended with a non-agenda discussion on expanding BuildKite to 
test more code.dlang.org packages to further reduce breakage with 
new compiler releases. The current list is manually curated. 
Átila has a script that determines which code.dlang.org projects 
currently build, and that results in a bigger list. The only 
actionable item that came out of this is that Robert will write a 
script to work out the dependency graph from that list in the 
hope it can be used to minimize the time taken to run the tests 
and reduce resource usage.



More information about the Digitalmars-d-announce mailing list