-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi iwakeh, cc'ed Tor devs,
now that we're down to 0 defect tickets in the Onionoo component (not counting that one ticket in needs_review that I hope to resolve before the weekend), ... time for a little applause... I went through the 20 open Onionoo enhancement tickets in an attempt to categorize and prioritize them. Mind going through the list below and commenting on summaries and priorities? And is there a ticket that you'd want to work on? Here's the list, where (--) means low priority and (++) means high priority: === Functional enhancements, user-facing features === #9778 Adding votes documents to Onionoo (-) Processing votes and adding a new document type are major enhancements. The result might turn out to be really useful, but this takes quite some effort. Not super urgent, I'd say. #11041 Add new document type with monthly relay and bridge statistics to Onionoo (-) This is a major feature, and I didn't hear back from the people who originally suggested it. I'd say put on hold until somebody really wants this. #11430 Add new field last_running for "seen in a network status with the Running flag" in addition to last_seen for "seen in a network status" (-) Not many people will care about this distinction, though it's technically a good thing to make it. #11432 Start a bridge's uptime history when it was first listed in a status Similar to #11430, not many people will care about this. But it's still a good idea. #13137 Historical data (+) Without reading the whole ticket, this sounds worthwhile, though time-consuming. #13424 Add new `descriptor` parameter that returns relays or bridges by digest of recently published descriptors This feature would only be used by a very small subset of people, though those people help debug the Tor network. Maybe this isn't terribly difficult to implement. #13425 Add new document type `debug` that includes digests of recently published descriptors and statuses they're referenced from (--) Unclear if people would actually use this. Lowest priority. #14879 add platform search support to onionoo (+) Useful feature, but we should first think about related features and whether we should add them at the same time. === Refactorings, documentation, non-functional enhancements === #11573 Ponder using a database for Onionoo rather than keeping indexes in memory and contents on disk (--) I don't see the clear advantage of switching to a database. There's the risk that it will not perform (much) better or even worse than the file system based design. In any case, we can easily spend lots and lots of hours on this, and even if we're successful, there's no/hardly any visible change to users. Lowest priority. #12944 onionoo protocol/client api and base implementaion (-) I'm unclear what the benefit will be. And unfortunately, patches have aged quite a bit by now. #13003 Figure out a better strategy to avoid concurrent Onionoo executions (+) Unclear what's left to do here, but the summary sounds reasonable. #13080 Add Ant tasks for measuring coverage, dependencies, etc. (++) Without reading the ticket body, this would be great to have. #13088 Versioning and Releases (++) Sounds like a great thing to do, but I need help with this. #13334 improve DetailsDocument (-) Subticket to #12944, same priority. #13362 Make Onionoo's logs more useful (-) Unclear what's left to do, though making logs more useful sounds good. Depending on how much time we can sink into this, though. #13561 logging documentation (-) Seems useful, but if we start documentation logging configuration, we'll soon write much more documentation. This can of course be useful. But it's a huge time sink. #13562 additional logging for backend and frontend components (-) Better log statements would be great, but see the concerns about related tickets. #13600 Improve bulk imports of descriptor archives (+) We're in a good position to complete this ticket. And while it only affects very few people (Onionoo operators), it's worthwhile. #13616 define jmeter testcase(s) ant ant task(s) (+) Sounds useful to have some baseline data and then see how performance changes as new features are added. #14201 Configure out/ directory path somewhere else than in web.xml. (+) Sounds trivially useful. And here's the Trac query that this list is based on: https://trac.torproject.org/projects/tor/query?status=!closed&status=!needs_review&type=enhancement&component=Onionoo&col=id&col=summary&order=id By the way, thanks for all your hard work by submitting and reviewing Onionoo patches! Many people use your work every day without even knowing it. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJU7ebnAAoJEJd5OEYhk8hIUOYH/3AP2iu8hnCYtbcDOSkzqbDT rSe/S5MewtrRlD4cnZID/TqGXGZLJofWbd4Ly4SOg0QpoT8uq47k/vmbeeOBXSqx O3Qxu/e7L9z8/NJeuym3nwTAcFnIQv7K1JkqvPSyB8wrMFhJe+mll+UHS38f5C4z dKdCLs5gsmGJljqbr17tMr2y0hm38u1ID8lzlqmU3H/vI+5dvKK7DPfdsRNLbvmc tA5ATufehYya3xbHJPy8K9W0P706n3Dg4qHBrZ2AnxB4mmX/k3x842WJhnIYapyI kPiM2i2RVdumZA91kHUEu2dYMY0P3OzJK3K9cn9eNFtxMhnMmI1zttkOsIg7mWw= =ZHaC -----END PGP SIGNATURE----- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
