1 |
On Thu, Nov 3, 2016 at 9:45 AM, Ian Stakenvicius <axs@g.o> wrote: |
2 |
> |
3 |
> |
4 |
> Although metadata.xml is one way to do this, since it is more of a social thing than a technical one I think it might be better to wikify it instead -- each dev can list their "please fix my package" preferences in a per package or per anything-with-them-as-maintainer spec in one location. |
5 |
> |
6 |
|
7 |
I tend to think that metadata is the right place for a couple of reasons: |
8 |
|
9 |
1. Somebody who discovers an ebuild with an issue/etc is probably |
10 |
sitting right in the directory with the metadata file, so the |
11 |
information is readily at hand. |
12 |
2. If somebody was going to have to reach out to the maintainer, the |
13 |
metadata file would tell them who the maintainer is (both in terms of |
14 |
projects and individuals). |
15 |
3. The file could potentially contain package-specific maintenance |
16 |
information. Sure, you can stick a page on a wiki that says "for |
17 |
rich0 in general feel free to touch anything, but be aware that mythtv |
18 |
upstream is picky about xyz, and be aware that the android sdk has |
19 |
issue xyz, ..." For somebody with their fingers on a lot of packages |
20 |
you could end up either writing a book, or just leaving it all out |
21 |
which could result in people making the same mistakes over and over, |
22 |
or devs might just opt out of having others touch their stuff because |
23 |
it is too much of a PITA to explain it all. With the metadata |
24 |
approach you only define package-level detail. So, if one package is |
25 |
hands-off, then you simply state so or fail to give permission to |
26 |
touch it. You could provide other background that is relevant to the |
27 |
specific package. |
28 |
|
29 |
I think the main issue is where to put it in the schema. For the |
30 |
proponents I'd suggest just putting a stick in the mud and see if |
31 |
anybody complains. |
32 |
|
33 |
-- |
34 |
Rich |