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