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

[intrigeri]

Hi,

Holger Levsen:
> On Mon, May 22, 2017 at 12:12:39PM +0200, intrigeri wrote:
>> Fundamentally, do you disagree with the main point this bug report is
>> about i.e. "Should not be part of Stretch"?

> yes, somewhat, but I acknowledge that it's not my call.

>> And if you indeed do want to see this package in Stretch, how do you
>> plan to be involved on maintaining it via stable-security or
>> stable-updates?

> 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?

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

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.

Thanks.

Cheers,
-- 
intrigeri