Re: [Tails-dev] Automated builds specification

2015-02-20 Thread intrigeri
Hi,

bertagaz wrote (19 Feb 2015 21:39:25 GMT) :
 On Mon, Feb 16, 2015 at 04:39:22PM +0100, intrigeri wrote:
 bertagaz wrote (16 Feb 2015 12:03:12 GMT) :
  Ack, sounds reasonable. However from what I've seen, it sometimes means a
  lot of branches so I wonder if we scaled our infra enough for that, as we
  didn't include this branches in our maths since the beginning of the
  discussion.
 
 This seems like a serious bug in this discussion process. May you
 please then provide example numbers that match what the proposed
 algorithm would output, so that we can reason about it?

 I've added to the statistic page the doc branches that have been merged.
 Part of them were not in the output of the script because they often get
 merged in master. It seems to add 4 to 6 branches per release, but their
 development and integration flaw is a bit different.

I've modified my count-merges script locally to take into account
merges into master too, but it didn't catch any more merges.
No surprise, given e.g.:

  git log 1.1..1.3-rc1 --merges --pretty=oneline | grep master | grep doc

... returns no such merge. Possibly the doc branches are merged
without --no-ff into master? sajolida, any idea?

 So in the end, I'm not sure they'll add a lot more load, but we have to
 count them in our maths.

Yep. Too bad we can't really do that with good stats.

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] What do we miss to replace Vidalia [was: Getting rid of Vidalia]

2015-02-20 Thread Alan
Hi again,

On Thu, 19 Feb 2015 14:23:03 +
sajolida sajol...@pimienta.org wrote:
 intrigeri:
  sajolida wrote (18 Feb 2015 11:32:17 GMT) :
  intrigeri:
  Alan wrote (12 Feb 2015 15:32:15 GMT) :
- Ability to close a circuit manually.
 
[...]
  = seems like we can address this corner case in a good-enough way
  without compromising security nor spending large amounts of energy on
  this topic.
 
 Fine with me. Still, we would need to have arm documented in the first
 place. And since I propose it to go in Advanced topics anyway we can
 explain the workaround there for now and create the upstream ticket that
 you mentioned as well.
 
+1

[About the green onion]

  Now... does Vidalia really do that? In other words, does Vidalia's
  green onion really turn yellow or red or something whenever this
  happens? I don't think so: I *believe* that Vidalia's onion indicator,
  once it has turned green, only reflects the state of Vidalia's
  connection to the Tor control port, not the state of the tor daemon's
  connection to the Tor network. I don't remember seeing it change
  colors unless I e.g. restarted Tor. I'd be happy to be proven wrong,
  though :)
 
 Same for me, I'm pretty sure that Vidalia stays green forever once Tor
 is started.

...until Vidalia loose connection to the Tor daemon.

 And I'm fine with mimicking this behavior for a start if
 that's easier to implement (no regression), but I think this is buggy
 (the onion shouldn't be green if Tor is not in a working state anymore).
 I want to replace Vidalia to get rid of its bugs not to reimplement them :)
 
  but would it be conceivable to have Tor Monitor
  appear as green onion on the desktop as Vidalia does until now?
  
I don't think it's the way to go:

- I'd like Tor Monitor to stay a generic application, with a clear
  focus on being a monitor for Tor and showing whatever icon on the
  desktop doesn't look like the same task for me.
- System Tray Icons were deprecated in Gtk since 3.14. A proper
  implementation of this green onion for GNOME 3 desktop would be a
  (very simple) Shell extension, to which we (the NetworkManager
  hook) should send a DBus signal (or the opposite). That might be a
  tiny funny project.

[...]

 Yes, and if I understood correctly Tor Monitor currently needs Tails
 Jessie. So an obvious roadmap would be to have a working replacement of
 Vidalia with Tor Monitor (without regressions) in Tails Jessie. Does
 that sound realistic? Then only we can work on making it better (eg.
 smarter onion status icon, progress bar while starting Tor, etc.).
 
  And if Tor Monitor is always running in the background, then maybe it
  could also provide information while Tor is starting and be the right
  tool to solve #7437 in the future?
  
  That's what I had hidden in the back of my head when asking this
  question initially :)
  
I'm not opposed to exposing a DBus interface in a future version of
TorMonitor to provide the green onion or other applications more
information that our hooks could. But I'm not sure it is the right
place to do it yet.

  The main problem I see with this approach is: if we go this way, then
  either Tor Monitor stops being a generic tool, but becomes yet another
  Tails-specific thing, which would make me sad.
 
 Let's try to make it generic straight away! I'd love to have it on my
 regular Debian as well.
 
Me too! I'm not really into solving all the issues we have in this
application.

  I thought about it
  a bit harder, and now it's not obvious to me what we would gain by
  merging the two tools we need into a single one:
  
   * Tails could start the Tor bootstrap and time sync progress monitor.
 Upon completion, this piece of software would either just
 terminate, or (if we need a permanent indicator that's tight to the
 actual Tor status) start Tor Monitor --hide-in-taskbar, that would
 display some onion.
  
   * Anyone else would just use Tor Monitor.
  
  And then this topic becomes mostly orthogonal to the current
  discussion, I think :)
 
For the reasons I exposed before, I don't think it's the right
solution. But you can try to convince me...

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