On Wed, Sep 10, 2014 at 10:18 AM, Michał Górny <mgo...@gentoo.org> wrote: > Dnia 2014-09-10, o godz. 07:53:31 > Rich Freeman <ri...@gentoo.org> napisał(a): > >> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos <pa...@gentoo.org> wrote: >> > >> > Personally I would vote for simply have a <maintainer> tag pointing to >> > the alias but we would still need to keep a list of real maintainers for >> > that alias as usually not all people listed in the alias are willing to >> > maintain the packages. >> > >> >> I think the solution to this is that maintainers can be either: >> 1. Devs - identified by their email address. (simple enough) >> or >> 2. Projects - identified by their email alias. >> or >> 3. A proxy maintainer identified by email address (in which case >> either a dev or project must also be listed, potentially including the >> proxy maintainer project). > > 4. A mail alias that is not project :). For example, we have clang@ for > easily aggregating all clang-related build failures and other bugs but > it isn't a formal team. > > It's hard if such a thing has proper member list. But in any case, is > there a reason for needing to have definitive member list?
I don't think we should allow #4 in the absence of #1-2, because mail aliases shouldn't be maintainers. What #4 says is "I'd like to know what is going on with a package, but don't look at me if it breaks." The challenge is that people are going to fail to distinguish between these aliases and ones that belong to projects, because they look the same. Why should we have a clang email alias if there isn't a clang project? Why not just make it into a project? It sounds like you have a bunch of devs who want to stay on top of clang so that it is well-supported in the tree, and that is basically the definition of a project. You don't need to have meetings, agendas, minutes, and bylaws to be a project - just a common purpose. I'm not opposed to finding better ways to keep people informed. I just don't want to equate a desire to be informed with a commitment to maintain something - which we've already identified as a problem. Also, you spoke about clang-related build failures. You probably wouldn't be tagging packages with that alias in that case - you'd just have it as a CC alias on bugs. You're more interested in specific bugs than specific packages. -- Rich
