Philip Brown wrote on 21.01.2010 18:46: > On Wed, Jan 20, 2010 at 3:51 PM, Sebastian Kayser <[email protected]> wrote: >> Philip Brown wrote on 20.01.2010 22:30: >>> On Wed, Jan 20, 2010 at 11:09 AM, James Lee <[email protected]> wrote: >>>> We could also have several people receiving the emails in the case >>>> of a maintainer team - or a mailing list. >>> Hrrrm.. I can ALMOST visualize supporting MULTIPLE email addrs in the >>> EMAIL= field of pkginfo. mantis DOES support having multiple people as >>> manager of a package. >> No ... please. Let's eventually de-couple our meta information handling >> from the bug handling in Mantis - not work it even more deeper into it. >> > > One way or another, we need "one central, official place to record who > 'owns' a package". It makes sense that it be a database.
One central database, totally agreed. > Since we ALREADY have a database that keeps track of that sort of > thing.. the mantis database... and that information MUST be kept > current there.... it doesn't make sense, from the standpoint of "good > information management practices" to make another separate database. > It would require even more synchronization between things. > Simpler is better. Currently I can't just grant every maintainer global maintainer privileges for easier bug handling in Mantis as it will break the package assignments which are (as of today) also tracked by using the privilege levels in Mantis. In other words, we are at a latent risk of possible meta data breakage because of things gone wrong in a 3rd party bug handling tool. When thinking about a dedicated CSW meta database and Mantis, the only synchronization required that comes to my mind would be a sync of maintainers to the list of people with global maintainer privileges in Mantis (except for the couple of Mantis admin users). Doesn't sound hard to me. Sebastian _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
