Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting chrono #16

Open
KodrAus opened this issue Apr 8, 2018 · 2 comments
Open

Supporting chrono #16

KodrAus opened this issue Apr 8, 2018 · 2 comments
Labels
crate Related to a library as opposed to a resource tracking issue

Comments

@KodrAus
Copy link
Collaborator

KodrAus commented Apr 8, 2018

chrono is one of the top 100 most depended on crates, and the most popular datetime library for Rust. It needs more support to revamp the API, answer open design questions and work towards a stable release.

@quodlibetor How could we best support chrono? I've got a few notes I thought I'd just drop in to get the ball rolling. A lot of this might've already crossed your mind!

There are some simple things we could put in place in preparation for more maintainers coming on board, like setting up a dedicated gitter channel, and maybe bors.

Would you like some more input from the community on where current deficiencies are and what a stable chrono should look like? Would you prefer to cover the design space yourself more before looking for input? I think the RFCs repo you set up is great 👍

A library evaluation using the API Guidelines as a checklist might not be very useful right now if the API is going to change a lot, but having that place for active and unstructured design discussion could be really worthwhile at just about any stage of your revitalisation effort.

It looks like we've got some idea of where chrono is now and where chrono should end up which should be really helpful for framing an evaluation/design thread (whatever shape that would end up taking). Perhaps we could flesh that out into some concrete RFC with a rough roadmap first?

Does anyone have any other thoughts?

I'm really excited to see chrono get some dedicated maintainership again! Thanks @quodlibetor for taking it on!

@KodrAus KodrAus changed the title Supporting chrono Supporting chrono Apr 8, 2018
@KodrAus KodrAus added the crate Related to a library as opposed to a resource label Apr 9, 2018
@Enet4
Copy link

Enet4 commented Apr 11, 2018

So, I have read @quodlibetor's notes, but I'm not quite sure where technical discussions should take place at the moment. Should there also be a tracking issue at the chrono repository? Or perhaps the new RFC repository? I'm a bit confused about what belongs in which repository, since according to the latter, we are invited to "open tickets / PRs, no matter how minor". I suppose that only major suggestions to the crate would require an RFC, right? :)

I agree that a gitter channel would be useful, as it often leads to a faster exchange of ideas without making issues too noisy.

@quodlibetor
Copy link

For long term planning or just brainstorming I think I would prefer putting that in the RFCs repo. And yes you should feel free to open any tickets you want in there.

I'll create a gitter channel as well. I'm imagining treating the RFCs repo as sort of a forum, for now, to work around the lack of better channels. I'm open to ideas for better channels -- I'm concerned that creating a tag for chrono in urlo would be too noisy for people there, but I would welcome the extra input if people think that would be reasonable. I'm also open to other ideas.

I purposefully left my planned solutions out of my notes document so that people would feel free to propose their own, without thinking that the plan is figured out. So: any kind of brainstorming ticket would be fine there. I would prefer to keep chrono itself focused on current issues: bugs, PRs, support, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crate Related to a library as opposed to a resource tracking issue
Projects
None yet
Development

No branches or pull requests

3 participants