Re: [Tails-dev] Should we delay Tails 3.2? [Was: Tor Browser…

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?

I was not talking about the general case, but about the specific situation we are in now with Tails 3.2, i.e.: we're told Tor Browser is delayed because of Mozilla PR reasons, but we are ready to release two days early (well, "one day" by now).

(I know you said "mainly" above, but I must confess I more or less ignored that word, so your statement became much more absolute in my head. I certainly assumed it meant that the QA was done, and that you would be clear with the QA not being done if you knew it to be the case. Lot's of assumptions, I know, but in my defence I never intended to act without some sort of ACK from Mozilla. :))

So, for the general case: if Mozilla's and your (Tor Browser folks) QA has passed, and you are only waiting x time before releasing publicly for non-technical reasons, do you care about Tails releasing x time earlier than you?

>>>> 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.

I would really want to understand this (and possibly agree as well :)). Why do both of you (and others?) feel this is important? This is not a rhetorical question, I simply don't get it. If your explanation depends on the QA status, please also include the case where QA passed so you answer can be applied for the Tails 3.2 case.

>> 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.

Me too! If it is not clear by now, my interpretation was that the code was ready to be shipped to users, and the delay was due to PR concerns only.

>> 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.

Agreed!

>> 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@??? 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).

Thanks for the clarification!

To me this means the responsible thing vs. our users is to release now, but it is still unclear what is responsible vs release coordination with our upstreams. The sort of answer I'd be looking for is from our upstreams is:

* "As an upstream, we agree that protecting your users is more important than release coordination between our projects, so please go ahead and release early", or

* "As an upstream, we feel release coordination is very important; please rebuild Tails 3.2 with the old browser and prepare an emergency release with the new browser in two days, or simply delay the release if you cannot afford this".

(Note: these are just examples, I'm sure there are other positions to hold on this matter.)

Any way, it's clear there won't be an agreement in time for an early release to make sense, so I'll delay Tails until tomorrow. Let's downgrade the urgency of this thread, but let's not drop it; I'd like to know what to do next time this happens!

Cheers!