Re: [Tails-dev] Releasing automated tests

[sajolida]

anonym:
> sajolida:
>> anonym:
>>> [Moving discussion to tails-dev@]
>>
>> Meta: I really don't want to understand everything that's in this email
>> but I felt you would want me to answer this one. But if you think that
>> you can have this discussion without me I would be super happy as well.
> 
> I believe you have answered the question that was (mostly) directed to
> you, but you also added an interesting idea, so... :)
> 
>>> Given the trimming that has happened, some context may have been lost.
>>> The discussion is about that we now, in our Jenkins setup, automatically
>>> test images built from doc/ and web/ branches, which wastes a lot of
>>> time on our isotesters.
>>>
 From: intrigeri 
 Date: Tue, 20 Oct 2015 13:08:31 +0200

> From: bertagaz 
> Date: Mon, 19 Oct 2015 12:29:26 +0200

>> From: anonym 
>
>> Still, once we release 1.7, then all doc/ and web/ branches will become
>> tested. I suspect we will need a permanent fix for only building (not
>> testing) these branches -- it's useless to test them 99.9% of the time,
>> and they will block (for ~5 hours) test runs from relevant branches that
>> got something pushed to them right after them.

> That's something we didn't decide when during the design round. Sounds
> doable, but I wonder if there are still some valid points to still test
> that branches.
>>>
>>> True, but there's an overwhelming amount of them, and their
>>> modifications are limited to something that is completely isolated from
>>> most of Tails, the OS, meaning that a huge part of each test run on them
>>> is just a (possibly out-dated) re-run of master/devel/stable depending
>>> on which branch it was based on. That is unlike feature/, bugfix/ and
>>> test/ branches, that need a full run in general. Perhaps you can see
>>> where I'm going:
>>>
>>> As an optimization, we could introduce @web and @doc tags, and run the
>>> test suite with `--tag @web` or `--tag @doc` for doc/ and web/ branches,
>>> respectively. Then we could even have automated tests of @web changes
>>> before deploying them by browsing the local wiki in Tails. :)
>>>
>>> Note that I may not have the correct understanding of the doc/ vs web/
>>> distinction, so I'd like a clarification just in case so we don't design
>>> something stupid. I suspect that since we don't have any automated tests
>>> for the *website* (as opposed to the docs) we only care about doc/ and
>>> only need to test web/ if we want to start testing the website.
>>>
 FTR I dislike the idea of blacklisting such branches based on their
 name. I'm not going to debate it here [...]
>>
>> The prefixes doc/ and web/ are used loosely to differentiate work on the
>> "documentation" (/doc /support) and the "website" in general (structure,
>> stuff not in /doc, etc.) but the difference is not strict.
> 
> ACK, as I expected, than.
> 
>> I also don't think they should be tested. Maybe you could exclude them
>> from testing by their diff to their base branch. If all the diff is
>> under wiki/src then don't test that branch.
> 
> I guess you mean the diff against the base branch (but base branches
> themselves would *always* build, of course). Hm. Technically we'd have
> to do something slightly different since a `git diff` would show changes
> in the base branch since the point they diverged. We'd have to look at
> all files touches in `git log $base_branch..` or something like that.
> It's an interesting approach, which I think I like.

Did you took into account the '...' (THREE DOTS) operator which is
slightly different than '..' and I *think* might be helpful here to diff
only the changes that happened on this branch. I'm not sure what it does
exactly (couldn't understand the man page).

 [...] making sure that the workaround is not worst than the problem
 it fixes
>>>
>>> The only effect should be that we won't get automated tests of the few
>>> scenarios that looks at the wiki shipped inside Tails. [...]
>>
>> Agreed. If I understand correctly, these scenarios have a *dependency*
>> on what is on the local copy of the website, but they are actually
>> testing the Tails software (the "Report an Error" launcher for example).
> 
> Correct so far.
> 
>> They are not testing the content of the local copy of the website itself.
> 
> Actually, they *are* testing the content of the local copy, e.g. that
> the support page is properly localized. Hence there could be a subset of
> automated tests that would make sense to run for doc/ and web/ branches.

I didn't know that, sorry!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [PATCH] Fix "persitent" typo in news/test_1.7-rc1.mdwn

[sajolida]

junglefowl:
> Change persitent to persistent.
> ---
>  wiki/src/news/test_1.7-rc1.de.po |2 +-
>  wiki/src/news/test_1.7-rc1.fr.po |2 +-
>  wiki/src/news/test_1.7-rc1.mdwn  |2 +-
>  wiki/src/news/test_1.7-rc1.pt.po |2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/wiki/src/news/test_1.7-rc1.de.po 
> b/wiki/src/news/test_1.7-rc1.de.po
> index c00b959..a8f7858 100644
> --- a/wiki/src/news/test_1.7-rc1.mdwn
> +++ b/wiki/src/news/test_1.7-rc1.mdwn
> @@ -71,7 +71,7 @@ Changes since Tails 1.6 are:
>  - Add a technology preview of the Icedove Email client (a
>rebranded version of Mozilla Thunderbird), including OpenPGP
>support via the Enigmail add-on, general security and anonymity
> -  improvements via the Torbirdy add-on, and complete persitence
> +  improvements via the Torbirdy add-on, and complete persistence
>support (which will be enabled automatically if you already have
>Claws Mail persistence enabled). Icedove will replace Claws Mail
>as the supported email client in Tails in a future
> diff --git a/wiki/src/news/test_1.7-rc1.pt.po 
> b/wiki/src/news/test_1.7-rc1.pt.po
> index c00b959..a8f7858 100644

Applied, thanks!
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Reverting defacement on blueprint

[sajolida]

Jesse W:
> The defacement is listed as being authored by localhost (127.0.0.1@web),
> which has 13,538 commits attributed to it, although all but 2,288 of
> them point to the same tree as their parent (i.e. they contain no actual
> change).

All these commits are the ones done through the web interface for
editing the website. So that's expected to have so many of them.

> Of the ones with changes, they all are in the wiki, and were
> authored between 2009 and now (distribution by year below). All but 16
> were committed by webmas...@amnesia.boum.org (the other 16, committed
> between Oct 2010 and Nov 2011, were committed by amne...@boum.org ).
> 
> There have been **41** commits with the same log message as the
> defacement (2rand[0,1,1]) going back to July 2011, although there hasn't
> been one since 2012 (aside from the one sajolida found). They are all
> spam.

Thanks for looking into this. I didn't remember "2rand[0,1,1]" as a
common commit title for spam and thought that maybe this was some intent
of by passing input validation or something.

> I didn't know we accept anonymous edits to the wiki -- it is certainly
> not documented anywhere I've seen...

As intrigeri pointed out, right now it's only possible to edit
/blueprint/. Some years ago, it was possible to edit all the whole
website :)

> git log --author '<127.0.0.1@web>' --pretty=format:'%ai' wiki/ | cut -c
> '1-4' | sort | uniq -c  
> 116 2009
> 111 2010
> 781 2011
> 650 2012
> 152 2013
>  41 2014
> 437 2015
> 
>> On Mon, 2015-10-26 at 12:42 +, sajolida wrote:
>>> Today while fetching from origin I had to revert a defacement on a
>>> blueprint. See b2b585b and 19a3de4.
>>>
>>> If anybody wants to investigate this further...
>>
> intrigeri:
>
> What do you think could/should be investigated?

I didn't remember the "2rand[0,1,1]" as common for spam and thought
maybe this time it was more than spam. I didn't dare opening the URL :)

Case closed for me.
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] [PATCH] Fix "persitent" typo in news/test_1.7-rc1.mdwn

[elouann]

Hi junglefowl,

junglefowl  :

> Change persitent to persistent.
> [...]

Thanks a lot for your patch,
I'll take care of that today.

Cheers,
~ elouann


signature.asc
Description: PGP signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Releasing automated tests

[anonym]

sajolida:
> anonym:
>> sajolida:
>>> anonym:
 [Moving discussion to tails-dev@]
>>>
>>> Meta: I really don't want to understand everything that's in this email
>>> but I felt you would want me to answer this one. But if you think that
>>> you can have this discussion without me I would be super happy as well.
>>
>> I believe you have answered the question that was (mostly) directed to
>> you, but you also added an interesting idea, so... :)
>>
 Given the trimming that has happened, some context may have been lost.
 The discussion is about that we now, in our Jenkins setup, automatically
 test images built from doc/ and web/ branches, which wastes a lot of
 time on our isotesters.

> From: intrigeri 
> Date: Tue, 20 Oct 2015 13:08:31 +0200
>
>> From: bertagaz 
>> Date: Mon, 19 Oct 2015 12:29:26 +0200
>
>>> From: anonym 
>>
>>> Still, once we release 1.7, then all doc/ and web/ branches will become
>>> tested. I suspect we will need a permanent fix for only building (not
>>> testing) these branches -- it's useless to test them 99.9% of the time,
>>> and they will block (for ~5 hours) test runs from relevant branches that
>>> got something pushed to them right after them.
>
>> That's something we didn't decide when during the design round. Sounds
>> doable, but I wonder if there are still some valid points to still test
>> that branches.

 True, but there's an overwhelming amount of them, and their
 modifications are limited to something that is completely isolated from
 most of Tails, the OS, meaning that a huge part of each test run on them
 is just a (possibly out-dated) re-run of master/devel/stable depending
 on which branch it was based on. That is unlike feature/, bugfix/ and
 test/ branches, that need a full run in general. Perhaps you can see
 where I'm going:

 As an optimization, we could introduce @web and @doc tags, and run the
 test suite with `--tag @web` or `--tag @doc` for doc/ and web/ branches,
 respectively. Then we could even have automated tests of @web changes
 before deploying them by browsing the local wiki in Tails. :)

 Note that I may not have the correct understanding of the doc/ vs web/
 distinction, so I'd like a clarification just in case so we don't design
 something stupid. I suspect that since we don't have any automated tests
 for the *website* (as opposed to the docs) we only care about doc/ and
 only need to test web/ if we want to start testing the website.

> FTR I dislike the idea of blacklisting such branches based on their
> name. I'm not going to debate it here [...]
>>>
>>> The prefixes doc/ and web/ are used loosely to differentiate work on the
>>> "documentation" (/doc /support) and the "website" in general (structure,
>>> stuff not in /doc, etc.) but the difference is not strict.
>>
>> ACK, as I expected, than.
>>
>>> I also don't think they should be tested. Maybe you could exclude them
>>> from testing by their diff to their base branch. If all the diff is
>>> under wiki/src then don't test that branch.
>>
>> I guess you mean the diff against the base branch (but base branches
>> themselves would *always* build, of course). Hm. Technically we'd have
>> to do something slightly different since a `git diff` would show changes
>> in the base branch since the point they diverged. We'd have to look at
>> all files touches in `git log $base_branch..` or something like that.
>> It's an interesting approach, which I think I like.
> 
> Did you took into account the '...' (THREE DOTS) operator which is
> slightly different than '..' and I *think* might be helpful here to diff
> only the changes that happened on this branch. I'm not sure what it does
> exactly (couldn't understand the man page).

Neat! That's is a very useful Git feature. Thanks for letting me know
about it!

Then I think we can combine the "..." operator with another fancy Git
feature I recently found, namely Git pathspec "magic signatures". So we
could do:

   BASE_BRANCH_DIFF="$(git diff $base_branch...$commit  -- \
   '*' \
   ':!/wiki' \
   ':!/ikiwiki.setup' \
   ':!/ikiwiki-cgi.setup')"
   if [ -z "${BASE_BRANCH_DIFF}" ]; then
   CUCUMBER_ARGS="${CUCUMBER_ARGS} --tag @doc"
   fi

where $commit is the commit we test, before merging the base branch
locally. Interesting!

Cheers!

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] [review] Rescue translation and fix typo

[elouann]

Hi all,

Could anyone review & merge from elouann/master?

The commit 066a078 is meant to rescue the french translation, when
9b067e3 fixes a typo

Thank you,
~ elouann


signature.asc
Description: PGP signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

Re: [Tails-dev] Fix "persitent" typo in news/test_1.7-rc1.mdwn

[elouann]

Hi sajolida,

sajolida  :

> junglefowl:
> > Change persitent to persistent.
> [...]
> Applied, thanks!

Thanks for taking care of that, you're definitively too fast!

~ elouann


signature.asc
Description: PGP signature
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.

[Tails-dev] Releasing automated tests

[Spencer]

Hi,



anonym:
Neat! That's is a very useful Git feature. Thanks for letting me know
about it!

Then I think we can combine the "..." operator with another fancy Git
feature I recently found, namely Git pathspec "magic signatures". So we
could do:

   BASE_BRANCH_DIFF="$(git diff $base_branch...$commit  -- \
   '*' \
   ':!/wiki' \
   ':!/ikiwiki.setup' \
   ':!/ikiwiki-cgi.setup')"
   if [ -z "${BASE_BRANCH_DIFF}" ]; then
   CUCUMBER_ARGS="${CUCUMBER_ARGS} --tag @doc"
   fi

where $commit is the commit we test, before merging the base branch
locally. Interesting!



I don't understand this at all!

Don't mind me :)

Wordlife,
Spencer

___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to 
tails-dev-unsubscr...@boum.org.