| 1 |
On Sunday 04 January 2009, Mike Auty wrote: |
| 2 |
> Jeroen Roovers wrote: |
| 3 |
> > The order ("first maintainer as assignee" or "first maintainer/herd |
| 4 |
> > as assignee") is open to discussion and I think this is the proper |
| 5 |
> > forum to have that discussion. |
| 6 |
> |
| 7 |
> It seems sensible to me. I would've thought that being more specific |
| 8 |
> would surely be better? Splitting them up means those who are mostly |
| 9 |
> in charge of a package see it easily, and it's also then easier to |
| 10 |
> spot packages that only have a herd, rather than them getting lost in |
| 11 |
> all the packages that do have individual maintainers... |
| 12 |
> |
| 13 |
> I've attached a quick patch that should fix up assign.py to add all |
| 14 |
> the herds on the end. Since the order of the second item onwards |
| 15 |
> doesn't matter, all herds are added at the end. If we do need an |
| 16 |
> ordering (like maintainer1, herd1, maintainer2, maintainer3, herd2) |
| 17 |
> then it'll need a more complex patch... |
| 18 |
|
| 19 |
I actually implemented it this way before (only that I had all herds |
| 20 |
with higher priority than all maintainers, which is the reverse of your |
| 21 |
patch). The outcome of the previous discussion for me was that there is |
| 22 |
no real consent on who should be the assignee. Robin put it this way: |
| 23 |
|
| 24 |
On Sunday 19 October 2008, Robin H. Johnson wrote: |
| 25 |
> As an addenda, from v1, different teams and developers DO want |
| 26 |
> different behaviors: |
| 27 |
> 1. Assign to herd, CC all others (eg: GNOME, base-system) |
| 28 |
> 2. Assign to first maintainer, CC herd and others (eg: net-mail) |
| 29 |
> |
| 30 |
> That was deliberately why I had logic about using the order in the |
| 31 |
> metadata.xml file, with the addition that later duplicate entries of |
| 32 |
> an email would override the first one. |
| 33 |
> |
| 34 |
> Your generic rule of (assign to first non-herd maintainer, CC rest) |
| 35 |
> doesn't fit all of the cases. |
| 36 |
|
| 37 |
Accepting the fact that different teams have different preferences, we |
| 38 |
need to find a solution for them to set theirs individually. This could |
| 39 |
either be the order of elements in metadata.xml (and would set the |
| 40 |
preference on a per-package basis) or some attribute in herds.xml |
| 41 |
(which would be a global setting per herd, and we'd need to find a |
| 42 |
default). |
| 43 |
|
| 44 |
|
| 45 |
Robert |
Archives