[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