[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: Re: [gentoo-dev] Drop the Perl Modules Guideline?
From: Mikle Kolyada <zlog.gentoo () gmail ! com>
Date: 2012-12-28 12:30:35
Message-ID: CAJai-TLUkncnTUSfbUCw7o5t96x64_3KL3LBbfmp5h=gW-=MHw () mail ! gmail ! com
[Download RAW message or body]
I can't vote, but I think we need to soften the policy.
2012/12/26 Sergey Popov <pinkbyte@gentoo.org>
> 25.12.2012 18:30, Mike Gilbert wrote:
> > On Tue, Dec 25, 2012 at 7:09 AM, Torsten Veller <tove@gentoo.org> wrote:
> >> Let's discuss the "specific guideline" for Perl modules. It's as
> follows:
> >>
> >> ,-
> http://devrel.gentoo.org/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect2
> >> | Perl
> >> |
> >> | New Perl modules are to be added to portage only when one of the
> following
> >> | conditions is met:
> >> |
> >> | a) The module(s) fulfill a dependency
> >> | b) The module(s) cannot be handled by g-cpan
> >> | c) The module(s) add functionality to existing ebuilds
> >> | d) The module(s) provide tools, applications or other features (i.e.
> more
> >> | than what their .PM offers)
> >> |
> >> | Please make sure that at least one member of the perl herders approves
> >> | your addition.
> >> `-
> >>
> >> Recently the proxy-maintainer project is repeatedly adding packages
> >> which aren't following these guideline AFAIK. So maybe we should change
> >> it.
> >>
> >> 444974 a) dev-perl/Text-Format - Various subroutines to format text
> 2012-12-07
> >> 444976 a) dev-perl/Roman - Perl module for conversion between Roman and
> Arabic numerals. 2012-12-03
> >> 446710 ?) dev-perl/FLV-AudioExtractor - Extract audio from Flash Videos
> 2012-12-12
> >> 447724 ?) dev-perl/Email-Send-Gmail - Send Messages using Gmail Mon
> 10:12
> >>
> >> Ad a): This requirement is a little problematic:
> >> Sometimes perl modules are needed for maintainer-wanted packages.
> >> Sometimes the perl modules are added to the tree while the
> >> maintainer-wanted package never are or will be. Sometimes the maintainer
> >> are waiting for the perl team to do their work.
> >>
> >> Ad b): (Judging from bugreports) g-cpan doesn't seem to be really
> >> reliable these days. I always wanted to test/verify it. But ... (random
> >> excuse: time, motivation,...)
> >>
> >> I guess I don't have no problem with modifying or dropping the
> >> requirements. The perl overlay contains hundreds of packages which
> >> should be added to the main tree.
> >>
> >> The dev-perl category currently already contains the most packages
> >> (1140 per packages.g.o).
> >>
> >> --
> >> Best regards
> >> Torsten
> >>
> >
> > I'm sure I skimmed that section of the handbook at some point for the
> > quizzes, but I don't remember it. I think it is possible that the
> > proxy commiter (pinkbyte) forgot about it too.
>
> No, i do not, i have read this guideline, and yes - it is not mentioned
> directly in Handbook or Devmanual.
> Some of these modules was added cause they are dependencies for other
> packages(which are still waiting for adding in tree, cause they have no
> maintainer yet), others - cause g-cpan generate very ugly ebuilds for them.
>
> > I think that all of those requirements make sense. We might want to
> > formalize a similar guideline for the python herd.
> >
> > Perhaps the requirements list could be copied somewhere more visible?
> > The perl project page might get more traffic for people looking to
> > write perl ebuilds.
> >
>
> Truly, i do not really understand such hard policy for NOT including
> perl modules in tree. I know that perl herd is understaffed, but i do
> not think that this is generally a problem, cause they do not maintain
> recently added packages, but proxy maintainers do.
>
> So, basically, yes, i vote for easing policy a bit.
>
> P.S. CCing maintainer of modules, that i have commited as a proxy, maybe
> he also wants to say something regarding this.
>
> --
> Best regards, Sergey Popov
> Gentoo Linux Developer
> Desktop-effects project lead
>
>
--
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.17 (GNU/Linux)
mI0ETyui1AEEALmZQeAzZVPBtw3IJ3NC3w1SdhrNFN7DnEmnrw0UrjfZ1ubxGq58
2nmOOrb0TxAx4hQ5DPiWzIK0D4EAYAPbkApJsYUB7jhocV7d1O09iu+Ip8lT5wV3
ZviMJ0r3itP8yOU93v7WKygR9T4AljMuMoP7v2qz+VCyeVplfsYHo/qbABEBAAG0
Pk1pa2xlIEtvbHlhZGEgKFRoZSBSZWFsIE1pa2xlIEtvbHlhZGEpIDx6bG9nLmdl
bnRvb0BnbWFpbC5jb20+iLgEEwECACIFAk8rotQCGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAAoJEDRdeYLl90M6N2cD/jFx/0p+dT67Dgq8wQGRE6VMjHsP6rZl
uM2B2NvIuaJAKx6CESUJzxHSVHsu9xVrSm8g1/+rtryf/NxbtEsscUuWY62yVDVj
F+sLOPNztj2K7ms2aHAgZxwbAG/yjGt+KTcgga2CYxwPvKEvU+suEL4c+ScSrRSl
/vdll08JVo0yuI0ETyui1AEEAMbrOCNzTvLfsb4whOo+pk+y9YU9PXzI5u+Zao3v
qmLkyViqwh+z9O3r8IIFWF5ASVPHwBIMWDWn0KamA7QsKKFD87Q3wMN524oCvVds
FnbtqZhlntE0AbQzt4bkpGpIbmAw1nL6B2BE7xiPrEMqcNPyXLYp6i60ddRDHrcB
ZlQJABEBAAGInwQYAQIACQUCTyui1AIbDAAKCRA0XXmC5fdDOhBwA/wLTcQgIm76
bG0a9t551U5YnQBD2H+nlBzwrPREY5P40pwRt6ur1eN9Xobs9IsimmRQGwlfwLuv
PKFD4KWCmjyoMxMuF1b0VycbuETz31T4KxF0CGAQoiRxGurlhbxmmjrauqqUAYft
1mGFbulta/hLx0Ez0JNEDw0Z6dw4Jny15Q==
=sNcj
-----END PGP PUBLIC KEY BLOCK-----
[Attachment #3 (text/html)]
<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">I can't \
vote, but I think we need to soften the policy.</span><br></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">2012/12/26 Sergey Popov <span \
dir="ltr"><<a href="mailto:pinkbyte@gentoo.org" \
target="_blank">pinkbyte@gentoo.org</a>></span><br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">25.12.2012 18:30, Mike Gilbert wrote:<br> > On Tue, Dec \
25, 2012 at 7:09 AM, Torsten Veller <<a \
href="mailto:tove@gentoo.org">tove@gentoo.org</a>> wrote:<br> >> Let's \
discuss the "specific guideline" for Perl modules. It's as follows:<br> \
>><br> >> ,- <a \
href="http://devrel.gentoo.org/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect2" \
target="_blank">http://devrel.gentoo.org/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect2</a><br>
>> | Perl<br>
>> |<br>
>> | New Perl modules are to be added to portage only when one of the \
following<br> >> | conditions is met:<br>
>> |<br>
>> | a) The module(s) fulfill a dependency<br>
>> | b) The module(s) cannot be handled by g-cpan<br>
>> | c) The module(s) add functionality to existing ebuilds<br>
>> | d) The module(s) provide tools, applications or other features (i.e. \
more<br> >> | than what their .PM offers)<br>
>> |<br>
>> | Please make sure that at least one member of the perl herders approves<br>
>> | your addition.<br>
>> `-<br>
>><br>
>> Recently the proxy-maintainer project is repeatedly adding packages<br>
>> which aren't following these guideline AFAIK. So maybe we should \
change<br> >> it.<br>
>><br>
>> 444974 a) dev-perl/Text-Format - Various subroutines to format text \
2012-12-07<br> >> 444976 a) dev-perl/Roman - Perl module for conversion between \
Roman and Arabic numerals. 2012-12-03<br> >> 446710 ?) \
dev-perl/FLV-AudioExtractor - Extract audio from Flash Videos 2012-12-12<br> >> \
447724 ?) dev-perl/Email-Send-Gmail - Send Messages using Gmail Mon 10:12<br> \
>><br> >> Ad a): This requirement is a little problematic:<br>
>> Sometimes perl modules are needed for maintainer-wanted packages.<br>
>> Sometimes the perl modules are added to the tree while the<br>
>> maintainer-wanted package never are or will be. Sometimes the maintainer<br>
>> are waiting for the perl team to do their work.<br>
>><br>
>> Ad b): (Judging from bugreports) g-cpan doesn't seem to be really<br>
>> reliable these days. I always wanted to test/verify it. But ... (random<br>
>> excuse: time, motivation,...)<br>
>><br>
>> I guess I don't have no problem with modifying or dropping the<br>
>> requirements. The perl overlay contains hundreds of packages which<br>
>> should be added to the main tree.<br>
>><br>
>> The dev-perl category currently already contains the most packages<br>
>> (1140 per packages.g.o).<br>
>><br>
>> --<br>
>> Best regards<br>
>> Torsten<br>
>><br>
><br>
> I'm sure I skimmed that section of the handbook at some point for the<br>
> quizzes, but I don't remember it. I think it is possible that the<br>
> proxy commiter (pinkbyte) forgot about it too.<br>
<br>
No, i do not, i have read this guideline, and yes - it is not mentioned<br>
directly in Handbook or Devmanual.<br>
Some of these modules was added cause they are dependencies for other<br>
packages(which are still waiting for adding in tree, cause they have no<br>
maintainer yet), others - cause g-cpan generate very ugly ebuilds for them.<br>
<br>
> I think that all of those requirements make sense. We might want to<br>
> formalize a similar guideline for the python herd.<br>
><br>
> Perhaps the requirements list could be copied somewhere more visible?<br>
> The perl project page might get more traffic for people looking to<br>
> write perl ebuilds.<br>
><br>
<br>
Truly, i do not really understand such hard policy for NOT including<br>
perl modules in tree. I know that perl herd is understaffed, but i do<br>
not think that this is generally a problem, cause they do not maintain<br>
recently added packages, but proxy maintainers do.<br>
<br>
So, basically, yes, i vote for easing policy a bit.<br>
<br>
P.S. CCing maintainer of modules, that i have commited as a proxy, maybe<br>
he also wants to say something regarding this.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Best regards, Sergey Popov<br>
Gentoo Linux Developer<br>
Desktop-effects project lead<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- \
<br><div>-----BEGIN PGP PUBLIC KEY BLOCK-----</div><div>Version: GnuPG v2.0.17 \
(GNU/Linux)</div><div><br></div><div>mI0ETyui1AEEALmZQeAzZVPBtw3IJ3NC3w1SdhrNFN7DnEmnrw0UrjfZ1ubxGq58</div>
<div>2nmOOrb0TxAx4hQ5DPiWzIK0D4EAYAPbkApJsYUB7jhocV7d1O09iu+Ip8lT5wV3</div><div>ZviMJ \
0r3itP8yOU93v7WKygR9T4AljMuMoP7v2qz+VCyeVplfsYHo/qbABEBAAG0</div><div>Pk1pa2xlIEtvbHlhZGEgKFRoZSBSZWFsIE1pa2xlIEtvbHlhZGEpIDx6bG9nLmdl</div>
<div>bnRvb0BnbWFpbC5jb20+iLgEEwECACIFAk8rotQCGwMGCwkIBwMCBhUIAgkKCwQW</div><div>AgMBA \
h4BAheAAAoJEDRdeYLl90M6N2cD/jFx/0p+dT67Dgq8wQGRE6VMjHsP6rZl</div><div>uM2B2NvIuaJAKx6CESUJzxHSVHsu9xVrSm8g1/+rtryf/NxbtEsscUuWY62yVDVj</div>
<div>F+sLOPNztj2K7ms2aHAgZxwbAG/yjGt+KTcgga2CYxwPvKEvU+suEL4c+ScSrRSl</div><div>/vdll \
08JVo0yuI0ETyui1AEEAMbrOCNzTvLfsb4whOo+pk+y9YU9PXzI5u+Zao3v</div><div>qmLkyViqwh+z9O3r8IIFWF5ASVPHwBIMWDWn0KamA7QsKKFD87Q3wMN524oCvVds</div>
<div>FnbtqZhlntE0AbQzt4bkpGpIbmAw1nL6B2BE7xiPrEMqcNPyXLYp6i60ddRDHrcB</div><div>ZlQJA \
BEBAAGInwQYAQIACQUCTyui1AIbDAAKCRA0XXmC5fdDOhBwA/wLTcQgIm76</div><div>bG0a9t551U5YnQBD2H+nlBzwrPREY5P40pwRt6ur1eN9Xobs9IsimmRQGwlfwLuv</div>
<div>PKFD4KWCmjyoMxMuF1b0VycbuETz31T4KxF0CGAQoiRxGurlhbxmmjrauqqUAYft</div><div>1mGFbulta/hLx0Ez0JNEDw0Z6dw4Jny15Q==</div><div>=sNcj</div><div>-----END \
PGP PUBLIC KEY BLOCK-----</div><div><br></div> </div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic