[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
Santiago M. Mola wrote: On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] 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
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?
docsofficial-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
On Jan 19, 2008 4:13 PM, Tiziano Müller [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
���^�X��� ��(��j)b�b�
[gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
Denis Dupeyron wrote: On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] 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
Mark Loeser wrote:
Tiziano Müller [EMAIL PROTECTED] 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
