Mailing List Archive

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
z{h¡×¯–+-²§¶Š(® šŠX§‚X¬

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

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

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¬¶ÈžÚ(¢¸&j)bž b²

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.
z{h¡×¯–+-²§¶Š(® šŠX§‚X¬

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
žÚ(uëåŠËléí¢Š+‚f¢–)à–+-

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

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

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

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

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

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