[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] (FWD) [network-team] Hand-off notes for Nick's vacation
Forwarding with permission from Nick, since he sent it to only a sekrit
list, and it should go to a public list.
Onward and upward,
--Roger
----- Forwarded message from Nick Mathewson <nickm@xxxxxxxxxxxxxx> -----
Date: Fri, 14 Aug 2020 13:52:02 -0400
From: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
To: network-team <network-team@xxxxxxxxxxxxxxxxxxxx>
Subject: [network-team] Hand-off notes for Nick's vacation
Hi!
You can also read this at
https://gitlab.torproject.org/nickm/notes/-/wikis/Vacation2020 -- it
is a list of stuff I thought might be helpful or important to think
about while I'm away.
This is me signing off for the next while. As documented in the
calendar, I'll be back on 14 September. If you need to contact me in
the meanwhile, please use Signal or personal email. I'll be routing
all mailing lists to a "Post-Vacation" folder.
I'm going to use this email to checkpoint a few things before I go
off, so it'll be easier to pick them up. I've asked George to help me
write it.
I've sorted this list in order of decreasing priority.
# 0.4.4
We are planning to release a stable 0.4.4 release on 15 September.
That's the day after I get back. I just put out an 0.4.4.4-rc release
on 13 August.
There are still some 044-must/044-should issues that
I think we have several possible choices here:
* If there are no further risky changes in 0.4.4 between now and 15
September, we can just release 0.4.4 stable on that date.
* If we want to do futher risky changes between now and 15
September, it would probably be okay to plan for another release
candidate on 1 September. That would let me put out a stable when I
get back.
* If you don't do a release candidate between now and when I get
back, but there _are_ risky changes, then we should put out a release
candidate when I'm back, and we can plan to put out the stable 2-3
weeks after that.
I have updated the ReleasingTor.md documentation in the master branch
to reflect current practice.
There is a ticket at
https://gitlab.torproject.org/tpo/core/team/-/issues/11 to track
things we need to do for the release. Please make sure that the
"must" and "should" tickets get triaged and handled (or not handled)
as appropriate.
# Caitlin's internship
Caitlin has been working on
https://gitlab.torproject.org/tpo/core/tor/-/issues/40066 ??? there is a
patch with a merge request. Please make sure to give them all the help
they need, and answer their questions promptly and usefully: if I
understand correctly, their internship ends at the end of month.
# Sponsor 55
Sponsor 55 will come to an end over the weekend. For a list of what
we've done, have a look at
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Sponsor55Report
. I sent a copy of this pad to gaba and david under the heading
"sponsor 55 - what was worked on (so we can start having stuff
together for the report)".
There are remaining tickets labeled with "sponsor 55". I believe that
none of them are must-do items for the sponsor. But some of them are
things we need to do before we can release 0.4.5, and some of them are
things that we should do while the code is still fresh in our heads.
I will try to sort these out as much as I can before I go, but there
may be remaining tickets for you to sort.
https://gitlab.torproject.org/tpo/core/team/-/issues/12 is the
tracking ticket for removing the S55 label from the remaining tickets.
# Gitlab best practices
IMPORTANT: Make sure you are seeing new tickets in tpo/core/tor that
do not mention you specifically. This may not be the default. You
can do this either by looking at the complete list of tickets every
day or two, then skipping to the end... or by updating the settings in
"User settings > notifications" at
https://gitlab.torproject.org/profile/notifications .
When somebody submits a patch but not a merge request, please ask them
to do a merge request if they can, and open one for them if they
can't.
If a volunteer has been sitting on a needs_revision patch for a long
time, consider asking them for permission to take it over and fix it
up.
# 0.4.5 best practices
Please remember how to handle tickets that are possibly backportable.
When making a Merge Request:
1. Make the branch against the target maint-0.x.y branch.
2. Make your merge request against the target maint-0.x.y branch.
3. Note that the MR is backportable in your MR message.
When merging, if it is even _possible_ we want to backport more:
1. Give the MR the "Backport" label.
2. Un-assign yourself from the MR: you don't need to review it any more.
3. Put the MR into the latest milestone to which it has not been backported.
# Tickets and MRs assigned to Nick
There are a bunch of tickets still assigned to me. Please feel to
take any of them over that you want. I'm going to go through them and
unasssign any that I think should be handled before I'm back, with
notes.
If you review an MR that I wrote and it needs changes, please consider
making those changes yourself or getting somebody else to do so, if
you feel that you can. I won't mind, and it's probably better if this
code doesn't rot for a whole month.
# CI
We now have CI running on gitlab, with debian-stable. It covers (I
believe) hardened builds, gcc, clang, stem, chutney, distcheck, and
documentation. It's implemented in .gitlab.yml and in scripts/ci/ .
Feel free to hack on it, but make sure to make any changes to
maint-0.3.5 and merge them forward from there: it was really
unpleasant to have our appveyor and travis files diverge among
versions.
There are more changes to make, and please feel free to move ahead
with this stuff: I've tried to update stuff on trac as we go.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40048 is the
ticket for moving to gitlab CI.
Also please remember that super-slow CI is not our friend. You can
make hardened builds run much faster by merging tpo/core/tor#40088,
once you trust it. :)
# 0.4.5 planning
Please feel free to make progress on planning and coding stuff for
045, but keep im mind that technical debt and leftovers from 044 would
also be very smart things to work on.
The ticket where our discussions have been happening is:
https://gitlab.torproject.org/tpo/core/team/-/issues/7
# TROVE-2020-005
We have an open low-severity issue tracked as tpo/core/tor#40080
(private) and tpo/core/tor#40086 (public). More thought there would
always be valuable. If it is indeed low-severity, the it's okay to
merge it in 044 if you like it and are confident in it. But please be
careful: the code is subtle.
# Tor ticket triage
I closed our original ticket triage activity, and opened a new one:
https://gitlab.torproject.org/tpo/core/team/-/issues/10
Feel free to do as much or as little here as you think good, and/or to
come up with different ideas.
# Blog post comments
We're supposed to moderate comments on all our blog posts, and I just
put out a release (0.4.4.4-rc) on 13 August. Please keep an eye on
the comments there and approve the ones that are on-topic.
# Defer till later: rename 'master', autostyle the code.
We're planning to rename "master" to "main", and to get clang-format
running happily on our code. Both of these are deferred till I get
back in September.
----- End forwarded message -----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev