Re: autoqa-results@ results archive disabled

[Kamil Paral]

>  > This should address the problem in the short term, but
> adjustments
>  > may be needed on to recognize that autoqa-results@ archive no
>  > longer
>  > available.  It seems that the volume+size of autoqa-results@ mails
>  > increased dramatically recently.  I'm not clear why, so that might
>  > be
>  > interesting to diagnose.  This also helps us determine whether
>  > autoqa-results@ is still the best option for long-term test result
>  > storage, or if there are other options worth pursuing.
>  
>  I think it has to do with a change that went in when we did pretty
>  logs.
>  
>  When we started splitting off the results pages for every package in
>  a
>  depcheck or upgradepath result, we started sending emails for those
>  packages, too. 
I counted the results from 28th October:
https://fedorahosted.org/pipermail/autoqa-results/20110928/thread.html

Total: 11523 emails

The number of emails per test is:
   3745 rpmguard
   3743 rpmlint
   3718 upgradepath
    280 depcheck
     12 rats_sanity
     11 repoclosure
      6 conflicts
      4 anaconda_storage
      4 rats_install

I also counted .fcNN patterns:
   6183 fc16
   3331 fc17
   1270 fc15
    537 fc14

rpmlint and rpmguard numbers are basically doubled regarding to tests actually run,
because for every test run we send a pretty log link and a full log output (2 emails).

Upgradepath and depcheck send emails for every update in the currently pending set. The
reason for the high amount of upgradepath emails is that depcheck uses "previously
accepted updates" concept and doesn't send emails for those (confirmation needed,
but I believe my guess is pretty close). Upgradepath always checks all the pending updates
and always reports about all of them (and the bodhi library ensures duplicates removal).

>  
>  The net result is that we started sending one email per pacakge in a
>  depcheck run in addition to the email for every run. Personally, I
>  think that the email volume has gotten a little out of hand and would
>  like to see it toned down a bit. I was actually having problems with
>  my
>  email clients (couldn't view entire folder, couldn't delete messages
>  from it) when I forgot to clean out my autoqa-results folder for a
>  while.
>  
>  I don't think that it would be too hard to patch autoqa back to its
>  pre-split volume if there are no objections. 
I think we have multiple (non-exclusive) options:
1. keep emails disabled and wait for resultsdb (work, josef, work!)
  - not fully optimal, we won't detect crashed tests
2. disable pretty log link sending for rpmlint+rpmguard, that will save half of their
emails
  - but please remember that in case of some mass rebuild in f16 or f17 we will be flooded
anyway
3. disable rawhide (fc17) checking for rpmling+rpmguard
  - it also saves a lot of emails and is not used much (probably?)
4. don't send per-item results for depcheck+upgradepath
  - that will save considerable fraction of emails

The options may be combined.

Ideas?