On 12/27/05, John Myers <[EMAIL PROTECTED]> wrote: > What if upstream is more than one person, but less than an organization? What > if there is more than one upstream such as for gentoo-sources, where the > maintainer of each of the patchsets could be considered an upstream?
I don't see a problem with having multiple "name" and "email" fields. Perhaps there could be an additional "description" tag to discriminate what each person is responsible for. > if this is to be subject to automated processing, shouldn't there be a > registry of valid "type" values maintaining a definition of what the value of > the element corresponds to for each type? Yes. Thus far, I have in mind freshmeat, sourceforge and cpan, but other types can be added later. On 12/27/05, Grobian <[EMAIL PROTECTED]> wrote: > The bugs-to tag can hold either an email address or URL. Not a big > issue, but why not make it an URI, such that an email address is written > as "mailto:[EMAIL PROTECTED]"? Using an URI gives a nice specified format > (already including the http(s) which you require) and should go with > regular URI parsers. Sounds good enough. > Given the URI thing, maybe it can be useful to define the changelog tag > to have an URI as well, since some upstreams ship the changelog with the > sources and don't put them on the web. In such case you might want to > use a "file://" URI to point to the file on disk when installed? I > realise this is tricky. Hmmm... I'm not sure about this one. Not only is it tricky, but the whole point of this GLEP is to facilitate the finding of online up-to-date information. If there is no online changelog, I think it may be better just to ommit this field. > What I wanted to say, where is > the logic stored on how to make this id into some resource? And if you > store that logic somewhere, why not in the XML structure? Any reason to > use an id, and not for instance an URI to the remote 'developers' > homepage/resource? Yes, there is a logic. I think it is easier to maintain an external list, such as we do with "thirdpartymirrors". The point of listing alternative resources is that they may include features not provided by upstream itself. For example, an announce list that lets one know when a new version has been released. On 12/27/05, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > What is the reason for having an upstream tag? Aggregate useful upstream information in one place. > Wouldn't it be easier to just name the tags properly. How? > And what about just using a general attribute tag > like <meta name="upstreammaint" value="[EMAIL PROTECTED]"/> It's not bad, but isn't it better to have it in the structured way we suggest? It's graphically easier to read/write. Cheers! I'll be back the first week of January :-). Marcelo -- Marcelo Góes [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
