Planning Update June 23 & 30 -- Bugzilla to GitHub; Deprecations

[FeepingCreature]

On Tuesday, 4 July 2023 at 11:08:02 UTC, Mike Parker wrote:
> I'm able to report on a couple of decisions that we reached 
> over the past two planning meetings.
>
> ### Bugzilla to GitHub migration
>
> The update on this is likely to result in quite a bit of 
> discussion, so I've [put it in a separate 
> thread](https://forum.dlang.org/post/kttzxwbbvdpzxlmoyvyo@forum.dlang.org).
>
> ### Deprecation policy
>
> Deprecating `alias this` in classes was a mistake. Walter 
> proposed that we revert it, and everyone got on board.
>
> We also agreed with Walter's proposal to review other recent 
> deprecations to determine if they were inappropriate or have 
> caused unintended problems and, if so, examine if they can be 
> reverted without causing new problems.
>
> Going forward, we're going to take a much more conservative 
> stance on deprecations:
>
> * nothing should be deprecated unless there's a very compelling 
> reason ("this feature was a mistake and people shouldn't be 
> using it" is not a compelling reason)

I mean, only a slight step beyond that is "this feature is the 
cause of people creating bugs." What *is* a compelling reason?

For instance, I got `alias Nullable.get this` deprecated and 
later removed. I'm extremely glad that source of bugs is gone and 
would be upset if it was reverted.

What about things that are straight up bugs that contradict the 
spec? For instance, you used to be able to access a private 
function if it was overloaded with a public function that came 
after. Should we write *that* in the spec? Or should we just 
silently do the wrong thing?

(I don't agree with this policy, you can probably tell. :P)

> * every deprecation should have a clear path for migration, 
> automated if possible
> * the person implementing a deprecation will be responsible for 
> updating projects that trigger it in our BuildKite tests

Apropos, how do I get projects in the Buildkite suite?