search

dlang / project-ideas

Collection of impactful projects in the D ecosystem
36 stars 12 forks source link

Find a way forward for std.experimental #40

Open burner opened 5 years ago

burner commented 5 years ago

Description

The packages in std.experimental are stuck in some limbo state. We need to find a way forward for them. And make sure not to end up in the same situation again.

What are rough milestones of this project?

How does this project help the D community?

It will reduce uncertainty about phobos

Recommended skills

grit

Point of Contact

the authers of the packages in experimental

References

wilzbach commented 5 years ago

FYI a while ago I created the dlang-stdx GitHub organization: https://github.com/dlang-stdx

It even comes with the official design:

https://dlang-stdx.github.io/collections/

We should probably just move all current experimental packages into this organization. Another good example is the stdx-allocator which I extracted from std.experimental:

https://code.dlang.org/packages/stdx-allocator

It's heavily used these days because people want to be able to uggrade when they have time, not when a new language version is released. However, I should point out that stdx-allocator took an interesting path as the community wanted it to be able to work with -betterC, so the stdx-allocator dub package diverged a bit from std.experimental.allocator (also it doesn't contain any of the newer additions to std.experimental.allocator since 2.072 as these were API breaking).

More about this controversy: https://github.com/dlang-community/stdx-allocator/pull/16

Geod24 commented 5 years ago

@wilzbach : That's a great idea, and I'm all for a central Github organization - but what package qualify for inclusion ? Is it based on popularity ? Maintenance criteria ? Other ?

wilzbach commented 5 years ago

I honestly have no detailed idea. I created the repository because Andrei's students were "hacking in the dark" and there was no easy nor central way to see what they were doing.

However, as I have a bit of experience with dlang-community, my idea would be to make very relaxed constraints in joining initially and maybe yearly purge projects that haven't progressed, have no activity and have no plans for the future. This means that the initial author would be admin of his project and is free to hand out merge rights as he sees fit. We could use this repository or a meta repository over at dlang-stdx where people can propose projects for inclusion. Except for a few tasks that can and should be automated there isn't a huge overhead in having more repositories in this repository.

An alternative would be judge community interest more seriously via e.g. voting, but that's always harder and potentially unfair.

Geod24 commented 5 years ago

👍 for relaxed criteria for inclusion.

What I'd very much like to see is an assured compiler support for those project. E.g. projects under the dlang-stdx umbrella will always compile with the latest 5 DMDs, 2 LDCs, 2 GDCs, etc... Numbers subject to change ofc. Having some guideline for setup (mandatory Jenkins and presence in the Buildkite build) should make auto-update trivial.

A few other rules (e.g. no top-level module, a predictable package system, some dub requirement, guaranteed SemVer), gradually applied / tried, would go a long way.

wilzbach commented 5 years ago

Yeah, maybe we should use the dlang-stdx collection repository and make a template out of it, s.t. more projects can be added with the same style.

I added a few more points and created a meta repository for the dlang-stdx organization:

https://github.com/dlang-stdx/meta

Feedback on these guidelines is very welcome! (probably best to use the issue tracker over there: https://github.com/dlang-stdx/meta/issues)

Thanks!