[tor-dev] Syncing the Tor+TBB release schedules?

[Mike Perry]

Nick Mathewson:
> On Fri, Mar 13, 2015 at 11:50 AM, Isabela <isabela at riseup.net> wrote:
> > This is a great discussion, thanks Mike for writing down TBB release
> > process.
> >
> > I think is very important to start being more strategical on how we plan the
> > different projects releases. Of course this doesn't mean we have to force a
> > big change right away, that is why the discussion is important so we can
> > figure out a good plan on how to do it.
> >
> > Let's see our options first:
> >
> [option 1]
> > match Core Tor release 0.2.7 with TB 5.0-x release
> >
> > pros: PT and control port compatibilities
> 
> TB 5.0 gets _some_ new Tor features beyond whatever 0.2.6 provides.
> 
> > cons: probably will have to cut in half the number of features for 0.2.7
> > release (should analyze how that can affect sponsor deliverables we are
> > committed to)
> 
> Also, we might be tempted to avoid putting in larger features to 0.2.7
> if we think that they might take more time.
> 
> [option 2]
> > target 0.2.6 for TB 5.0-x stable, and aim for 0.2.7 to go out in the next TB
> > series
> >
> > pros?
> 
> TB has a stable Tor to include; Tor team can c
> 
> > cons?
> 
> TB 5.0 doesn't get whatever improvements we do in 0.2.7.
> 
> > Did I missed anything?
> 
> Option 3:  Ship TB 5.0 with 0.2.7 in whatever state it happens to be
> when TB 5.0 is released.
> 
> Pros:
>   * As many new features as possible in TB 5.0
>   * Not much additional effort for the Tor team
> 
> Cons:
>   * Likely unstable Tor in 5.0; possibly buggy Tor in TB 5.0.
> 
> 
> Option 4: Ship TB 5.0 with a version of 0.2.6 including some items
> backported from 0.2.7
> 
> Pros:
>   * TB has the features from Tor that the TB team thinks are most important.
>   * TB ships with a pretty stable Tor.
> 
> Cons:
>   * Some stability risk, but less so than option 3.
>   * Some high-complexity features may be too difficult to backport.

Thanks for breaking out all the options, Isabela and Nick!

After more consideration of all of them, given that these next few
months will be spent mostly doing rebase work, I think either Option 2
or Option 4 above seem like the best plan.

The only reason we should *need* new Tor features during the FF38 rebase
effort is if the pluggable transports decide they need new Tor features
in that timeframe. In fact, better PT support/fixes were the reason for
most/all of our previous round of tor patch backports.

Otherwise, we would just be including Tor 0.2.7 for more testing
exposure. If the tor-core folks are fine waiting a bit longer before
0.2.7 sees a TBB release, I think it's fine for us to wait, too.




-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150315/edcb57d6/attachment.sig>