Hi, all!
Here's an idea I had for directory authorities and the 0.2.3 release series.
"As you know Bob," Tor 0.2.3 will be stable very soon, and I'm hoping not to take any more patches for it except for important security issues. I want 0.2.4 to come out very early next year. But in the meantime, to support 0.2.4, and to deploy security/reliability features to the network early, there are some directory consensus features that we'd want to deploy before the rest of 0.2.4 is done and stable.
In particular, I'd like directories to be able to reach consensus on IPv6 addresses (6363), and I'd like to try out the code that Mike wrote to make the bandwidth voting system more robust against dishonest during its startup phase (2286).
So here's my plan: Make a "maint-0.2.3-da" branch based on 0.2.3, plus feature patches for directory authorities. It gets patches from the stable series (0.2.3), plus directory-authority features under development. It would get merged-forward into 0.2.4, to make sure that 0.2.3-da and 0.2.4 behavior stay in sync.
This way we can get new authority features working in time to support 0.2.4 clients, but without forcing too many authorities to run 0.2.4 before it's ready, and without forcing us to make feature changes in 0.2.3 proper.
Thoughts?
yrs,
On Fri, Aug 31, 2012 at 11:57:04AM -0400, Nick Mathewson wrote:
Hi, all!
Here's an idea I had for directory authorities and the 0.2.3 release series.
"As you know Bob," Tor 0.2.3 will be stable very soon, and I'm hoping not to take any more patches for it except for important security issues. I want 0.2.4 to come out very early next year. But in the meantime, to support 0.2.4, and to deploy security/reliability features to the network early, there are some directory consensus features that we'd want to deploy before the rest of 0.2.4 is done and stable.
In particular, I'd like directories to be able to reach consensus on IPv6 addresses (6363), and I'd like to try out the code that Mike wrote to make the bandwidth voting system more robust against dishonest during its startup phase (2286).
So here's my plan: Make a "maint-0.2.3-da" branch based on 0.2.3, plus feature patches for directory authorities. It gets patches from the stable series (0.2.3), plus directory-authority features under development. It would get merged-forward into 0.2.4, to make sure that 0.2.3-da and 0.2.4 behavior stay in sync.
This way we can get new authority features working in time to support 0.2.4 clients, but without forcing too many authorities to run 0.2.4 before it's ready, and without forcing us to make feature changes in 0.2.3 proper.
Thoughts?
Sounds good to me.
Nick Mathewson nickm@freehaven.net wrote Fri, 31 Aug 2012 11:57:04 -0400:
| Hi, all! | | Here's an idea I had for directory authorities and the 0.2.3 release series. | | "As you know Bob," Tor 0.2.3 will be stable very soon, and I'm hoping | not to take any more patches for it except for important security | issues. I want 0.2.4 to come out very early next year. But in the | meantime, to support 0.2.4, and to deploy security/reliability | features to the network early, there are some directory consensus | features that we'd want to deploy before the rest of 0.2.4 is done and | stable. | | In particular, I'd like directories to be able to reach consensus on | IPv6 addresses (6363), and I'd like to try out the code that Mike | wrote to make the bandwidth voting system more robust against | dishonest during its startup phase (2286). | | So here's my plan: Make a "maint-0.2.3-da" branch based on 0.2.3, plus | feature patches for directory authorities. It gets patches from the | stable series (0.2.3), plus directory-authority features under | development. It would get merged-forward into 0.2.4, to make sure | that 0.2.3-da and 0.2.4 behavior stay in sync. | | This way we can get new authority features working in time to support | 0.2.4 clients, but without forcing too many authorities to run 0.2.4 | before it's ready, and without forcing us to make feature changes in | 0.2.3 proper. | | Thoughts?
Sounds good to me.
Just a thought. A few of the directory authorities, I think at least three, as well as the bridge authority run packages/ports only, not builds from source. We'd have to package our -da branch ourselves for those I guess. But that's probably a better option than the others.
On Sat, Sep 01, 2012 at 12:36:51AM +0200, Linus Nordberg wrote:
Just a thought. A few of the directory authorities, I think at least three, as well as the bridge authority run packages/ports only, not builds from source. We'd have to package our -da branch ourselves for those I guess. But that's probably a better option than the others.
Right. The people who are willing to run from git generally are fine running master (and helping to find bugs), so it's really the people who only run from packages that we need to consider here.
Maybe we should just enumerate the eight directory authorities and their habits, rather than trying to generalize too early?
- I generally run moria1 from git master, to maximize the cool new bugs I can find.
- I think weasel only runs tor26 from debs. I wonder what he would think of us asking him to deb up a separate git branch for just a few people? He says "I don't mind running 0.2.4 - it's not worse than running a fork of 0.2.3."
- Linus runs maatuska from git, and is happy with git master too.
- I'm not sure about gabelmoo, dizum, dannenberg, turtles, and urras.
--Roger
On Sep 1, 2012, at 1:02 AM, Roger Dingledine wrote:
On Sat, Sep 01, 2012 at 12:36:51AM +0200, Linus Nordberg wrote:
Just a thought. A few of the directory authorities, I think at least three, as well as the bridge authority run packages/ports only, not builds from source. We'd have to package our -da branch ourselves for those I guess. But that's probably a better option than the others.
Right. The people who are willing to run from git generally are fine running master (and helping to find bugs), so it's really the people who only run from packages that we need to consider here.
Maybe we should just enumerate the eight directory authorities and their habits, rather than trying to generalize too early?
- I generally run moria1 from git master, to maximize the cool new bugs
I can find.
- I think weasel only runs tor26 from debs. I wonder what he would think
of us asking him to deb up a separate git branch for just a few people? He says "I don't mind running 0.2.4 - it's not worse than running a fork of 0.2.3."
Linus runs maatuska from git, and is happy with git master too.
I'm not sure about gabelmoo, dizum, dannenberg, turtles, and urras.
I run gabelmoo from git, typically not tip of master early in a release series except when necessary.
Roger Dingledine:
On Sat, Sep 01, 2012 at 12:36:51AM +0200, Linus Nordberg wrote:
Just a thought. A few of the directory authorities, I think at least three, as well as the bridge authority run packages/ports only, not builds from source. We'd have to package our -da branch ourselves for those I guess. But that's probably a better option than the others.
Right. The people who are willing to run from git generally are fine running master (and helping to find bugs), so it's really the people who only run from packages that we need to consider here.
I think one thing to consider is just making the building of deb packages a bit easier. I did this with weasel in Italy and it wasn't actually too painful; if I were to document those steps, would anyone actually build debs for themselves? Or is the issue actually building the debs more than anything else?
Maybe we should just enumerate the eight directory authorities and their habits, rather than trying to generalize too early?
- I generally run moria1 from git master, to maximize the cool new bugs
I can find.
I do the same.
- I think weasel only runs tor26 from debs. I wonder what he would think
of us asking him to deb up a separate git branch for just a few people? He says "I don't mind running 0.2.4 - it's not worse than running a fork of 0.2.3."
It seems like it might be nice to have a deb that builds a deb with custom options- sorta like the old djb packages. There are a lot of variants that would be nice - arm, tor-fw-helper, a specific git rev, etc. One package that generated a deb with your flavor of Tor would be pretty neat. I think though, I just heard weasel's head explode... ;-)
Linus runs maatuska from git, and is happy with git master too.
I'm not sure about gabelmoo, dizum, dannenberg, turtles, and urras.
I run urras from a frequently updated git tip of master. It has a few small patches but nothing major or of consequence.
All the best, Jake
Nick Mathewson:
Hi, all!
Here's an idea I had for directory authorities and the 0.2.3 release series.
"As you know Bob," Tor 0.2.3 will be stable very soon, and I'm hoping not to take any more patches for it except for important security issues. I want 0.2.4 to come out very early next year. But in the meantime, to support 0.2.4, and to deploy security/reliability features to the network early, there are some directory consensus features that we'd want to deploy before the rest of 0.2.4 is done and stable.
In particular, I'd like directories to be able to reach consensus on IPv6 addresses (6363), and I'd like to try out the code that Mike wrote to make the bandwidth voting system more robust against dishonest during its startup phase (2286).
So here's my plan: Make a "maint-0.2.3-da" branch based on 0.2.3, plus feature patches for directory authorities. It gets patches from the stable series (0.2.3), plus directory-authority features under development. It would get merged-forward into 0.2.4, to make sure that 0.2.3-da and 0.2.4 behavior stay in sync.
This way we can get new authority features working in time to support 0.2.4 clients, but without forcing too many authorities to run 0.2.4 before it's ready, and without forcing us to make feature changes in 0.2.3 proper.
Thoughts?
yrs,
I think this is a fine plan - my preference is generally to track git tip for urras. I'm happy to track whatever branches need experimenting or lots of use. I will need to acquire some IPv6 space for the machine soon for it to be of maximal usefulness in the future....
All the best, Jake
On Tue, Sep 4, 2012 at 10:57 PM, Jacob Appelbaum jacob@appelbaum.net wrote:
Hi, Jake!
I think this is a fine plan - my preference is generally to track git tip for urras. I'm happy to track whatever branches need experimenting or lots of use. I will need to acquire some IPv6 space for the machine soon for it to be of maximal usefulness in the future....
What I really need to hear on this question is whether there are directory authority operators who are *not* comfortable tracking 0.2.4.x-alpha, but who *would* be comfortable running a hypothetical 0.2.3-da series.
If there are are a significant number of such operators, it might be worthwhile to make an 0.2.3-da. But if everybody's happy tracking 0.2.4.x or tracking git, there's no real reason to put out an 0.2.3-da., I think.
Thus spake Nick Mathewson (nickm@freehaven.net):
On Tue, Sep 4, 2012 at 10:57 PM, Jacob Appelbaum jacob@appelbaum.net wrote:
Hi, Jake!
I think this is a fine plan - my preference is generally to track git tip for urras. I'm happy to track whatever branches need experimenting or lots of use. I will need to acquire some IPv6 space for the machine soon for it to be of maximal usefulness in the future....
What I really need to hear on this question is whether there are directory authority operators who are *not* comfortable tracking 0.2.4.x-alpha, but who *would* be comfortable running a hypothetical 0.2.3-da series.
If there are are a significant number of such operators, it might be worthwhile to make an 0.2.3-da. But if everybody's happy tracking 0.2.4.x or tracking git, there's no real reason to put out an 0.2.3-da., I think.
For me, it comes down to the update frequency. It's fairly painful for me to update my dirauth, or even to change its config. If we expect 0.2.4.x to require very frequent updates on the part of dirauth operators, I think I'd prefer 0.2.3-da.
I don't require packages, though. I also build directly from git.
-
andrea＠persephoneslair.org -
Jacob Appelbaum -
Linus Nordberg -
Mike Perry -
Nick Mathewson -
Roger Dingledine -
Sebastian Hahn