[Pkg-privacy-maintainers] Bug#824460: testing using alpha versions?

georg at riseup.net georg at riseup.net
Mon May 23 10:02:20 UTC 2016


On 16-05-22 15:45:48, intrigeri wrote:
> Holger Levsen wrote (22 May 2016 12:52:46 GMT) :
> > as I tried to say above: the problem is, an update arrives, and people
> > update their system. After this the update cannot be tested anymore (as
> > people are understandably not really willing to go back to a backed up
> > state and retest again).
> 
> I suspect that Georg had automated testing in mind, so what *people*
> are ready to do or not doesn't matter this much. E.g. an automated
> test could keep around copies of ~/.local/share/torbrowser/, restore
> the one corresponding to the previous Tor Browser release, and test
> the update to the last version as Georg described, right? (no,
> I didn't volunteer :)

*people* and *automated* are keywords...so, yes, I proposed to set up
automated tests. Either like intrigeri described, aka keeping copies of
~/.local/share/torbrowser/, or, maybe easier to achieve, for each test
create a new virtual machine or use an existing one (or one, just set up
for this task), and delete ~/.local/share/torbrowser/ and
~/.config/torbrowser/ before or after the test. This way, in case I'm
not overlooking something, it would be possible to do the tests without
relying on alpha releases. 

I guess, it would make sense, to create an environment which mimics the
environments of the "normal users", aka no alpha releases, if I'm not
mistaken.

If this sounds like a possible way to go in your ears, I could write /
set up a proof of concept. (But we would have to decide first roughly
how this should look like / how this should work.)

Notes: 

- I proposed this way to test apparmor profiles etc, which doesn't
  necessarily check for a smooth upgrade path between different
  versions. If we would like to do this as well, we would indeed have
  to keep copies of ~/.local/share/torbrowser/ (and
  ~/.config/torbrowser/ ?) like intrigeri described.

- Even if one would test using alpha versions, there would have to be a
  way to do this multiple times in a row, which would mean, as far as I
  understand the things currently, having some sort of deleting /
  restoring the directories and running the update(s) again.

Cheers,
Georg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/attachments/20160523/9dd5e444/attachment.sig>


More information about the Pkg-privacy-maintainers mailing list