[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-dev] Priorities for Onionoo development

-----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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev