[gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[Tiziano Müller]

Current state: "Deferred"
Wanted state: "Accepted/Implemented" (at least by me)

Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one <maintainer>
  entry?
- Is recording an upstream-status (active/inactive) a good idea?
  Possibilities:
    An element: <status>{active/inactive}</status>
    An attribute: <maintainer status="{active/inactive}">...
- Is an additional <doc> element needed to link to upstream docs
- Must the type of <remote-id> be controlled/listed/checked?

My answers to this:
- yes
- yes. Remark: do we need to specify when upstream has to be marked as
active/inactive or can we use our common sense ?
- yes.
- not yet. Can be defined later.

Your oppinion?


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[Santiago M. Mola]

On Jan 19, 2008 2:07 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
>
> Current state: "Deferred"
> Wanted state: "Accepted/Implemented" (at least by me)

The GLEP should be updated. "Motivation" section does not seem to
justify the changes. IMO Meatoo [1]  (and its hipothetical rewrite
using Doapspace [2]) would be the right tool to detect version bumps.
Maybe metadata.xml should contain a  Freshmeat or DOAP entry so meatoo
could get more automation.

Anyway, I don't know how much would take the new version of meatoo.
Pythonhead, could you give us some news about it? Or it's just planned
for the long-term future?


[1] http://meatoo.gentooexperimental.org/
[2] http://blog.doapspace.org/

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[Mark Loeser]

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

Tiziano Müller <dev-zero@gentoo.org> said:
> 
> Current state: "Deferred"
> Wanted state: "Accepted/Implemented" (at least by me)

Yea, this sounds like a good thing from reading over the GLEP, unless
I'm missing some glaring problems with it.

> Open questions from last discussion (March 2006):
> - Is it possible/should it be possible to have more than one <maintainer>
>   entry?

Yea, agree.

> - Is recording an upstream-status (active/inactive) a good idea?
>   Possibilities:
>     An element: <status>{active/inactive}</status>
>     An attribute: <maintainer status="{active/inactive}">...

Definately.  We have several packages in the tree that once they become
broken, we'd have to start developing ourselves.  This will help the
treecleaner project as well so they can tell if a package has several
open bugs and upstream is inactive, its a very good candidate for
getting booted from the tree.

> - Is an additional <doc> element needed to link to upstream docs

Sounds reasonable.

> - Must the type of <remote-id> be controlled/listed/checked?

I'd say we should come up with a good list to start with.  We can come
up with updates to the allowed values at a later date, but I do think we
should keep this under control.


-- 
Mark Loeser
email         -   halcy0n AT gentoo DOT org
email         -   mark AT halcy0n DOT com
web           -   http://www.halcy0n.com

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

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[Alistair Bush]

Tiziano Müller wrote:
> Current state: "Deferred"
> Wanted state: "Accepted/Implemented" (at least by me)
> 
> Open questions from last discussion (March 2006):
> - Is it possible/should it be possible to have more than one <maintainer>
>   entry?
	
	Yes

> - Is recording an upstream-status (active/inactive) a good idea?
Maybe, leaning to No.

What about packages that have multiple slots, e.g php-4, php-5?  one 
slot could be inactive the other not, does that make upstream active?

>   Possibilities:
>     An element: <status>{active/inactive}</status>

	Status of what? seeing you have proposed a upstream-status and a 
maintainer status. what else is there left to status :P

>     An attribute: <maintainer status="{active/inactive}">...
	No.  As i'm pretty sure that every inactive maintainer won't go around 
updating their packages metadata.xml

> - Is an additional <doc> element needed to link to upstream docs
Interesting. what about the situation where upstream documentation sucks 
but there is a "better" resource provided by a third party, could we 
link to that? e.g. http://tldp.org for bash is an excellent resource
Multiple doc links? 
<docs><official-doc/><official-doc/><doc/><doc/></docs> could provide 
that.  Only concern I see is that this could relate to an endorsement of 
thirdparty websites, which may change negatively ( porn on tldp.org ) or 
my just become outdated.

Actually without the multiple official/unofficial doc tags I would have 
to say No.  as 99% of the time it would just be "${HOMEPAGE}/doc" or 
there would be a big fat link from the homepage and therefore would be 
of no real benefit.

Alistair

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml

[Tiziano Müller]

Santiago M. Mola wrote:

> On Jan 19, 2008 2:07 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
>>
>> Current state: "Deferred"
>> Wanted state: "Accepted/Implemented" (at least by me)
> 
> The GLEP should be updated. "Motivation" section does not seem to
> justify the changes. IMO Meatoo [1]  (and its hipothetical rewrite
> using Doapspace [2]) would be the right tool to detect version bumps.
> Maybe metadata.xml should contain a  Freshmeat or DOAP entry so meatoo
> could get more automation.
Unfortunately not all projects update their Freshmeat entry.

But you're right about the motivation: The point "It will reduce the time
spent by developers trying to find how to contact upstream." should get
more attention.
Maybe it should even be split into two proposals: "New upstream tags to
store maintenance upstream info" and "Add upstream tags to be able to store
upstream version info" (or something like this, I'm sure you get the idea).



-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml

[Tiziano Müller]

Alistair Bush wrote:

> 
> 
> Tiziano Müller wrote:
>> Current state: "Deferred"
>> Wanted state: "Accepted/Implemented" (at least by me)
>> 
>> Open questions from last discussion (March 2006):
>> - Is it possible/should it be possible to have more than one <maintainer>
>>   entry?
> 
> Yes
> 
>> - Is recording an upstream-status (active/inactive) a good idea?
> Maybe, leaning to No.
> 
> What about packages that have multiple slots, e.g php-4, php-5?  one
> slot could be inactive the other not, does that make upstream active?
Well, upstream for php-4 is not inactive (it still exists but answers with
a "won't fix" if you report a bug for php-4).

But there might be a case that there are two maintainers of different
branches of a software. Doesn't seem like a common case, does it?
Nevertheless: ideas?

> 
>>   Possibilities:
>>     An element: <status>{active/inactive}</status>
> 
> Status of what? seeing you have proposed a upstream-status and a
> maintainer status. what else is there left to status :P
There will be a <maintainer> tag within the <upstream></upstream>, not the
same as our already existing <maintainer>

But the question I tried to express (probably not clear enough) is:
Should (if at all) the status being tracked for <upstream> or for
<maintainer> (within upstream).

As an example "dev-libs/xmlwrapp": The original maintainer is inactive, but
there is a new one who took the package to sourceforge and it's not a fork
since the original maintainer agreed up on this. Should such a case be
tracked at all?

> 
>>     An attribute: <maintainer status="{active/inactive}">...
> No.  As i'm pretty sure that every inactive maintainer won't go around
> updating their packages metadata.xml
Not talking about the existing <maintainer> tag, sorry.

> 
>> - Is an additional <doc> element needed to link to upstream docs
> Interesting. what about the situation where upstream documentation sucks
> but there is a "better" resource provided by a third party, could we
> link to that? e.g. http://tldp.org for bash is an excellent resource
> Multiple doc links?
> <docs><official-doc/><official-doc/><doc/><doc/></docs> could provide
> that.  Only concern I see is that this could relate to an endorsement of
> thirdparty websites, which may change negatively ( porn on tldp.org ) or
> my just become outdated.
> 
> Actually without the multiple official/unofficial doc tags I would have
> to say No.  as 99% of the time it would just be "${HOMEPAGE}/doc" or
> there would be a big fat link from the homepage and therefore would be
> of no real benefit.

Hmm, good point. Maybe we have to narrow the specification for <doc> to only
point to package maintainer info?
Since it can also change between versions, slots, etc...



-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml

[Santiago M. Mola]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1225 bytes --]

On Jan 19, 2008 4:13 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
> >>   Possibilities:
> >>     An element: <status>{active/inactive}</status>
> >
> > Status of what? seeing you have proposed a upstream-status and a
> > maintainer status. what else is there left to status :P
> There will be a <maintainer> tag within the <upstream></upstream>, not the
> same as our already existing <maintainer>
>
> But the question I tried to express (probably not clear enough) is:
> Should (if at all) the status being tracked for <upstream> or for
> <maintainer> (within upstream).
>
> As an example "dev-libs/xmlwrapp": The original maintainer is inactive, but
> there is a new one who took the package to sourceforge and it's not a fork
> since the original maintainer agreed up on this. Should such a case be
> tracked at all?
>

I think we don't want to track if previous maintainer is active or
not, or if it's changed. In your example, the important data is "who
is the current maintainer and how to contact him" and "is she
active?". Keeping an entry for the old maintainer as inactive when
there's a new one is not like an useful piece of info.

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
éí¢‡^¾X¬¶È\x1ežÚ(¢¸&j)bž	b²

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[Denis Dupeyron]

On Jan 19, 2008 2:07 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
> Your oppinion?

Would this be the right time to discuss about moving other variables
to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those
hardly change and if they ever do we can restrict them to specific
versions. I know there could be technical hurdles, but what do you
think of the idea at least ?

Denis.

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[Santiago M. Mola]

On Jan 19, 2008 4:24 PM, Denis Dupeyron <calchan@gentoo.org> wrote:
> On Jan 19, 2008 2:07 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
> > Your oppinion?
>
> Would this be the right time to discuss about moving other variables
> to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those
> hardly change and if they ever do we can restrict them to specific
> versions. I know there could be technical hurdles, but what do you
> think of the idea at least ?
>

I'm not sure about HOMEPAGE and DESCRIPTION, but I think LICENSE
should be per-ebuild variable. A license change is not so strange
(GPL-3, double licensing the source, or adding new artwork licensed
with a more restrictive license). Moreover, a license change does not
need to be retroactive, so using a global variable in metadata.xml
could lead to accidentally show a wrong license for old versions.

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml

[Tiziano Müller]

Denis Dupeyron wrote:

> On Jan 19, 2008 2:07 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
>> Your oppinion?
> 
> Would this be the right time to discuss about moving other variables
> to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those
I'd rather like to see it in a new thread since it involves changes to the
PMS.

> hardly change and if they ever do we can restrict them to specific
> versions. I know there could be technical hurdles, but what do you
> think of the idea at least ?
But it ties the ebuild closer to the metadata and if you get an ebuild
without HOMEPAGE, DESCRIPTION and LICENSE you don't have any information
about the package. I'd say that those vars are the minimal needed
information for a package and should therefore being kept in the ebuild
itself. But a longer description or a description in a different language
can always be kept in metadata.xml as it is possible already.


-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml

[Tiziano Müller]

Mark Loeser wrote:

> Tiziano Müller <dev-zero@gentoo.org> said:
>> 
>> Current state: "Deferred"
>> Wanted state: "Accepted/Implemented" (at least by me)
> 
> Yea, this sounds like a good thing from reading over the GLEP, unless
> I'm missing some glaring problems with it.
> 
>> Open questions from last discussion (March 2006):
>> - Is it possible/should it be possible to have more than one <maintainer>
>>   entry?
> 
> Yea, agree.
> 
>> - Is recording an upstream-status (active/inactive) a good idea?
>>   Possibilities:
>>     An element: <status>{active/inactive}</status>
>>     An attribute: <maintainer status="{active/inactive}">...
> 
> Definately.  We have several packages in the tree that once they become
> broken, we'd have to start developing ourselves.  This will help the
> treecleaner project as well so they can tell if a package has several
> open bugs and upstream is inactive, its a very good candidate for
> getting booted from the tree.
> 
>> - Is an additional <doc> element needed to link to upstream docs
> 
> Sounds reasonable.
> 
>> - Must the type of <remote-id> be controlled/listed/checked?
> 
> I'd say we should come up with a good list to start with.  We can come
> up with updates to the allowed values at a later date, but I do think we
> should keep this under control.
Ok, agreed.
Where should we keep that list?
Something like "gentoo-x86/metadata/dtd/upstream-tags.dtd" ?


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[Ciaran McCreesh]

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

On Sat, 19 Jan 2008 16:24:53 +0100
"Denis Dupeyron" <calchan@gentoo.org> wrote:
> On Jan 19, 2008 2:07 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
> > Your oppinion?
> 
> Would this be the right time to discuss about moving other variables
> to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those
> hardly change and if they ever do we can restrict them to specific
> versions. I know there could be technical hurdles, but what do you
> think of the idea at least ?

At least LICENSE is no go, since the package manager needs it. Having
DESCRIPTION and HOMEPAGE available to the package manager even when XML
goes splat is probably useful too...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml

[Rob Cakebread]

Santiago M. Mola wrote:
> 
> The GLEP should be updated. "Motivation" section does not seem to
> justify the changes. IMO Meatoo [1]  (and its hipothetical rewrite
> using Doapspace [2]) would be the right tool to detect version bumps.
> Maybe metadata.xml should contain a  Freshmeat or DOAP entry so meatoo
> could get more automation.
> 
> Anyway, I don't know how much would take the new version of meatoo.
> Pythonhead, could you give us some news about it? Or it's just planned
> for the long-term future?
> 
> 
> [1] http://meatoo.gentooexperimental.org/
> [2] http://blog.doapspace.org/
> 


Sorry, I missed this email, but I'll be at the council meeting to listen 
in on talk about GLEP 46.

Having Freshmeat, SourceForge etc. project id's in metadata.xml sounds 
great.

I would gladly write a tool to go through SourceForge and Freshmeat's 
metadata and match project names to ebuild package names using HOMEPAGE. 
  I already have code to parse FLOSSMole's[1] metadata, so it'd be 
simple to whip up quickly.

doapspace.org has an API that lets you give a SourceForge, Freshmeat, 
PyPI and RubyForge project name and get metadata back, so having a link 
to the DOAP's URL in metadata.xml isn't really needed for those. For 
self-hosted projects, we could either put a link to the DOAP in 
metadata.xml, or simply make sure the HOMEPAGE matches the homepage in 
the DOAP itself. The second is preferable because the URL to the DOAP 
could change.

Meatoo will be much more accurate after I cross-reference metadata from 
FLOSSMole to map Gentoo package names to other forge/package index 
names. Once that's done, we'll have very accurate version bump info that 
can be looked up by herd/maintainer, from SourceForge, RubyForge, 
Freshmeat etc.

Rob

[1] http://ossmole.sourceforge.net

-- 
gentoo-dev@lists.gentoo.org mailing list