[tbb-dev] [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser release is postponed by two days]

[Georg Koppen]

intrigeri:
> Hi,
> 
> Georg Koppen:
>> anonym:
>>> Georg Koppen:
>>>> Just to inform you about things we learned a couple of minutes ago: the
>>>> Firefox release is due on Thursday. It got postponed by two days mainly
>>>> to give 57 beta more publicity.
> [...]
> 
>>> Still, it makes me want to remember/re-evaluate *why* we always
>>> wait on Mozilla.
>>>
>>> What are your feelings around this? What are the arguments for/against releasing early?
> 
>> Not sure what you mean with "early", probably not as soon as one
>> critical security bugfix lands on the esr52 branch (because there are
>> many :) ). Releasing once candidate build1 is done then? It sometimes
>> happens that additional changes get pushed and a buildN is done or that
>> some of the patches need to get backed out due to issues Mozilla found
>> during their Q&A. I guess you don't want that risk either?
> 
> Sure.
> 
>>> TBH this has always seemed odd to me. I remember argument for this being about us
>>> behaving like good Free Software community members by coordinating releases.
>>> I wonder if they really care, especially given our users' position. So, let's
>>> ask them!
> 
>> I don't know whether they care but that argument has some weight for me
>> at least.
> 
> Same here.
> 
> But even putting ethical considerations aside, there's a strong
> technical argument in favour of waiting for Mozilla: their release
> engineering team is a much better position than us to judge when their
> code is ready to be shipped to users, and I don't think we should
> second-guess them.

Yes, I agree with that.

> Now, I'm open to making the occasional exception e.g. when we're
> certain that the *only* reason Mozilla has to delay a release, that
> they otherwise consider as "ready to ship", is about
> marketing/communication wrt. channels we don't track ourselves.
> If/when we do so, we should be extremely clear (e.g. in our changelog
> and release notes) that we're shipping something based on what will
> probably become FF ESR x.y.z, and not something based on FF ESR x.y.z.
> 
> In the case at hand, Georg wrote "mainly" so it's not clear to me what
> other reasons they have for delaying the release. Until this is
> clarified, I don't think we're in a good position to tell we can go
> ahead without waiting. Georg, can you please share any other info you
> have (possibly privately to tails-rm at boum.org if needed) or put anonym
> in touch with the Mozilla release engineering folks who could answer?

The delay was planned due to Firefox 57 Beta getting more publicity. I
used "mainly" because Mozilla needed this time six candidate builds for
Firefox 56 fixing, among others, last minute crash bugs (the last
candidate build got kicked off yestderday). I am not sure whether they
would have delayed the release for those, though. They might have
shipped follow-up releases instead. So, I think it is fair to summarize
the situation that Firefox 56 (and Firefox 52.4.0esr) got delayed by two
days due to PR/publicity requirements (which fit very well to the
technical issues (and solving them) related to this release cycle).

Georg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20170927/9e80f1e1/attachment.sig>