Re: [Tails-dev] Release schedule for Tails 1.6
Hi, anonym wrote (27 Aug 2015 14:59:02 GMT) : Ideally I would like *everything* (including testing, most notably) but the steps making the release public (announcements on our website/IRC/twitter/Tor blog) to be done late on 2015-09-21. If someone with Git commit rights would like to take over that part (which should be only 5-10 minutes of mindless work, since I will have prepared everything, + waiting for the Mozilla release announcement) I would be very happy. I suggest that someone who wanted to get started with RM work (that would be... tadam... bertagaz!) does it. I can assist them on IRC as needed. Testers, please let me know: * if you are available on 2015-09-21, and which times of that day. I'm available from noon to 8pm CEST/CET. * if you are available on 2015-09-22, morning to afternoon, CEST. I'm available from noon to 8pm CEST/CET. Cheers! -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Testing Tor Monitor
Hi, sajolida wrote (27 Aug 2015 16:48:14 GMT) : C. Duplicate information In the list of circuits I sometimes see duplicated lines. Technical nitpicking: these are streams, not circuits :) For example when connecting to heavy websites like YouTube. See duplicates.png in attachment. Why not deduplicate these lines? I'm not sure what's the value of the there are multiple streams to this IP:PORT going on that circuit information. At first glance, I would say let's deduplicate, but perhaps I'm missing a use case or three? Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Automated tests specification
Hi, On Wed, Aug 26, 2015 at 07:46:17PM +0200, anonym wrote: On 08/26/2015 07:21 PM, bertagaz wrote: The rational behind my proposal was that it would at least raise the issue if there were some external changes that breaks the build of this feature branch (mostly, changes in APT/Debian). ... so this was the point I was gonna make, but apparently forgot. And I some how missed your mention of external changes in your response to intrigeri. Great, then we're on the exact same page! :) Yep, that's nice! :) I expect things to quickly go out of hand if we do it on every push, but hey, my expectations are frequently wrong. I say we try it if it's easy to quickly switch to your suggested optimization if needed. Well, in fact we already decided to use different strategies depending on the ReadyForQA state of a branch. So it will be implemented at the beginning. :) Yes, cucumber tags were the solution I was thinking about to implement this. But I get your do not miss stuffs argument and it sounds completely rational to me. Yet that could be an option we could combine with the previous one (test only ReadyForQA branches): we could test only specific features for all the dev life of a branch, and then once it is marked as ReadyForQA, run the whole test suite on it. That would pretty much looks like the way you describe the development of a branch. Ok, this sounds more acceptable. I've updates the Future ideas section of the blueprint with this. I've also added a new section about the result to keep: ## What kind of result shall be kept The test suite produces different kind of artifacts: logfiles, screen captures for failing steps, snapshots of the test VM, and also videos of the running test session. Videos may be a bit too much to keep, given they slow down the test suite and might take quite a bit of disk space to store. If we want to keep them, we may want to do so only for failing test suite runs. But then, often the screen capture are enought to identify why a step failed to run. If we decide to still use them, then we probably have to wait for [[!tails_ticket 10001]] too be resolved. Proposal: * For green test suite runs: keep the test logs (Jenkins natively do that) * For red test suite runs: keep the screen captures and the logs. The retention strategy should be the same than for the automatically built ISOs. I don't expect this last one to raise a lot of discussions, so let say that the deadline for this thread is next Sunday 12pm CEST unless some points are still not clear. I think the rest has already been discussed and drafted enough. bert. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] tails cryptographic signature deadlink
Hi, Victor Roemer wrote (28 Aug 2015 13:04:37 GMT) : The following link is dead: https://tails.boum.org/torrents/files/tails-i386-1.5.iso.sig Fixed, thanks. Also, why isn't there an non-torrent link? I don't understand what you mean here. May you please clarify? ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Update on Firefox extension
Hi, Meta: putting tails-ux in copy for the info but please answer on tails-dev only. I wanted to clarify a bit what's going on regarding the development of the Verification Extension (#7552). In terms of specs, I realized that we were not taking into account the case where the download might get interrupted either on the client side by a faulty network connection, either on the server side by a faulty mirror. That's now #9717 and I proposed a mockup: https://labs.riseup.net/code/attachments/download/922/extension-20150828-resume.pdf Tchou, can you have a look (as I couldn't assign the ticket to both you and Maone). In terms of HTML+CSS, we're still waiting for tchou to review and mockup the code on /blueprint/bootstrapping/extension/prototype. That's #9384. And to draft a CSS. That's #9385. Tchou, any ETA on that? In terms of mirror support, we did great progress to disable ETags on all the mirrors. Only one of two still have them but we can replace them pretty much any time if needed. In terms of extension code, Maone told us he would be busy with other extension work over the summer but maybe he's back on track now. Giorgio what's up? Do you have any ETA for a first prototype? Anything blocking you? Just to let you know, we want to do extensive user testing sessions of the whole process (Installation Assistant + Verification Extension) in November. So we need all the pieces to be ready by then. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update on Firefox extension
sajolida: https://labs.riseup.net/code/attachments/download/922/extension-20150828-resume.pdf Broken link: https://labs.riseup.net/code/attachments/download/924/extension-20150828-resume.png ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 1.6
On Thu, 27 Aug 2015 14:59:17 + (UTC) anonym ano...@riseup.net wrote: Testers, please let me know: * if you are available on 2015-09-21, and which times of that day. In the middle of the night in Europe when most people are sleeping might be best. * if you are available on 2015-09-22, morning to afternoon, CEST. Will try. pgpZaIVxfrrDY.pgp Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update on Firefox extension
On 28/08/2015 17:37, sajolida wrote: In terms of extension code, Maone told us he would be busy with other extension work over the summer but maybe he's back on track now. Giorgio what's up? Do you have any ETA for a first prototype? Anything blocking you? The main roadblock was Mozilla finalizing its add-ons migration strategy to the Electrolysis (e10s) multi-process sandboxing architecture. Without an ultimate public decision, which has been deemed imminent for all the past month (see https://labs.riseup.net/code/issues/8567#note-7 ), it was hard to even decide which of the 4 different technical approaches to develop Firefox add-ons was the best for this project: 1. XUL/XPCOM, like desktop NoScript; 2. restartless, like Android NoScript; 3. Add-on SDK; 4. WebExtensions, the new, future proof, Chromium-like thing (not even disclosed yet until last week, but I was aware of it earlier because I've been working closely with the e10s/add-ons team) This finally happened last week, with this announcement: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ More about WebExtensions: https://wiki.mozilla.org/WebExtensions/ https://wiki.mozilla.org/WebExtensions/FAQ As I told intrigeri when we met, I had really hoped to develop our extension with the new API to improve its longevity and make a Chrome porting easy to do and maintain, but unfortunately, as you can also deduce from the links above, the decision have been dragged for so long that we wouldn't be able to support the Tor Browser (based on ESR) for about on year. Furthermore, until my own native.js proposal ( https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457 ) gets implemented ( https://bugzilla.mozilla.org/show_bug.cgi?id=1199718 -- filed just minutes ago), the WebExtensions API is not powerful enough to support our requirements. Therefore the only currently available option ensuring longevity is the Add-ons SDK (AKA Jetpack). I've just received guarantees from Mozilla (in a meeting held today) that they will give us any assistance for our extensions to be supported by any of the foreseeable future Firefox versions. I've already set up a development environment and started hacking. I'm gonna commit something to the git repository next week, and a working prototype most likely by the end of September. Just to let you know, we want to do extensive user testing sessions of the whole process (Installation Assistant + Verification Extension) in November. So we need all the pieces to be ready by then. I'm confident it's going to happen timely. -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
