[gentoo-dev] Last rites: dev-perl/Date-ISO

2013-07-16 Thread Mikle Kolyada
# Mikle Kolyada zlog...@gentoo.org (16 Jul 2013)
# Upstream dead.
# No license info (bug #381283).
# Removal in 30 days.
dev-perl/Date-ISO

-- 
Best regards, Mikle Kolyada.
Gentoo Linux Developer.




[gentoo-dev] About m68k arch status in perl packages

2013-06-26 Thread Mikle Kolyada
Hi all. We have very long delay with m68k arch in many stabilization
bugs, especially in perl-related. I think this is not ok. The only one
mk68k developer is vapier, so i want say: if we'll have no progress in
stabilization for m68k for a two weeks, i'll close all bugs, that have
m68k as last arch (i have no hardware to test it) and drop related
keyword in package to unstable.

-- 
Best reagrds, Mikle Kolyada.
Gentoo Linux Developer




[gentoo-dev] Last rites: dev-perl/Class-MOP

2013-06-25 Thread Mikle Kolyada
# Torsten Veller t...@gentoo.org (08 Jan 2013)
# Mask dev-perl/Class-MOP. It was merge with dev-perl/Moose-2.
# Now as the last arch stabilized Moose-2, dev-perl/Class-MOP will be
removed.
# bug #350612
dev-perl/Class-MOP

-- 
Best reagrds, Mikle Kolyada.
Gentoo Linux Developer




Re: [gentoo-dev] Drop the Perl Modules Guideline?

2012-12-28 Thread Mikle Kolyada
I can't vote, but I think we need to soften the policy.


2012/12/26 Sergey Popov pinkb...@gentoo.org

 25.12.2012 18:30, Mike Gilbert wrote:
  On Tue, Dec 25, 2012 at 7:09 AM, Torsten Veller t...@gentoo.org wrote:
  Let's discuss the specific guideline for Perl modules. It's as
 follows:
 
  ,-
 http://devrel.gentoo.org/handbook/handbook.xml?part=2chap=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-


<    1   2