| 1 |
On Thu, Sep 17, 2015 at 7:20 AM, Anthony G. Basile <blueness@g.o> wrote: |
| 2 |
> On 9/17/15 7:05 AM, James Le Cuirot wrote: |
| 3 |
>> |
| 4 |
>> On Thu, 17 Sep 2015 06:57:08 -0400 |
| 5 |
>> "Anthony G. Basile" <blueness@g.o> wrote: |
| 6 |
>> |
| 7 |
>>> Totally rethink the idea of emails aliases as something that is |
| 8 |
>>> created on the fly. We just need to know who should get emails for a |
| 9 |
>>> package when it comes to bug reports. Why can't that be calculated |
| 10 |
>>> on the fly from the metadata.xml? |
| 11 |
>> |
| 12 |
>> I've not read every last part of this thread but I think I like where |
| 13 |
>> this is going. I just want to be sure that people besides those in the |
| 14 |
>> Java herd/project/whatever can continue to receive emails for |
| 15 |
>> java@g.o. For instance, gnu_andrew is not a dev and does not |
| 16 |
>> intend to be but he still likes to be CC'd on all Java mail. I would |
| 17 |
>> not like to have to add his address to the metadata.xml of every Java |
| 18 |
>> package. |
| 19 |
>> |
| 20 |
> Yes. If the metadata.xml contained both <project> and <maintainer> tags, |
| 21 |
> it would go to all of java@g.o and to gnu_andrew. Already not all |
| 22 |
> <maintainers> are devs. |
| 23 |
> |
| 24 |
|
| 25 |
Can you clarify where you intend to stick gnu_andrew? I think the |
| 26 |
concern was NOT listing him as a maintainer on every java package, but |
| 27 |
allowing him to still get mail. |
| 28 |
|
| 29 |
I think there are a few levels of indirection involved in your proposal. |
| 30 |
|
| 31 |
Packages have entities who are interested, who can be projects, |
| 32 |
maintainers, and observers. |
| 33 |
Projects have members and observers. |
| 34 |
|
| 35 |
It sounds like your proposal is basically that every package gets an |
| 36 |
email alias, and every project gets an email alias, and they're all |
| 37 |
dynamically populated based on both project member/observership and |
| 38 |
package metadata. A package alias may very well end up including one |
| 39 |
or more project aliases. |
| 40 |
|
| 41 |
Example. Bug logged against media-tv/mythtv |
| 42 |
Bugzilla assigns to and emails to media-tv/mythtv@×.org |
| 43 |
Email to media-tv/mythtv@×.org goes to mythtv@×.org, which goes to |
| 44 |
cardoe,rich0@g.o. |
| 45 |
|
| 46 |
Another bug gets logged against media-plugins/mythplugins |
| 47 |
Bugzilla assigns to and emails to media-plugins/mythplugins@×.org |
| 48 |
Email to media-plugins/mythplugins@×.org goes to mythtv@×.org, which |
| 49 |
goes to cardoe,rich0@g.o. |
| 50 |
|
| 51 |
Was that what you were getting at? The obvious concern is whether |
| 52 |
there is an issue with all those dyanically-created/destroyed bugzilla |
| 53 |
and email accounts. |
| 54 |
|
| 55 |
If you were hoping to cut out a layer I'm not sure that you'd be able |
| 56 |
to as easily accommodate cases where both the project and the package |
| 57 |
both have multiple email addresses listed. However, I guess you could |
| 58 |
just have bugzilla assign the first project it sees and if not the |
| 59 |
first member and if not the first observer and then CC everybody else, |
| 60 |
and then any projects or observers in the list could be email aliases. |
| 61 |
That is closer to what we're doing today. |
| 62 |
|
| 63 |
-- |
| 64 |
Rich |
Archives