doman -i18n (for EAPI 4?)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

doman -i18n (for EAPI 4?)

Ulrich Mueller-2
The "doman" command has an -i18n option which is supported by all
three package managers, but so far PMS fails to documented it.

Bug 303919 [1] contains a proposal to add this documentation to PMS,
but also slightly change behaviour of doman, so that the -i18n option
would take precedence over the filename language suffix.

Do we need a council vote on this? If yes, is it something that should
go into EAPI 4 still? (Patches for portage [2] and PMS [3] are both
ready.)

I would put it on next meeting's agenda if you agree.

Ulrich

[1] <https://bugs.gentoo.org/show_bug.cgi?id=303919>
[2] <https://bugs.gentoo.org/attachment.cgi?id=222241>
[3] <https://bugs.gentoo.org/attachment.cgi?id=223393>

Reply | Threaded
Open this post in threaded view
|

Re: doman -i18n (for EAPI 4?)

Denis Dupeyron
On Wed, Apr 7, 2010 at 4:35 AM, Ulrich Mueller <[hidden email]> wrote:
> The "doman" command has an -i18n option which is supported by all
> three package managers, but so far PMS fails to documented it.
>
> Bug 303919 [1] contains a proposal to add this documentation to PMS,
> but also slightly change behaviour of doman, so that the -i18n option
> would take precedence over the filename language suffix.

I would say that this requires to be part of an EAPI bump in order to
be added. On the other hand I'm all for not waiting for all of EAPI 4
to be ready if we think we have enough material for a bump (I'm not
saying it's necessarily the case right now). More specifically I think
the current situation of deciding on a number of features for a given
EAPI before they are even worked on is proving that it's a bad idea.
Since we're all volunteers progress occurs rather unpredictably and
planned features which are not available yet are blocking features
which are available and would be useful now.

The downside to that is that it makes the life of the maintainers of
package managers more difficult since they end up having to track a
moving target. So if we decided to go that route we'd have to
cooperate better with them and provide them with enough visibility and
support to make it easier for them.

> Do we need a council vote on this? If yes, is it something that should
> go into EAPI 4 still? (Patches for portage [2] and PMS [3] are both
> ready.)

You can add to the agenda a vote on whether we want this feature in
the next EAPI bump, independent of what this bump actually is. In case
there's enough time you might even want to add a discussion on the
above topic.

Denis.