[tor-dev] "Not our bug" bugs

[Georg Koppen]

Griffin Boyce:
> Hey all,
> 
> There have been quite a few bug reports that discuss incompatibility with
> various Firefox extensions and with websites. In most cases, I can't
> replicate
> these bugs -- either because the extension in question has been patched,
> the
> website reported no longer exists, or the issue can't be replicated
> (which could
> be due to site updates and past Firefox incompatibility).
> 
> Occasionally, the issue is real and still in effect, but isn't really a
> Tor bug
> (such as #7279, where a forum restricts logins by Tor users). We've all
> worked
> very hard to reduce overly-restrictive blacklist policies, but can't be
> everything for everyone.
> 
> In these cases, I'd propose rejecting these bugs as either invalid or
> `not a
> bug`. These are all varying degrees of "not our bug" or "actually not a
> bug at
> all." Open to more thoughts on this.

I am inclined to agree with the "not our bug" in cases where websites
restrict Tor user access. At least this is not a Tor Browser bug.

However, figuring out whether it is really not our bug might not be as
trivial in other cases. Especially, given that we are able to write
fixes for the Firefox part and our toolchains ourselves (at least in
theory). So, issues caused by our Firefox modifications or caused by the
extensions we ship are clearly bugs on our side. But even things that
Mozilla fixed upstream but are still present in our fork should be
tracked in our bug tracker. We might find easy workarounds we could ship
or might want to reprioritize things to get a proper backport in case it
affects a lot of users or users under particular and for Tor users
relevant circumstances. I am thinking, too, that we should track bugs in
our toolchains on our side, too, even if the sole reason were to have a
good overview in Trac available where additional work is needed.

To sum this up, I think we should be quite liberal if we think about
classifying issues as bugs even if they are not directly caused by code
maintained/written by us.

Georg




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160318/b78c5325/attachment.sig>