[gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[Marcelo Góes]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

Hello,

I am basically mailing this new draft on behalf of Ciaran, I just ok'd it :-).
Please read and comment.

Cheers,
Marcelo
--
Marcelo Góes
marcelogoes@gmail.com
vanquirius@gentoo.org

[-- Attachment #2: glep-0046.txt --]
[-- Type: text/plain, Size: 4093 bytes --]

GLEP: 46
Title: Allow upstream tags in metadata.xml
Version: $Revision: 1.1 $
Last-Modified: $Date: 2005/12/27 00:26:58 $
Author: Marcelo Goes <vanquirius@gentoo.org>, Ciaran McCreesh <ciaranm@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Dec-2005

Abstract
========

Tree ``metadata.xml`` files are currently used to specify maintainer and
description information for packages. This GLEP proposes extensions to
``metadata.xml`` to allow storage of information about upstream.

Motivation
==========

The range of upstream-related data currently available to developers and
tool authors is currently limited to ``DESCRIPTION`` and ``HOMEPAGE`` in
ebuilds.

There have been several attempts at creating tools that check a
package's versions against Freshmeat to see whether an ebuild version
bump is required. Currently identifying a package's Freshmeat entry is a
matter of guesswork, and not something that can reliably be automated.

Similarly, various scripts exist to check a package's status against a
specialist external data source. One of the authors, for example, has a
shell script hack that tries to determine whether any ``app-vim``
packages need bumping by checking the associated ``vim.org`` script
page. Again, tying packages to external data source entries is not
particulaly straight forward.

Making additional upstream-related data easily available will have other
benefits:

* It will allow systems such as the Packages website to provide more
  useful information to end users.

* It will reduce the time spent by developers trying to find how to
  contact upstream.

Specification
=============

``metadata.dtd`` should allow the use of a upstream tag in
``metadata.xml``.  Inside the upstream tag, developers should be able to
add upstream related information.

This GLEP defines the following four tags for ``upstream``:
``maintainer``, ``changelog``, ``bugs-to`` and ``remote-id``, none of
which are mandatory. Future GLEPs may extend this -- tools processing
metadata.xml should ignore unrecognized elements.

``maintainer`` can contain the tags ``name`` and ``email``, indicating
the person or organization responsible for upstream maintainership of
the package.

``name`` should contain a block of text with upstream's name.

``email`` should contain an e-mail address in the format foo@bar.bar.

``changelog`` should contain a URL prefixed with ``http://`` or
``https://`` where the location of the upstream changelog can be found.

``bugs-to`` should contain a place where bugs can be filed, a URL
prefixed with ``http://`` or ``https://`` or an e-mail address prefixed
with ``mailto:``.

``remote-id`` should specify a type of package identification tracker
and the identification that corresponds to the package in question.
``remote-id`` should make it easier to index information such as its
Freshmeat ID or its CPAN name.

The ``remote-id`` element has a ``type`` attribute, which is a string
identifying the type of upstream source. Examples are ``freshmeat``, in
which case the element content should be the Freshmeat ID or ``vim``, in
which case the element content should be the ``vim.org`` script
identifier. This GLEP does not specify a complete list of legal values
for ``type`` -- developers should email the ``gentoo-dev`` mailing list
before using a new ``type`` value.

For example, a ``metadata.xml`` upstream snippet may look like::

	<upstream>
		<maintainer>
			<name>Foo Bar</name>
			<email>foo@bar.bar</email>
		</maintainer>
		<changelog>http://foo.bar/changelog.txt</changelog>
		<bugs-to>https://bugs.foo.bar</bugs-to>
		<remote-id type="freshmeat">12345</remote-id>
		<remote-id type="sourceforge">foobar</remote-id>
	</upstream>


Backwards Compatibility
=======================

No changes are necessary to existing ``metadata.xml`` files. Information
in the new tags is not be mandatory. Any sane tool that currently
handles ``metadata.xml`` files will simply ignore unrecognised elements.

Copyright
=========

This document has been placed in the public domain.

.. vim: set ft=glep tw=72 :

Re: [gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[Marius Mauch]

On Sun, 5 Mar 2006 15:29:58 -0300
"Marcelo Góes" <vanquirius@gentoo.org> wrote:

> Hello,
> 
> I am basically mailing this new draft on behalf of Ciaran, I just
> ok'd it :-). Please read and comment.

general comment: Maybe this is an imlementation thing, but it would be
good to list the actual DTD for the new upstream tag as the GLEP leaves
some things unclear like how often the subtags may appear or if they
support any of the metadata.dtd attributes (like version restrictions).

regarding remote-id, while the GLEP doesn't and shouldn't contain a
definite list of types itself we should create/keep a definite list of
them in cvs or so, and the GLEP seems like the proper place to define
the location of that list.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Mon, 6 Mar 2006 01:48:19 +0000 Marius Mauch <genone@gentoo.org>
wrote:
| regarding remote-id, while the GLEP doesn't and shouldn't contain a
| definite list of types itself we should create/keep a definite list of
| them in cvs or so, and the GLEP seems like the proper place to define
| the location of that list.

XML people: is there a way of linking attribute="" values to stuff
defined in another XML file that isn't going to make my face bleed?

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[Chris White]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

On Monday 06 March 2006 09:58, Ciaran McCreesh wrote:
> XML people: is there a way of linking attribute="" values to stuff
> defined in another XML file that isn't going to make my face bleed?

Can you expand on that some more?  What exactly would be accomplished through 
that?

Chris White

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

On Mon, 6 Mar 2006 11:04:19 +0900 Chris White <chriswhite@gentoo.org>
wrote:
| On Monday 06 March 2006 09:58, Ciaran McCreesh wrote:
| > XML people: is there a way of linking attribute="" values to stuff
| > defined in another XML file that isn't going to make my face bleed?
| 
| Can you expand on that some more?  What exactly would be accomplished
| through that?

Well, if we're having a list of valid remote-id type values in a file
somewhere, there's at least a vague argument that said file should be
XML. And since XML is supposedly compatible, said file should be
magically linked to the regular metadata DTD.

So we'd have something like:

<remote-id-values>
    <value name="sourceforge" format="string">
        The project's sourceforge project ID (e.g. 'hilite')
    </value>
    <value name="vim" format="integer">
        The script's vim.org script ID (e.g. '123')
    </value>
</remote-id-values>

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[Chris White]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

On Monday 06 March 2006 12:02, Ciaran McCreesh wrote:
> Well, if we're having a list of valid remote-id type values in a file
> somewhere, there's at least a vague argument that said file should be
> XML. And since XML is supposedly compatible, said file should be
> magically linked to the regular metadata DTD.
>
> So we'd have something like:
>
> <remote-id-values>
>     <value name="sourceforge" format="string">
>         The project's sourceforge project ID (e.g. 'hilite')
>     </value>
>     <value name="vim" format="integer">
>         The script's vim.org script ID (e.g. '123')
>     </value>
> </remote-id-values>

Correct me if I'm wrong but.. it seems you're describing XML Schema[1]?  Using 
XML to define the value types that can exist in another XML file would be XML 
Schema.

I'm going under that this is in reference to:

"This GLEP does not specify a complete list of legal values
for ``type`` -- developers should email the ``gentoo-dev`` mailing list
before using a new ``type`` value."

and if not please specify which part of the GLEP this references to.

Chris White

[1] http://www.w3.org/TR/xmlschema-0/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Sunday 05 March 2006 19:29, Marcelo Góes wrote:
> Hello,
>
> I am basically mailing this new draft on behalf of Ciaran, I just ok'd it
> :-). Please read and comment.
>

I'm really sorry that I didn't act upon a previous proposal in this area. I'm 
still putting the finishing touches on my Ph.D. thesis. It kindof has my 
priority now. Anyway, I think that another tag "doc" should be added with a 
"type" and a "description" attribute for upstream documentation as proposed.

Further, in reaction to Ciaranm's comment, I don't think that the format 
should be overengineered. Just having types should be enough.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: New Glep 46 Draft: Allow upstream tags in metadata.xml

[R Hill]

Marcelo Góes wrote:

> GLEP: 46
> Title: Allow upstream tags in metadata.xml
> Version: $Revision: 1.1 $

i'm offline for the week, so ignore any of this that has already been discussed
in the meantime.

> This GLEP defines the following four tags for ``upstream``:
> ``maintainer``, ``changelog``, ``bugs-to`` and ``remote-id``, none of
> which are mandatory. Future GLEPs may extend this -- tools processing
> metadata.xml should ignore unrecognized elements.

i think a 'status' tag might also be handy to indicate if the package has an 
active upstream or not.  either a text field or a predetermined set of 
possibilities ("active"/"inactive").

> ``maintainer`` can contain the tags ``name`` and ``email``, indicating
> the person or organization responsible for upstream maintainership of
> the package.

multiple maintainer tags allowed?

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New Glep 46 Draft: Allow upstream tags in metadata.xml

[Marcelo Góes]

On 3/12/06, R Hill <dirtyepic.sk@gmail.com> wrote:
> i think a 'status' tag might also be handy to indicate if the package has an
> active upstream or not.  either a text field or a predetermined set of
> possibilities ("active"/"inactive").

active/inactive sounds good enough for me, as long as people don't
start tagging upstream as inactive if they do not reply within the
hour...

> multiple maintainer tags allowed?

Sure, why not? That is how it is done with Gentoo maintainers in
metadata.xml already, AFAIK.

Cheers
--
Marcelo Góes
marcelogoes@gmail.com
vanquirius@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list