Re: [Tails-dev] incremental upgrades: phase one almost done,…

このメッセージを削除

このメッセージに返信
著者: anonym
日付:  
To: The Tails public development discussion list
題目: Re: [Tails-dev] incremental upgrades: phase one almost done, release plan
14/11/12 11:07, intrigeri wrote:
> Hi,
>
> intrigeri wrote (27 Sep 2012 07:24:38 GMT) :
>> I think I'll want to prepare and publish an IUK for 0.14, and have
>> some early testers try it.
>
> Update-description files and an IUK from 0.14~rc2 to 0.14 are now in
> place, and can be tested. Please do test them.
>
> Sadly, the IUK is huge (150MB) due to Debian point-release + updated
> iceweasel + updated openoffice.org. I think this is about the worst
> case that can happen in practice.
>
> On a fast and reliable enough Internet connection, the update process
> worked for me the first time. On flaky Wi-Fi, it failed a few times
> and I was not patient enough to go on testing until success.
> Added "Should be more robust on flaky Internet connections" to the
> todo list.


I tested this for 0.14~rc2 to 0.14, and all went smoothly. Congrats on
your awesome work!

However, the upgrade took over an hour to complete as it seems I
happened to pick a terrible circuit. That is one hour without any
user-feedback what so ever. I had to look up the temporary file and see
if anything was actually happening with it in order to convince myself
that the download hadn't crashed or similar. I suspect our users will
quickly assume that something went wrong.

I know a progress bar is planned (I looked around in the ticket), but
due to my experience above I think it's an absolute must that it's
implemented before we announce this feature publicly. Other useful
controls for the window showing the progress bar could be:

* Button for aborting upgrade cleanly.
* Button for resuming an interrupted download (to handle e.g. the "flaky
Wi-Fi" case?)
* A rough ETA estimator (useful if running on battery or when otherwise
having time constraints).
* I'm not sure about this one, but what about a "Retry with new circuit"
button? Circuit throughput varies wildly, and since this is a large
download, it'll quickly wear out users' patience if a bad circuit is
picked. Or maybe this can happen behind the scenes, e.g.:
Automatically switch circuit every X minutes or Y% progress? That
could even make fingerprinting the download on the Tor client <->
Entry Node side of the pipe a bit more difficult, for whatever that's
worth.

Cheers!