[Pkg-privacy-maintainers] Bug#861744: Bug#861744: Bug#861744: Bug#861744: torbrowser-launcher: Should not be part of Stretch

[u]

Hi,

intrigeri:
> Holger Levsen:
>> On Mon, May 22, 2017 at 12:12:39PM +0200, intrigeri wrote:

>> I don't plan to be involved.
> 
>> My trigger to send this mail are those mails generated through the failures
>> on https://jenkins.debian.net/view/torbrowser/ - I get a daily mail that
>> torbrowser-launcher in jessie is broken, and weekly mails about the breakage
>> in wheezy-backports and jessie-backports.
> 
>> So of course what I shall do is to disable those mails to me, after all
>> I'm one of the maintainers of jenkins.d.n :) But then I fear that
>> torbrowser-launcher will bitrot even more…
> 
> Perhaps Ulrike would want to be the recipient of those email?

I am already receiving these emails, but I lack time to work on it, and
that's why I mostly ignore them (fragmented attention and information
overload - already too much of that in my life). I have prepared the new
version of TBL since 2 weeks, but I've still not uploaded it, even
though I simply made a mistake in the version information of the package
which should be modified. Maybe this illustrates my current lack of time
quite well.

>> So, in summary, yes, I disagree with this bugreport that I think that the
>> package is supportable in stable and then I realized that I also question
>> the plan to support it in stretch-backports, cause I'm very aware of the
>> status of the package in stable-backports and oldstable-backports today.
> 
> Thanks for clarifying.
> 
> The way I see it:
> 
> 1. We (collectively) did a poor job during the Jessie cycle; this
>    applies to stable, backports and to some extent even to
>    testing/sid.
> 
> 2. AFAIK we won't have more resources to put into this package during
>    the Stretch cycle, and quite the opposite actually: Holger took
>    a step back, Ulrike has other priorities with stronger commitments,
>    and I am not in a position to promise anything at this point.
> 
> With these 2 points in mind, the only reasonable course of action
> I can think of is to *lower* the bar, i.e. stop trying to do
> everything as it could be done with an infinite amount of resources:
> surely this package is "supportable in stable" in theory, but that's
> only theory until someone commits to do it… and actually does.

Absolutely.

> This is what Ulrike and I have been trying to do with this bug report.
> Preventing the package from being in Stretch might not be the best way
> to do it though; I would welcome other, realistic options (taking
> #1 and #2 into account) if someone has any.
> 
> Note: even the "maintaining the package in backports" part is
> something we should start doing very carefully IMO, not too early in
> the Buster cycle, and only after making sure we are ready to maintain
> it there for many years. It's similar to, and a bit cheaper than
> maintaining the package in stable, so it'll be a good start and will
> help us assess whether we're ready to have the package in Buster :)
> 
>> I realize that my position is not the most helpful one, but I thought and
>> think that it's also not helpful to be aware of problems and stay silent on
>> them.

Your position does at least seem controversial to me, if I may: as a
previous maintainer who suddenly removed his name from the Uploaders:
field - without prior notice nor a posteriori explanation to a supposed
_team_ of maintainers - and since then sends emails reminding others of
their duty to maintain this package preferrably in stable, I can't help
but underline your own assumption of not being very helpful.

As far as I'm concerned: I'm currently unable to process all bug
reports, follow upstream modifications and modifications in TorBrowser
itself, like signing keys and SSL certs. Regarding this state of things:
I might even call for an RFA at some point.

Cheers,
ulrike