[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian derivatives census: subscription system

Hi Anastasia,

Anastasia Tsikoza:
> As part of the Outreachy project we are going to implement a
> subscription system for error notifications produced by derivatives. 

Great! Thanks for working on this :)

> If you are going to sign up for a subscription, please tell us, what
> error output you consider useful and whether you would like to receive
> the emails regularly or after some specific event (like if the new
> check-* file differs from the old). 

I would happily subscribe to the Tails errors/warnings if:

 - They bring enough information to be actionable (for example, I have
   no idea what to do with "mismatched source packages in
   Sources/Packages"; which are the faulty packages?). Fixing them all
   now in not a prerequisite IMO, as long as someone is ready to fix
   them incrementally when reported by subscribers once the
   notifications are in place.

 - The notifications are sent in a way such as I won't quickly and
   unconsciously learn to ignore them all.

   I would like to be notified when check results change. A basic
   home-made implementation might be OK as a proof of concept but on
   the long term, I am pretty sure it'll be insufficient: keeping the
   signal/noise ratio high for monitoring checks is not a trivial
   problem. Thankfully, we have good monitoring systems available with
   the needed features to solve it, e.g. flapping detection and
   notifying only after N successive failures. So I humbly suggest
   plugging the checks into one such existing monitoring system
   instead of writing a new one from scratch.

   On top of that, I wouldn't mind a reminder sent 1-4 times a year
   about the unchanged, still pending issues; but that's not necessary
   if the whole thing is exposed to me via a monitoring system's
   web dashboard.

   An Lintian-like override mechanism and output ("here are the
   non-overriden errors, oh and by the way you're also overriding
   N other ones") would be nice but probably vastly overkill at
   this stage.


Reply to: