Maintainership, Archive, or Something Else?

[kanielrkirby]

The goal here is to talk about some concerns, compile the recent developments, and to ask a question to @chmln.

I'd love to help contribute to this project a bit. It's a nice way to get more hands-on experience with Rust, and support such an awesome project. It seems, though, that maintainership has moved into a grey area since 2024 started (#290, #297, #238), even though people are still using sd and contributing (#292, #193, #296) to it.

@CosmicHorrorDev has recently stepped down (#290) from maintaining the project, with @nc7s also making it known that they won't be able to maintain either. I don't know your relationship (if any) with the other contributors, but it's worthwhile to mention that @dev-ardi has offered to try maintaining, at least a little.

To be clear, it totally makes sense if there aren't any contributors you feel comfortable passing maintainership to. I think what I personally am looking for is a more concrete answer. So, all of that lead-up to ask 1 of 3 things:

a) Do you think there is anyone else that you'd be willing to grant the ability to maintain sd, or
b) Is the project better off being archived to let users know it is not planned to be maintained, or
c) Do you think the project is in a good place as of now, and doesn't warrant archiving or new maintainers, for whatever reason that might be?

From a concerned user and developer. I wish all of you the best, and appreciate all the work that's gone into this project.

[chmln]

Hi guys, more than happy to grant maintainer rights to those interested especially if they have any experience with maintaining Rust crates / codebases. I will reread these threads and reach out to those interested

[kanielrkirby]

Awesome! Really happy to hear that.

[danie-dejager]

I'm not sure how much of a fork https://github.com/ms-jpq/sad/ is, but it is maintained and seem to have been inspired by sd. Should users either migrate to that package or will it be possible to at least check that sd builds with relative current dependencies with a lock on new features?

[danie-dejager]

Currenty sd is building with rust 1.80. Can't see any glaring issues.
Here is a current list:
aho-corasick v1.1.2 - v1.1.3
ansi_term v0.12.1 - v0.12.1
anstream v0.6.4 - v0.6.15
anstyle-parse v0.2.2 - v0.2.5
anstyle-query v1.0.0 - v1.1.1
anstyle v1.0.4 - v1.0.8
autocfg v1.1.0 - v1.3.0
bitflags v2.4.1 - v2.6.0
cfg-if v1.0.0 - v1.0.0
clap_builder v4.4.6 - v4.5.13
clap_derive v4.4.2 - v4.5.13
clap_lex v0.5.1 - v0.7.2
clap v4.4.6 - v4.5.13
colorchoice v1.0.0 - v1.0.2
crossbeam-deque v0.8.3 - v0.8.5
crossbeam-epoch v0.9.15 - v0.9.18
crossbeam-utils v0.8.16 - v0.8.20
errno v0.3.5 - v0.3.9
fastrand v2.0.1 - v2.1.0
heck v0.4.1 - v0.5.0
is-terminal v0.4.9 - v0.4.12
libc v0.2.149 - v0.2.155
linux-raw-sys v0.4.10 - v0.6.4
memchr v2.6.4 - v2.7.4
memmap2 v0.9.0 - v0.9.4
memoffset v0.9.0 - v0.9.1
proc-macro2 v1.0.69 - v1.0.86
quote v1.0.33 - v1.0.36
rayon-core v1.12.0 - v1.12.1
rayon v1.8.0 - v1.10.0
regex-automata v0.4.3 - v0.4.7
regex-syntax v0.8.2 - v0.8.4
regex v1.10.2 - v1.10.6
rustix v0.38.20 - v0.38.34
scopeguard v1.2.0 - v1.2.0
strsim v0.10.0 - v0.11.1
syn v2.0.38 - v2.0.72
tempfile v3.8.0 - v3.11.0
terminal_size v0.3.0 - v0.3.0
thiserror-impl v1.0.50 - v1.0.63
thiserror v1.0.50 - v1.0.63
unescape v0.1.0 - v0.1.0
unicode-ident v1.0.12 -v1.0.12
utf8parse v0.2.1 - v0.2.2