[Pkg-anonymity-tools] torbrowser-launcher in Debian stable [Was: annotated tag debian/0.1.8-1 created (now 1e9ff2c)]

[Holger Levsen]

Hi,

On Mittwoch, 21. Januar 2015, intrigeri wrote:
> I don't know what Ulrike's and Holger's plans are regarding 0.1.8.

upload 0.1.8 to sid and ask for an unblock request, the changes are tiny and 
important. (both is on my agenda for today or maybe tomorrow.)

> I assume we could probably get another unblock request, but it seems
> to me that we can't sensibly postpone having a discussion with the
> release team wrt. what strategy could be applicable to maintain
> torbrowser-launcher in Debian stable.

we initialized that discussion already, see  
https://lists.debian.org/201408191441.32271.holger@layer-acht.org and 
followup.

from their non-reaction I assume they are "fine with it" as it's basically the 
way it is.

(I also think that "we can't sensibly postpone having a discussion" is phrased 
a bit too drastically. "Wait and see" or rather "wait and react then" is also 
often a sensible strategy. As you describe below we'll have several options, 
and IMO it's a feature that we'll be able to choose whichever suits us when 
whichever situation arises.)

> (I couldn't find any such previous discussion, please point me to it
> if we've already had it.)

done :)

> I guess our options are:
> 
> 1. Track upstream in Jessie
> 2. Track upstream via the "updates" archive (formerly "volatile")
> 3. Cherry-pick only required fixes from upstream
> 4. Drop from Jessie, maintain in backports instead

I agree these will be our options in the jessie lifetime and I think we should 
choose whichever is suitable when the situation arises. And to keep our 
workload low, we should try to get new upstream versions in, as long as 
possible. We should also try to convince upstream to only do maintainance 
updates in 1.x and put new development into a 2.x series - if much new 
development will happen at all, given that maybe the torproject itself will 
provide a torbrowser installer in future.

> Long-term wise, we should probably split the package between code
> (that would be frozen in Debian stable) and data (that could be
> updated as needed). However, some logic that needs to be updated from
> time to time (e.g. alpha/beta detection) lives in the code, so it
> would need to be parameterized (e.g. the corresponding regexp), and
> the paramaters would need to be extracted from the Python code to some
> configuration file that we could put in the data package. It's of
> course too late to do that for Jessie, but it would be good to file
> a request upstream about it so that we don't realize once Stretch is
> frozen that it didn't happen yet :)

Given the above and the nature of the package (it's tiny and has a single 
purpose) I'm not sure its worth the effort. Also I hope that it will become 
more stable in the next two years :-)


cheers,
	Holger


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.alioth.debian.org/mailman/private/pkg-anonymity-tools/attachments/20150121/57cdb42c/attachment.sig>