| 1 |
On 12/27/05, John Myers <electronerd@×××××××××××××.net> wrote: |
| 2 |
> What if upstream is more than one person, but less than an organization? What |
| 3 |
> if there is more than one upstream such as for gentoo-sources, where the |
| 4 |
> maintainer of each of the patchsets could be considered an upstream? |
| 5 |
|
| 6 |
I don't see a problem with having multiple "name" and "email" fields. |
| 7 |
Perhaps there could be an additional "description" tag to discriminate |
| 8 |
what each person is responsible for. |
| 9 |
|
| 10 |
> if this is to be subject to automated processing, shouldn't there be a |
| 11 |
> registry of valid "type" values maintaining a definition of what the value of |
| 12 |
> the element corresponds to for each type? |
| 13 |
|
| 14 |
Yes. Thus far, I have in mind freshmeat, sourceforge and cpan, but |
| 15 |
other types can be added later. |
| 16 |
|
| 17 |
On 12/27/05, Grobian <grobian@g.o> wrote: |
| 18 |
> The bugs-to tag can hold either an email address or URL. Not a big |
| 19 |
> issue, but why not make it an URI, such that an email address is written |
| 20 |
> as "mailto:foo@×××.bar"? Using an URI gives a nice specified format |
| 21 |
> (already including the http(s) which you require) and should go with |
| 22 |
> regular URI parsers. |
| 23 |
|
| 24 |
Sounds good enough. |
| 25 |
|
| 26 |
> Given the URI thing, maybe it can be useful to define the changelog tag |
| 27 |
> to have an URI as well, since some upstreams ship the changelog with the |
| 28 |
> sources and don't put them on the web. In such case you might want to |
| 29 |
> use a "file://" URI to point to the file on disk when installed? I |
| 30 |
> realise this is tricky. |
| 31 |
|
| 32 |
Hmmm... I'm not sure about this one. Not only is it tricky, but the |
| 33 |
whole point of this GLEP is to facilitate the finding of online |
| 34 |
up-to-date information. If there is no online changelog, I think it |
| 35 |
may be better just to ommit this field. |
| 36 |
|
| 37 |
> What I wanted to say, where is |
| 38 |
> the logic stored on how to make this id into some resource? And if you |
| 39 |
> store that logic somewhere, why not in the XML structure? Any reason to |
| 40 |
> use an id, and not for instance an URI to the remote 'developers' |
| 41 |
> homepage/resource? |
| 42 |
|
| 43 |
Yes, there is a logic. I think it is easier to maintain an external |
| 44 |
list, such as we do with "thirdpartymirrors". The point of listing |
| 45 |
alternative resources is that they may include features not provided |
| 46 |
by upstream itself. For example, an announce list that lets one know |
| 47 |
when a new version has been released. |
| 48 |
|
| 49 |
On 12/27/05, Paul de Vrieze <pauldv@g.o> wrote: |
| 50 |
> What is the reason for having an upstream tag? |
| 51 |
|
| 52 |
Aggregate useful upstream information in one place. |
| 53 |
|
| 54 |
> Wouldn't it be easier to just name the tags properly. |
| 55 |
|
| 56 |
How? |
| 57 |
|
| 58 |
> And what about just using a general attribute tag |
| 59 |
> like <meta name="upstreammaint" value="foo@×××.com"/> |
| 60 |
|
| 61 |
It's not bad, but isn't it better to have it in the structured way we |
| 62 |
suggest? It's graphically easier to read/write. |
| 63 |
|
| 64 |
Cheers! I'll be back the first week of January :-). |
| 65 |
Marcelo |
| 66 |
|
| 67 |
-- |
| 68 |
Marcelo Góes |
| 69 |
marcelogoes@×××××.com |
| 70 |
vanquirius@g.o |
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-dev@g.o mailing list |
Archives