[Pkg-privacy-maintainers] New torbrowser-launcher upstream version is out Was: Bug#803171: this only affects one profile in complaint mode

[intrigeri]

Hi,

given how the discussion has escalated, I'll add a good amount of meta
around the technical points that are being discussed here.

Holger Levsen wrote (12 Jul 2016 18:23:04 GMT) :
> On Mon, Jul 11, 2016 at 04:55:00PM +0000, u wrote:
>> We did not agree on that, however, if you look at the state of the
>> pristine-tar branch it's simply a fact that the latest versions did not
>> use it anymore. Unless I miss something here. This branch is not even
>> present at
>> https://anonscm.debian.org/git/pkg-privacy/packages/torbrowser-launcher.git
>> anymore.
>> 
>> I *do* have a local copy of the pristine-tar branch from about a year
>> ago, when I last worked on this package. So, either somebody takes care
>> of putting the branch back it into shape or we disable it in gbp.conf.
>> That's what I have done for the time being.
>> 
>> Do you actually use pristine-tar? If yes, maybe you need to push your
>> branch with the latest additions, and then I'll happily take care of
>> updating it. In any case, I guess that one should also document how to
>> update this package correctly in debian/README.source.
>  
> my point is: we agreed on this workflow, because we thought this was the
> best possible workflow for this. so I would expect a discussion before
> officially burying it.

> (and no, I havent used pristine-tar here recently, in fact I think I did
> the last upload ignoring pristine-tar. but this was ment as a temporal
> thing, to get the upload done.)

> and as I tried to say in my first/last mail on this: I dont mind the
> change. I mind the change without discussing it first.

[Context: I believe this discussion is about
https://anonscm.debian.org/git/pkg-privacy/packages/torbrowser-launcher.git/commit/?h=debian/sid&id=16bcb4f92e5bd25647cb5696e4af81381eba11a6]

I'm surprised to read that pristine-tar not being used was something
temporary, that affected only recent uploads. From my PoV, it looks
like this package's workflow simply has _never_ beeng ported to using,
pristine-tar since we took it over 2 years ago: I could not find any
trace of pristine-tar usage in Git, while I see a history of merging
new upstream releases in ways that would make pristine-tar usage
quite painful.

So, to me this gbp.conf modification does not imply anything like
"officially burying" a workflow: the theory is left unchanged (until
decided otherwise, we prefer using pristine-tar for all our packages),
and the practice does not change either (torbrowser-launcher is an
exception to the rule, until someone feels a urge to change this
situation).

I see the discussed commit as a minor convenience change, and quite
frankly I'd rather not expect each other to discuss such changes
before implementing them, in particular when it does not affect the
resulting package (it simply formalizes what has always been done),
and can trivially be reverted. Holger: I really have a hard time
understanding your reaction on this one; I'd like to understand why
you feel so differently than I've described about this change, enough
to insist that this change should have been discussed before being
applied to Git, after u explained the best she could why the change
wasn't really one in practice.

(And if we need a more general discussion about how we order
commit/discussion, let us know.)

Now down to the actual change that's being discussed — encoding in
debian/gbp.conf the way we use gbp for that package seems worthwhile
to me:

 * it makes it easier, for those of us who do use gbp, to work on this
   package (one less command-line switch one has to think to manually
   pass gbp just for this package);

 * it documents how this package is _practically_ maintained, i.e.
   the fact it's an exception to our best practices, which is useful
   regardless of whether we see this exception as a problem: that file
   is the only place where we can easily share per-package gbp config
   between team members, and in particular it can be useful for those
   of us who don't work regularly enough on torbrowser-launcher to
   remember by heart how exactly it's different from our
   other packages.

u:
>> That is not correct. This english language bug is a new feature. It was
>> not present before. Thus I fail to see how it can break current
>> behaviour TBH.

New code can very well break apparently unrelated, and previously
working, functionality. I'm sure we can agree on that :) I don't
really understand how we can be stucked there at that point of the
discussion, given the code and error output we've seen. I _guess_ it
has to do with how the bug was reported to you, but I'd love to
understand your reaction better.

I wanted to understand what was happening so I had a look.
My understanding of the code and error output is that when tbl is
started in en_US locales, self.force_en_checkbox is never set, so it's
no surprise that the following statement:

        self.common.settings['force_en-US'] = self.force_en_checkbox.get_active()

… raises the exception reported by Jenkins.

I've tested it locally and I confirm that there's a serious regression:

 Given I am logged in with en_US locales
 And ~/.local/share/torbrowser/ and ~/.config/torbrowser/ don't exist
 When I start "Tor Browser Launcher" (not "Tor Browser") from the
      GNOME Shell overview
 And I Click "Install Tor Browser" (or just press Enter, as Jenkins does)
 Then I see nothing happen on the desktop
 But the Journal has the same Python exception reported by Jenkins

IMO repairing something else, that has been broken for a while, is not
worth breaking this use case.

I've suggested the general idea of a fix (not an actual patch) on the
corresponding upstream bug report [1], and I bet that many other
people will be affected, so given the severity of the regression,
I guess that we can wait a bit more, and a new brown paper bag
upstream release should hopefully be out shortly.

[1] https://github.com/micahflee/torbrowser-launcher/issues/241

>> If this is now actually a bullhead contest, I'm out. _Out_ as in "please
>> remove me from Uploaders".

> Same here.

> :-(

I don't know what's a bullhead contest, but if it has something to do
with insisting on a point despite failing to understand what the other
party means, then I can see a couple such situations in this thread
(I'm not inferring that all what's happening is perfectly symmetric;
it clearly isn't, given the power relationship that are in play).

I know for a fact that we can do better!

What can we, other team members, do to help fix this situation?

> I can't believe you're thinking I'm interested in a "bullhead contest"
> instead of trying to do whats best for our users and free software.

Let me be a bit silly for a moment: I can't believe you're thinking
that u is thinking that :P

Seriously, this sentence triggers a bunch of alarms in my head.
I don't want to let this slip to the point when u has to reassure you
about all that herself, because that would simply feel too creepy, so
here we go: nobody in here is implying that you're interested in
"bullhead contests". And I doubt that anybody in here believes that
you're interested in that.

Except it matters very little, because this has nothing to do with
what you are interested in, nor with your end goals you consciously
have, nor with what person you want to be ideally. It has to do with
how we (you + I + u + others) behave, and what situations our behavior
creates or perpetuates *in practice*. E.g. I'm not interested in
perpetuating a racist and patriarchal system, but I'm not the ideal
person I want to be, and some of my behavior does reinforce that
crap :/

And we can very well end up in a "bullhead contest" even if we would
rather not to.

Meta: I know all this sounds awfully patronizing and condescending.
Sorry about that, I can't do better right now, and doing it anyway
seemed better than shutting up.

♥
-- 
intrigeri