[tor-dev] Proposing sbws changes

[teor]

Hi,

We've talked about sbws a bit over the last few days.

I'm going to quote some things I wrote in a private email, with some
minor edits. (I would quote the whole thread, but I don't have
permission.)

We also discussed sbws in our team meeting today. Because we are in
lots of different timezones, only some people were there. I'll try
to summarise the meeting discussion as well.

Juga wrote some questions in the team meeting pad. I'll try to answer
their questions here.

>> On 22 Apr 2019, at 14:54, teor <teor at riseup.net> wrote:
>> 
>> We finished our first working version of sbws in March, and deployed
>> it to a directory authority. We're now working on deploying it to a
>> few more directory authorities:
>> https://trac.torproject.org/projects/tor/ticket/29290
>> 
>> We're also working on archiving and analysing the bandwidth files
>> produced by sbws and Torflow:
>> https://trac.torproject.org/projects/tor/ticket/21378
>> 
>> During this work, we've discovered some missing sbws features:
>> https://trac.torproject.org/projects/tor/ticket/30255
>> 
>> We need a better process for proposing and reviewing sbws changes.
>> 
>> At the moment, I am spending a lot of time reviewing and designing
>> sbws changes. And that's not sustainable. We need a process that works
>> when I go on leave, or get busy with other tasks.


> I wrote, privately:
> 
> Our problem is that we keep making lots of changes to sbws. But we don't
> have anyone managing those changes. That makes them high risk.
> 
> We need to assign another paid staff member to do some design and planning
> work on sbws.

> 
> We need to slow down the change process, so sbws becomes stable software.


In the team meeting, we agreed to block sbws merges until I get back from
leave at the end of May. We can make exceptions for critical bug fixes.

In general, we also need to slow down changes to sbws, to manage our
team's workload. sbws is not funded right now, so we need to spend less
time on it.


>> I suggest that we use the tor proposals process:
>> https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt
>> 
>> We can submit small changes as diffs to the bandwidth file spec:
>> https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt
>> 
>> But large changes, controversial changes, and changes with multiple
>> competing options should have their own proposal. Then, once we decide
>> what to do, we can integrate those changes into the spec.


> Our priority for sbws is maintaining stable software. That's more important
> than writing and merging features quickly.
> 
> We need to talk about sbws changes on tor-dev, so that other people
> can get involved. We can't expect people to watch all the sbws tickets.
> 
> If we keep doing high-risk changes with no feedback, then we will never
> be able to deploy sbws on more than 2 directory authorities.


Juga wrote on the network-team meeting pad:

> - Question 1: teor or network-team: which on do you think has higher
>               priority, #29710 or #30255?
> 
> - Question 2: teor or network-team: longclaw's sbws 1.1.0 has been
>               running for more than 1 week, do we want to start
>               running sbws 1.1.0 on basted or should #29710 and/or
>               #30255 be solved first?


For #29710 sbws reports 6200 relays, 1000 fewer than Torflow's 7200

We should deploy sbws 1.1.0 to bastet. Then wait 5-10 days for the
measurements to be stable.

Comparing longclaw and bastet will help us diagnose #29710:
* Does bastet also report 1000 fewer relays than Torflow?
* Do bastet and longclaw exclude the same relays?
* What else do the results tell us?

We can write and test changes for #29710, and I will review them at
the end of May. (These changes are high risk.)


For #30255 Add additional bandwidth file headers in sbws 1.2

We can add extra headers to sbws. Anyone can review them. But I'd
like to double-check the design before we merge. (These changes are
low risk.)

We talked about how to structure these pull requests on the ticket.
We wanted the changes to be easy to review and merge.
But my advice was not the best advice.

Here is some better advice:

Put the commits in one pull request, in this order:
1. We want to be able to add each header using 1-2 lines of code.
   So we need to refactor the header code. Add commits for this
   refactor.
2. Add one new header in each commit. If a group of headers makes
   more sense together, put their commits next to each other.



We will do sbws reviews as a low priority, so we can manage team
workload. That means that it might take us a few weeks to review them.

But please test them while you are waiting for a review.

I hope that helps!

T

--
teor
----------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190424/9e19cdcc/attachment.sig>