* An administrative mailing list for distribution, let's say "<distro>-changes-admin"
* Overrides changes: We will have a ISSPPH/ISBPPH.reason field and change-override tool will send an email to the admin ML containing a report of the executed action.
* Package Removal: The same ISSPPH/ISBPPH.reason field will be used, remove-package tool will send email as change-override.
* New Package acceptance: queue tool already send email to the <distro>-changes maillisting, should we Bcc the admin ML as well ?
* Build admin actions: it will be part of the build-failure-notification spec, but I'm not sure we should collapse the messages in the admin ML, buildd-failures are supposed to have their own ML.
Apart of small details, we can do this quickly before edgy release, Maybe we should right a small/straightforward specification for this.
Right, let's specify what will be required:
* An administrative mailing list for distribution, let's say "<distro> -changes- admin"
* Overrides changes: We will have a ISSPPH/ ISBPPH. reason field and change-override tool will send an email to the admin ML containing a report of the executed action.
* Package Removal: The same ISSPPH/ ISBPPH. reason field will be used, remove-package tool will send email as change-override.
* New Package acceptance: queue tool already send email to the <distro>-changes maillisting, should we Bcc the admin ML as well ?
* Build admin actions: it will be part of the build-failure- notification spec, but I'm not sure we should collapse the messages in the admin ML, buildd-failures are supposed to have their own ML.
Apart of small details, we can do this quickly before edgy release, Maybe we should right a small/straightf orward specification for this.