Georg Koppen:
Hi,
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.
We'll follow and release Tor Browser on Thursday as well.
Got it! It makes sense for you Tor Browser folks, since the Firefox security issues fixed in ESR 52.3 are not publicly known yet (at least in theory, but the code changes have been out for a week so they can have been reverse-engineered).
But what about Tails? Tails 3.2, which is ready to be published right now, would fix several publicly known security issues for our users, including some potential RCEs (Thunderbird, libsoup, ...). Of course, some of these issues have been out for weeks already, so what's two more days of delay? 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?
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!
Tor Browser folks, would you care if we released Tails 3.2 right now, so we in effect release Tor Browser 7.0.6 way before you? What do you feel about this in general?
As for asking Mozilla, I'm not even sure who/where to ask. Does any one have a clue?
Cheers!
Hi, Mozilla folks!
Geb told me you might be able to answer whether Mozilla cares if a Firefox downstream would release something based on Firefox ESR 52.4 earlier than you (or that you might be able to forward it to the right channel within Mozilla). For details and the full context, see the quoted parts below!
Cheers!
anonym:
Georg Koppen:
Hi,
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.
We'll follow and release Tor Browser on Thursday as well.
Got it! It makes sense for you Tor Browser folks, since the Firefox security issues fixed in ESR 52.3 are not publicly known yet (at least in theory, but the code changes have been out for a week so they can have been reverse-engineered).
But what about Tails? Tails 3.2, which is ready to be published right now, would fix several publicly known security issues for our users, including some potential RCEs (Thunderbird, libsoup, ...). Of course, some of these issues have been out for weeks already, so what's two more days of delay? 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?
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!
Tor Browser folks, would you care if we released Tails 3.2 right now, so we in effect release Tor Browser 7.0.6 way before you? What do you feel about this in general?
As for asking Mozilla, I'm not even sure who/where to ask. Does any one have a clue?
Cheers!
Hello team,
I don't recommend that you ship before us. We do take last minutes patches. Some of them, you won't care (example: Windows accessibility support) but some others, you might (privacy issue or security fixes). So, if you want us to 0-day you (and clearly, we don't want to do that to you ;), you should really wait until we ship officially.
Cheers, Sylvestre
Le 27/09/2017 à 00:15, anonym a écrit :
Hi, Mozilla folks!
Geb told me you might be able to answer whether Mozilla cares if a Firefox downstream would release something based on Firefox ESR 52.4 earlier than you (or that you might be able to forward it to the right channel within Mozilla). For details and the full context, see the quoted parts below!
Cheers!
anonym:
Georg Koppen:
Hi,
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.
We'll follow and release Tor Browser on Thursday as well.
Got it! It makes sense for you Tor Browser folks, since the Firefox security issues fixed in ESR 52.3 are not publicly known yet (at least in theory, but the code changes have been out for a week so they can have been reverse-engineered).
But what about Tails? Tails 3.2, which is ready to be published right now, would fix several publicly known security issues for our users, including some potential RCEs (Thunderbird, libsoup, ...). Of course, some of these issues have been out for weeks already, so what's two more days of delay? 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?
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!
Tor Browser folks, would you care if we released Tails 3.2 right now, so we in effect release Tor Browser 7.0.6 way before you? What do you feel about this in general?
As for asking Mozilla, I'm not even sure who/where to ask. Does any one have a clue?
Cheers!
anonym:
Georg Koppen:
Hi,
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.
We'll follow and release Tor Browser on Thursday as well.
Got it! It makes sense for you Tor Browser folks, since the Firefox security issues fixed in ESR 52.3 are not publicly known yet (at least in theory, but the code changes have been out for a week so they can have been reverse-engineered).
But what about Tails? Tails 3.2, which is ready to be published right now, would fix several publicly known security issues for our users, including some potential RCEs (Thunderbird, libsoup, ...). Of course, some of these issues have been out for weeks already, so what's two more days of delay? 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?
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.
Tor Browser folks, would you care if we released Tails 3.2 right now, so we in effect release Tor Browser 7.0.6 way before you? What do you feel about this in general?
Fine with me.
Georg
As for asking Mozilla, I'm not even sure who/where to ask. Does any one have a clue?
Cheers!
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.
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@boum.org if needed) or put anonym in touch with the Mozilla release engineering folks who could answer?
Cheers,
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@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
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@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).
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!
Hi,
anonym:
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.
Thank you for pushing me to think about it deeper than expressing raw feelings.
My general answer is: what a downstream does has all kinds of impacts on their upstream, and that impact can be problematic especially when downstream diverges in some way (be it by patching code, by changing default settings, by releasing in an uncoordinated manner, etc.)
For example:
- Releasing upstream's work before they do can create confusion for users wrt. version numbers and released / not released status, which can result in additional support work upstream (e.g. "why can't I install Firefox x.y? Tor Browser already has it").
- Releasing upstream's work before they do can dilute their communication.
- Releasing upstream's work before they deem it ready for prime time can result in bad user experience, and some users might erroneously (but understandably) think the root cause is upstream, which results in bad feelings/press about upstream.
- Similarly, modifying upstream's code or default prefs can create confusion for users, erroneously attributed bad UX/feelings/press, and additional support work upstream.
- See the last bullet list on https://tails.boum.org/contribute/derivatives/ :)
I suspect you'll easily find a bunch of other such problems if you pretend *you* are the upstream, and then someone releases something that's almost Tails but not quite, with either modified code/prefs or a different release schedule, and despite their good faith and attempts at clear communication, no matter what a bunch of people will be confused, will get it wrong, will ask questions in the wrong place, will write misleading stuff on Twitter, will write mistaken rants on Reddit.
Cheers!
anonym:
[snip]
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!
If you think you have really good arguments that it is urgent that Tails users get the update X days earlier than we (and Mozilla) are releasing then I am happy to explain that to users on our blog and elsewhere (who might be wondering what's up with the new Tor Browser and Firefox versions we and Mozilla are about to get out).
Or put in different words: there are costs involved for upstream projects by downstream releasing new versions earlier and there are risks involved by downstream doing so (missing last minute bugfixes etc.). But if you still think that's worth it in particular cases, then go for releasing earlier.
Georg
-
anonym -
Georg Koppen -
intrigeri -
Sylvestre Ledru