| 1 |
On Sun, Feb 14, 2016 at 6:37 AM, Patrick Lauer <patrick@g.o> wrote: |
| 2 |
> |
| 3 |
> The new schema collapses herd (err, project!) into maintainers (err, |
| 4 |
> sustainers ... staff ... linchpin?) |
| 5 |
> And maintainer is defined as: |
| 6 |
> <!ELEMENT maintainer ( email, (description| name)* )> |
| 7 |
> |
| 8 |
> Which means that only email is mandatory. So instead of search by name |
| 9 |
> you are now required to search by email. |
| 10 |
> And it leads to inconsistent (partial) duplication: Some metadata.xml |
| 11 |
> entries carry Name, some Description, and some are Email only. |
| 12 |
> |
| 13 |
> For example for gentoolkit this means that instead of search by name now |
| 14 |
> it needs to be search by email, and the previous search by name |
| 15 |
> functionality requires herds.xml, err, projects.xml to figure out the |
| 16 |
> name of a project. Which might not match the one in metadata.xml! |
| 17 |
|
| 18 |
This is all correct and intentional. I actually didn't care for |
| 19 |
having the name in metadata.xml for exactly that reason, but the |
| 20 |
intent of having it there (and optional) was to make the file more |
| 21 |
human-readable. Tools that intend to search by name should obtain the |
| 22 |
name from the authoritative source (ultimately the Wiki, but mirrored |
| 23 |
in projects.xml). |
| 24 |
|
| 25 |
If we made metadata.xml the source of project names then your search |
| 26 |
would break anytime a maintainer spells a name differently. If we |
| 27 |
imagine building a bunch of tools to prevent this from happening, we |
| 28 |
might as well build a bunch of tools that just references the name |
| 29 |
from projects.xml (which is what they'd have to do to prevent the |
| 30 |
breakage anyway). |
| 31 |
|
| 32 |
Feel free to peruse the various list discussions and council logs. |
| 33 |
Most of what you're bringing up has come up before. |
| 34 |
|
| 35 |
-- |
| 36 |
Rich |
Archives