tl;dr - I think criterion-plot could be useful to the broader ecosystem if somebody wanted to maintain it, but I don't. If you do, please continue reading.
When I took over maintenance of Criterion.rs I marked criterion-plot as a "private implementation detail" because I didn't want to commit to defining and maintaining a widely-used plotting crate as well as a benchmarking crate. I hoped that a pure-Rust plot-rendering crate would appear and then I could drop criterion-plot and use that instead and save myself the maintenance effort.
Two years later, that hasn't happened. Rust still has no widely-used plot-rendering crate, pure-Rust or otherwise. I think that criterion-plot could be that crate, but I still don't want to maintain it. Indeed, some folks have used it for that already, despite my dire warnings about API instability.
For that reason, I'd like to invite interested people or teams to fork criterion-plot and create a new, actively-maintained and supported crate based on it.
The reason for forking the crate rather than transferring ownership of the existing Crates.io name is mostly just to avoid risk. This way, I can wait and see how the successor crate(s) develop and if community-consensus forms before I switch Criterion.rs over to using it. It also means I can avoid an event-stream incident without actually having to vet the new owner(s).
For those who are unaware, criterion-plot is a crate that provides a rather nice (if somewhat verbose) interface for describing plots (eg. line charts, bar graphs, and so on), generating a gnuplot script and shelling out to gnuplot to turn the script into an image. It's used to generate all of the plots in Criterion.rs' HTML reports.
Hey! I'm new here, also with the Rust language (have professional software engineering experience though). This project seems comprehensible even for me, so I'd be glad to contribute.
I'm glad some folks are interested. I'd recommend forking the Criterion.rs repo and deleting everything but the plot subcrate and license files and similar. From there, you can decide what direction you want to go. I'd suggest documenting the existing API and adding examples, but I'm hoping you folks will have better plans for criterion-plot than I do.
This sounds like something I want to do. I took a quick look at the list of forks on the github repository, but couldn't see any forks by the people in this thread. Therefore have forked it here and removed the non-plot code.
We need to figure out how to best enable collaboration – I suppose as a start we could simply give everyone who wants to help maintain the crate push-permission to the fork. What are your thoughts?
Thanks @alice, I think that repo is a good start! Let's see first whether we can come up with something which is worth to give a new name to.
Let me propose a possible course of action:
Ask the people who expressed interest in the fork (also on reddit), whether it is still the case.
Set up a communications channel for shorter term brainstorming (maybe this or another thread on this site is sufficient)
Let's see the ideas. Probably we can divide the tasks into the following groups:
Code documentation, examples
Internal refactoring
Breaking changes in public interface (obviously this part needs the most justification)
Contributors start implementing the discussed tasks. They open PRs, which the others review. After that we can merge to master.
Thanks @mfep. You said there were interested helpers in reddit threads as well, so we should probably try to collect the full set of interested contributors in one place. I opened an issue here where everyone interested in participation should express their interest.
Unfortunately I am not aware of which reddit thread you are referring to, so it'd be cool if you could message them and tell them to express their interest in the issue.
As for communications channels, I have already started using the issues in the fork to write down a few thoughts.
I believe most communication should probably go in an issue on the fork created for the topic.
Discussion about the general direction of the project could go in this thread or an issue.
We should consider creating a discord channel or similar for less formal communication.
As for ideas, please take a look at the library and post your ideas in an issue! I have already written some stuff regarding categorization of stuff in this issue, and comments would be appreciated.
If you wish to look at the documentation, I recommend cloning the repository and building the documentation locally using cargo test followed by cargo doc, since the images in the documentation are generated by cargo test, and therefore not present in the documentation on docs.rs.
I am creating an organisation for this. It will be easier to manage and for integrations. Will add you there once you do it (and someone suggests a good name for the fork)
The repo now sits here. I have updated a few meta info, will set up travis and the rest things required shortly.
Yes. We generally use gitter for such things. Even though it is buggy, it is often appropriate for small group-repo discussions. Discord channel (or maybe even zulip) is okay but i find it an overkill for such discussions.
I'd prefer a thread on that repo for that. It is easier for others to discover it and contribute. The problem with a forum is that such topics often get buried under new topics being created so an issue is the better option.
Is there a reddit post asking for maintainers? Would benefit us if you can share a link.
Just for the sake of completeness of this thread, let us announce that yesterday ploteria 0.1.0 got published to crates.io. This release features usability improvements on the public interface as well as some refactoring under the hood. See the aforementioned repository for more information.
