| 1 |
On Fri, 2004-10-08 at 20:53, George Shapovalov wrote: |
| 2 |
> To ease off foser's comments I'll throw a few more words :). |
| 3 |
> |
| 4 |
> First I'd like to state that *personally* (emphasis to avoid accusations that |
| 5 |
> I am forcing non-existant policy ;)) I am against "registering" no-herd in |
| 6 |
> herds.xml. This does not bring us any close to the accountability which is a |
| 7 |
> primary goal of all this metadata introduction, but rather makes this |
| 8 |
> temporary "solution" more permanent (not like its too transient atm :)). |
| 9 |
> However unfortunately not every situation can be easily resolved, but I'd |
| 10 |
> rather have us come up with some better solution.. |
| 11 |
> |
| 12 |
> Ok, condensing your message I see you mentioned two situations where you feel |
| 13 |
> no-herd is necessary: |
| 14 |
> > when an ebuild does not fit into any existing herds or when a |
| 15 |
> > maintainer is not apart of what would perhaps be a fitting herd. |
| 16 |
> |
| 17 |
> While 1st situation is truly unaccounted for and gives the most trouble, the |
| 18 |
> 2nd one is covered and was specifically discussed (back all that time). In |
| 19 |
> this case (package belongs to some herd but has a maintainer not willing to |
| 20 |
> be in that herd) metadata.xml is supposed to list this herd and have a |
| 21 |
> separate maintainer entry for this dev who, in turn, would not be listed in |
| 22 |
> that particular herd in herds.xml. Bug wranglers are supposed then to assign |
| 23 |
> all package-related bugs to this maintainer and (may be optionally, I am not |
| 24 |
> totally sure on this one) CC the herd alias. |
| 25 |
> |
| 26 |
> As foser pointed out, if the package is not yet added to this herd this should |
| 27 |
> first be discussed with that herd maintainers. Since we are talking about a |
| 28 |
> situation when this package conceptually falls into the corresponding |
| 29 |
> category, herd devs shouldn't be opposed with the understanding that the |
| 30 |
> proposing dev will serve as its maintainer (and bug-wrangling happens as |
| 31 |
> described). |
| 32 |
> |
| 33 |
|
| 34 |
Do you see the irony is this situation? |
| 35 |
a) "A maintainer does not need to be part of the (2nd) maintaining |
| 36 |
herd." |
| 37 |
b) "you cannot assign something without consent ever" |
| 38 |
c) "Not adding metadata is against policy" |
| 39 |
d) this is quoting from the skel.metadata.xml |
| 40 |
"herd is a required subelement." |
| 41 |
|
| 42 |
if a, b, c and d cant be met for whatever reason then "no-herd" would be |
| 43 |
the appropriate choice. It's already the default in the skel so I'm not |
| 44 |
actually proposing anything new here. |
| 45 |
|
| 46 |
|
| 47 |
> Actually, the 1st situation might be attacked by introducing some more generic |
| 48 |
> herd (e.g. x11-misc, just follow the categories) and individual devs list |
| 49 |
> themselves in herds.xml with a <role> clause or just have a single fall-back |
| 50 |
> person and add themselves to individual metadata.xml's as maintainers. The |
| 51 |
> utility of this approach is limited to some basic accountability and I |
| 52 |
> realise it may be hard to sign-up people to such groups. But that's at least |
| 53 |
> an attempt :). May be somebody would have a better idea on how to cover such |
| 54 |
> situation (not involving a non-existant herd and thus dropping any hope to |
| 55 |
> get a fall-back coverage)? |
| 56 |
|
| 57 |
I like this option of using $CATEGORY. I would happily use it if |
| 58 |
somebody else (you?) with the motivation to gets everything created to |
| 59 |
meet these requirements and formalizes this into a standard. |
| 60 |
|
| 61 |
> |
| 62 |
> George |
| 63 |
> |
| 64 |
> |
| 65 |
> -- |
| 66 |
> gentoo-dev@g.o mailing list |
| 67 |
-- |
| 68 |
Ned Ludd <solar@g.o> |
| 69 |
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer |
Archives