[metrics-team] Atlas 1.0 Plan

Karsten Loesing karsten at torproject.org
Thu May 4 09:35:18 UTC 2017


On 03.05.17 23:34, Iain R. Learmonth wrote:
> Hi,

Hi Iain,

I'll comment on these ideas below, because I don't expect much
discussion of this topic at today's team meeting where neither you nor
iwakeh will be around.

> Atlas is not just a software as a service solution. The codebase runs
> straight out the git repository and I do this regularly for testing and
> reviewing of patches.
> 
> To organise the roadmap for Atlas, and have some tangible target, I propose
> that Atlas has "releases". These are going to be pretty informal and will
> probably take the form of a signed git commit.

Sounds great!  You might be able to re-use at least parts of the release
process we have for Java-based metrics code, which includes keeping a
change log file, uploading release tarballs to dist.tp.o, and announcing
releases on tor-dev at .

> I also intend, once this point is reached, to make a release of an Atlas
> Debian package so that you may run a local Atlas instance easily with
> managed stable updates (of course, this will still query Onionoo).

If you mean a package on deb.tp.o, I'd say go for it.

But if you mean including an official Atlas package in Debian, let's
maybe first discuss what this means.  What if we remove functionality
from Onionoo that Atlas depends on, giving Onionoo clients the usual 1
or 2 months to update?  Would we have to maintain a packaged Atlas for
years?  Would that even be possible without Onionoo being packaged, too?
 (And I don't think we're ready to package Onionoo at this point.)

> tor#14940 is going to be very useful for the Debian package in ensuring that
> we have reasonable licenses for all the code used by Atlas.

Makes sense to make sure that all code in Atlas has reasonable licenses,
even regardless of the packaging question.  What we do for Java-based
metrics code is that we only rely on libraries packaged in Debian stable
(at least for runtime; we do make exceptions for measuring code coverage
and checking code style during buildtime).

> I've added these items to the agenda to raise awareness of these intentions,
> but I'm not going to be present as I've got a scheduling conflict. If they
> are discussed, it would be cool if someone could add notes to the pad or
> follow up on this email.

Or let's keep the discussion here and put it on the agenda when you're
around.  It will make more sense.

> Thanks,
> Iain.

Thank you!

All the best,
Karsten


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20170504/b401bead/attachment.sig>


More information about the metrics-team mailing list