| 1 |
On Sat, 2004-10-09 at 10:29 -0400, Ned Ludd wrote: |
| 2 |
> Do you see the irony is this situation? |
| 3 |
> a) "A maintainer does not need to be part of the (2nd) maintaining |
| 4 |
> herd." |
| 5 |
> b) "you cannot assign something without consent ever" |
| 6 |
> c) "Not adding metadata is against policy" |
| 7 |
> d) this is quoting from the skel.metadata.xml |
| 8 |
> "herd is a required subelement." |
| 9 |
> |
| 10 |
> if a, b, c and d cant be met for whatever reason then "no-herd" would be |
| 11 |
> the appropriate choice. It's already the default in the skel so I'm not |
| 12 |
> actually proposing anything new here. |
| 13 |
|
| 14 |
Why can't a, b & c be met ? They can always be met if you put the effort |
| 15 |
in. |
| 16 |
|
| 17 |
> I like this option of using $CATEGORY. I would happily use it if |
| 18 |
> somebody else (you?) with the motivation to gets everything created to |
| 19 |
> meet these requirements and formalizes this into a standard. |
| 20 |
|
| 21 |
herds based on categories are not a good idea most of the time, there is |
| 22 |
no common ground, especially if you talk about *-misc categories. If |
| 23 |
something falls back to a herd where everyone has a 'role' to only take |
| 24 |
care of a specific pack in the end nothing gets done about packages |
| 25 |
outside of that scope, I even think there already examples of herds |
| 26 |
where this happened. |
| 27 |
|
| 28 |
- foser |
Archives