Along these lines... Do we have a plan for including 5.10 in F-9/devel? With the RC out, it sounds like 5.10 will GA not-too-horribly-soon from now, and we're at a point in devel where it's probably the Right Time to think about bumping from 5.8 to 5.10.
http://perlbuzz.com/project-hum/2007/10/perl-5100-nears-code-freeze-release....
-Chris
---------- Forwarded message ---------- From: Steven Bakker sb@monkey-mind.net Date: Nov 23, 2007 2:04 AM Subject: Re: AWOL: jpo To: Development discussions related to Fedora fedora-devel-list@redhat.com
On Tue, 20 Nov 2007 11:41:25 -0700 Richi Plana wrote:
As much as I love Perl and I prefer it over all existing scripting languages I'm familiar with, it's hard to get excited about its future since the developers are extremely quiet about it.
They're probably quiet about it because they prefer coding over talking :-)
Perl 5.10-RC1 has been unleashed recently[1], full of nice new features[2], borrowing some from (the still-vaporware) Perl6 (named capture buffers!).
[1] http://search.cpan.org/~rgarcia/perl-5.10.0-RC1/ [2] http://www.slideshare.net/rjbs/perl-510-for-people-who-arent-totally-insane
-- Steven
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sat, 2007-11-24 at 09:34 -0800, Chris Weyl wrote:
Along these lines... Do we have a plan for including 5.10 in F-9/devel? With the RC out, it sounds like 5.10 will GA not-too-horribly-soon from now, and we're at a point in devel where it's probably the Right Time to think about bumping from 5.8 to 5.10.
Any idea how intrusive this will be? Will it require a mass-rebuild of perl packages?
~spot
On 24/11/2007, Tom spot Callaway tcallawa@redhat.com wrote:
On Sat, 2007-11-24 at 09:34 -0800, Chris Weyl wrote:
Along these lines... Do we have a plan for including 5.10 in F-9/devel? With the RC out, it sounds like 5.10 will GA not-too-horribly-soon from now, and we're at a point in devel where it's probably the Right Time to think about bumping from 5.8 to 5.10.
Any idea how intrusive this will be? Will it require a mass-rebuild of perl packages?
Yes. All modules that have XS parts will need to be rebuilt, since 5.10 isn't binary compatible with 5.8.
On Nov 24, 2007 10:17 AM, Rafael Garcia-Suarez rgarciasuarez@gmail.com wrote:
On 24/11/2007, Tom spot Callaway tcallawa@redhat.com wrote:
On Sat, 2007-11-24 at 09:34 -0800, Chris Weyl wrote:
Along these lines... Do we have a plan for including 5.10 in F-9/devel? With the RC out, it sounds like 5.10 will GA not-too-horribly-soon from now, and we're at a point in devel where it's probably the Right Time to think about bumping from 5.8 to 5.10.
Any idea how intrusive this will be? Will it require a mass-rebuild of perl packages?
Yes. All modules that have XS parts will need to be rebuilt, since 5.10 isn't binary compatible with 5.8.
We also use the magic perl(:MODULE_COMPAT_x.x.x) tag even in noarch packages, which I imagine will need to change.
So, from a couple quick queries off yum list on my laptop (which will be slightly skewed -- I have ~10ish perl rpms installed not yet in Fedora):
642 noarch 172 x86_64 ------------- 814 total
I suspect we can ease the pain by coordinating a mass rebuild here, and just kicking off the rebuilds centrally. (e.g. an annointed Rebuilder In Chief)
-Chris
On Sat, 2007-11-24 at 11:16 -0800, Chris Weyl wrote:
642 noarch 172 x86_64
814 total
I suspect we can ease the pain by coordinating a mass rebuild here, and just kicking off the rebuilds centrally. (e.g. an annointed Rebuilder In Chief)
The circular dependencies will be fun!
First things first, lets divide up all of jpo's perl packages tomorrow (assuming that he doesn't come out of AWOL status in the next 24 hours), so that we have owners to help push this through.
Here's the list of his packages (mostly perl), feel free to start staking claims on what you'd like:
* asymptote -- Descriptive vector graphics language * eventlog -- Syslog-ng v2 support library * kchmviewer -- CHM viewer with KDE support * libcgi -- CGI easy as C * libol -- Support library for syslog-ng * libsmi -- A library to access SMI MIB information * nagios-plugins -- Host/service/network monitoring program plugins for Nagios * nagios-plugins-snmp-disk-proc -- Nagios SNMP plugins to monitor remote disk and processes * pdfjam -- Utilities for join, rotate and align PDFs * perl-Alien-wxWidgets -- Building, finding and using wxWidgets binaries * perl-AppConfig -- Perl module for reading configuration files * perl-Array-Compare -- Perl extension for comparing arrays * perl-Authen-SASL -- SASL Authentication framework for Perl * perl-B-Keywords -- Lists of reserved barewords and symbol names * perl-Cache-Cache -- Generic cache interface and implementations * perl-Cairo -- Perl interface to the cairo library * perl-Carp-Assert -- Executable comments * perl-Carp-Assert-More -- Convenience wrappers around Carp::Assert * perl-Compress-Bzip2 -- Interface to Bzip2 compression library * perl-Config-IniFiles -- A module for reading .ini-style configuration files * perl-Config-Tiny -- Perl module for reading and writing .ini style configuration files * perl-CSS-Tiny -- Read/Write .css files with as little code as possible * perl-Data-Compare -- Compare perl data structures * perl-DBD-CSV -- DBI driver for CSV files * perl-DBD-SQLite -- Self Contained RDBMS in a DBI Driver * perl-DBD-XBase -- Perl module for reading and writing the dbf files * perl-Devel-Cover -- Code coverage metrics for Perl * perl-Devel-Cycle -- Find memory cycles in objects * perl-Digest-MD4 -- Perl interface to the MD4 Algorithm * perl-Email-Address -- RFC 2822 Address Parsing and Creation * perl-Email-MessageID -- Generate world unique message-ids * perl-Email-MIME -- Easy MIME message parsing * perl-Email-MIME-ContentType -- Parse a MIME Content-Type Header * perl-Email-MIME-Encodings -- Unified interface to MIME encoding and decoding * perl-Email-MIME-Modifier -- Modify Email::MIME Objects Easily * perl-Email-Simple -- Simple parsing of RFC2822 message format and headers * perl-Error -- Error Perl module * perl-Expect -- Expect for Perl * perl-Expect-Simple -- Wrapper around the Expect module * perl-ExtUtils-CBuilder -- Compile and link C code for Perl modules * perl-ExtUtils-Depends -- Easily build XS extensions that depend on XS extensions * perl-ExtUtils-ParseXS -- Module and a script for converting Perl XS code into C code * perl-ExtUtils-PkgConfig -- Simplistic interface to pkg-config * perl-File-Find-Rule-PPI -- Add support for PPI queries to File::Find::Rule * perl-File-HomeDir -- Get the home directory for yourself or other users * perl-File-Tail -- Perl extension for reading from continously updated files * perl-File-Which -- Portable implementation of the 'which' utility * perl-FreezeThaw -- Convert Perl structures to strings and back * perl-GD -- Perl interface to the GD graphics library * perl-GDGraph -- Graph generation package for Perl * perl-GDGraph3d -- 3D graph generation package for Perl * perl-GDTextUtil -- Text utilities for use with GD * perl-Geo-Constants -- Standard Geo:: constants * perl-Geo-Ellipsoids -- Standard Geo:: ellipsoids * perl-Geo-Forward -- Calculate geographic location from lat, lon, distance, and heading * perl-Geo-Functions -- Standard Geo:: functions * perl-Geo-Inverse -- Calculate geographic distance from a lat & lon pair * perl-Glib -- Perl interface to GLib * perl-GPS -- Perl interface to a GPS receiver that implements the Garmin protocol * perl-GPS-PRN -- Package for PRN - Object ID conversions * perl-GSSAPI -- Perl extension providing access to the GSSAPIv2 library * perl-Gtk2 -- Perl interface to the 2.x series of the Gimp Toolkit library * perl-Hook-LexWrap -- Lexically scoped subroutine wrappers * perl-HTML-Scrubber -- Library for scrubbing/sanitizing html * perl-HTML-Template -- Perl module to use HTML Templates * perl-HTTP-Proxy -- A pure Perl HTTP proxy * perl-HTTP-Recorder -- Record interaction with web sites * perl-HTTP-Request-Params -- Retrieve GET/POST Parameters from HTTP Requests * perl-HTTP-Server-Simple -- Very simple standalone HTTP daemon * perl-Image-Base -- Base class for loading, manipulating and saving images in Perl * perl-Image-Info -- Image meta information extraction module for Perl * perl-Image-Size -- Determine the size of images in several common formats in Perl * perl-Image-Xbm -- Load, create, manipulate and save xbm image files in Perl * perl-Image-Xpm -- Load, create, manipulate and save xpm image files in Perl * perl-IO-Capture -- Abstract Base Class to build modules to capture output * perl-IO-Interface -- Perl extension for accessing network card configuration information * perl-IO-Socket-SSL -- Perl library for transparent SSL * perl-IO-String -- Emulate file interface for in-core strings * perl-IO-Tty -- Perl interface to pseudo tty's * perl-IO-Zlib -- Perl IO:: style interface to Compress::Zlib * perl-IPC-Shareable -- Share Perl variables between processes * perl-IPC-SharedCache -- Perl module to manage a cache in SysV IPC shared memory * perl-List-MoreUtils -- Provide the stuff missing in List::Util * perl-Locale-Maketext-Fuzzy -- Maketext from already interpolated strings * perl-Log-Dispatch -- Dispatches messages to one or more outputs * perl-Log-Dispatch-FileRotate -- Log to files that archive/rotate themselves * perl-Log-Log4perl -- Log4j implementation for Perl * perl-Mail-Sender -- Module for sending mails with attachments through an SMTP server * perl-Mail-Sendmail -- Simple platform independent mailer for Perl * perl-MARC-Record -- Object-oriented abstraction of MARC record handling * perl-MLDBM -- Store multi-level hash structure in single level tied hash * perl-Module-CoreList -- Perl core modules indexed by perl versions * perl-Module-Find -- Find and use installed modules in a (sub)category * perl-Module-Locate -- Locate modules in the same fashion as "require" and "use" * perl-Module-ScanDeps -- Recursively scan Perl code for dependencies * perl-Module-Versions-Report -- Report versions of all modules in memory * perl-Net-GPSD -- Provides an object client interface to the gpsd server daemon * perl-Net-SNMP -- Object oriented interface to SNMP * perl-Net-SSLeay -- Perl extension for using OpenSSL * perl-PadWalker -- Play with other peoples' lexical variables
* perl-Perl-Critic -- Critique Perl source code for best-practices * perl-pmtools -- A suite of small programs to help manage Perl modules * perl-Pod-Coverage -- Checks if the documentation of a module is comprehensive * perl-Pod-Escapes -- Perl module for resolving POD escape sequences * perl-Pod-Simple -- Framework for parsing POD documentation * perl-Pod-Spell -- A formatter for spellchecking Pod * perl-Pod-Strip -- Remove POD from Perl code * perl-PPI -- Parse, Analyze and Manipulate Perl * perl-PPI-HTML -- Generate syntax-hightlighted HTML for Perl using PPI * perl-PPI-Tester -- A wxPerl-based interactive PPI debugger/tester * perl-Scalar-Properties -- Run-time properties on scalar variables * perl-Set-Scalar -- Basic set operations * perl-SNMP_Session -- SNMP support for Perl 5 * perl-Socket6 -- IPv6 related part of the C socket.h defines and structure manipulators * perl-SQL-Statement -- SQL parsing and processing engine * perl-String-Format -- Sprintf-like string formatting capabilities with arbitrary format definitions * perl-Sub-Uplevel -- Run a perl function in an upper stack frame * perl-Test-Builder-Tester -- Test runner for Test::Builder testsuites * perl-Test-Cmd -- Perl module for portable testing of commands and scripts * perl-Test-Differences -- Test strings and data structures and show differences if not ok * perl-Test-Exception -- Library of test functions for exception based Perl code * perl-Test-Expect -- Automated driving and testing of terminal-based programs * perl-Test-File -- Test file attributes * perl-Test-Manifest -- Test case module for Perl * perl-Test-Memory-Cycle -- Check for memory leaks and circular memory references * perl-Test-MockObject -- Perl extension for emulating troublesome interfaces * perl-Test-Number-Delta -- Compare the difference between numbers against a given tolerance * perl-Test-Object -- Thoroughly testing objects via registered handlers * perl-Test-Perl-Critic -- Use Perl::Critic in test programs * perl-Test-Pod -- Perl module for checking for POD errors in files * perl-Test-Pod-Coverage -- Check for pod coverage in your distribution * perl-Test-Spelling -- Check for spelling errors in POD files * perl-Test-SubCalls -- Track the number of times subs are called * perl-Test-Warn -- Perl extension to test methods for warnings * perl-Test-WWW-Mechanize -- Testing-specific WWW::Mechanize subclass * perl-TeX-Hyphen -- Hyphenate words using TeX's patterns * perl-Text-CSV_XS -- Comma-separated values manipulation routines * perl-Text-Template -- Expand template text with embedded Perl * perl-Text-WikiFormat -- Translate Wiki formatted text into other formats * perl-Tie-IxHash -- Ordered associative arrays for Perl * perl-Tree-DAG_Node -- Class for representing nodes in a tree * perl-UNIVERSAL-can -- Hack around people calling UNIVERSAL::can() as a function * perl-UNIVERSAL-isa -- Hack around module authors using UNIVERSAL::isa as a function * perl-WWW-Bugzilla -- Handles submission/update of bugzilla bugs via WWW::Mechanize * perl-WWW-Mechanize -- Automates web page form & link interaction * perl-Wx -- Interface to the wxWidgets cross-platform GUI toolkit * perl-XML-Simple -- Easy API to maintain XML in Perl * srecord -- Manipulate EPROM load files * swatch -- Tool for actively monitoring log files * syslog-ng -- Syslog replacement daemon * tetex-beamer -- A LaTeX class for producing presentations and slides * tetex-bytefield -- Create illustrations for network protocol specifications * tetex-perltex -- Define LaTeX macros in terms of Perl code * tetex-pgf -- Create PostScript and PDF graphics in TeX * tetex-xcolor -- Driver-independent color extensions for LaTeX and pdfLaTeX
~spot
On Mon, Nov 26, 2007 at 11:18:18AM -0500, Tom spot Callaway wrote:
On Sat, 2007-11-24 at 11:16 -0800, Chris Weyl wrote:
642 noarch 172 x86_64
814 total
I suspect we can ease the pain by coordinating a mass rebuild here, and just kicking off the rebuilds centrally. (e.g. an annointed Rebuilder In Chief)
The circular dependencies will be fun!
First things first, lets divide up all of jpo's perl packages tomorrow (assuming that he doesn't come out of AWOL status in the next 24 hours), so that we have owners to help push this through.
Here's the list of his packages (mostly perl), feel free to start staking claims on what you'd like:
[...]
* perl-DBD-XBase -- Perl module for reading and writing the dbf files
Being the author/upstream for DBD::XBase, I can take this ...
"Tom "spot" Callaway" tcallawa@redhat.com writes:
On Sat, 2007-11-24 at 11:16 -0800, Chris Weyl wrote:
642 noarch 172 x86_64
814 total
I suspect we can ease the pain by coordinating a mass rebuild here, and just kicking off the rebuilds centrally. (e.g. an annointed Rebuilder In Chief)
The circular dependencies will be fun!
First things first, lets divide up all of jpo's perl packages tomorrow (assuming that he doesn't come out of AWOL status in the next 24 hours), so that we have owners to help push this through.
Here's the list of his packages (mostly perl), feel free to start staking claims on what you'd like:
* perl-Compress-Bzip2 -- Interface to Bzip2 compression library * perl-DBD-CSV -- DBI driver for CSV files * perl-DBD-SQLite -- Self Contained RDBMS in a DBI Driver * perl-FreezeThaw -- Convert Perl structures to strings and back * perl-Log-Log4perl -- Log4j implementation for Perl * perl-Pod-Coverage -- Checks if the documentation of a module is comprehensive * perl-Pod-Escapes -- Perl module for resolving POD escape sequences * perl-Pod-Simple -- Framework for parsing POD documentation * perl-Pod-Spell -- A formatter for spellchecking Pod * perl-Pod-Strip -- Remove POD from Perl code * perl-SQL-Statement -- SQL parsing and processing engine * perl-Test-Pod -- Perl module for checking for POD errors in files * perl-Test-Pod-Coverage -- Check for pod coverage in your distribution * perl-Text-CSV_XS -- Comma-separated values manipulation routines
I can take these. Is there a good way to mass-convert these modules, or do we just do individual requests?
-RN
On Mon, 2007-11-26 at 16:04 -0500, Robin Norwood wrote:
* perl-Compress-Bzip2 -- Interface to Bzip2 compression library * perl-DBD-CSV -- DBI driver for CSV files * perl-DBD-SQLite -- Self Contained RDBMS in a DBI Driver * perl-FreezeThaw -- Convert Perl structures to strings and back * perl-Log-Log4perl -- Log4j implementation for Perl * perl-Pod-Coverage -- Checks if the documentation of a module is comprehensive * perl-Pod-Escapes -- Perl module for resolving POD escape sequences * perl-Pod-Simple -- Framework for parsing POD documentation * perl-Pod-Spell -- A formatter for spellchecking Pod * perl-Pod-Strip -- Remove POD from Perl code * perl-SQL-Statement -- SQL parsing and processing engine * perl-Test-Pod -- Perl module for checking for POD errors in files * perl-Test-Pod-Coverage -- Check for pod coverage in your distribution * perl-Text-CSV_XS -- Comma-separated values manipulation routinesI can take these. Is there a good way to mass-convert these modules, or do we just do individual requests?
I'll just handle them when I move everything else tomorrow. Anyone else interested in any of the remaining modules? (I'll take whatever remains...but I'd prefer to share the load)
~spot
"Tom "spot" Callaway" tcallawa@redhat.com writes:
On Mon, 2007-11-26 at 16:04 -0500, Robin Norwood wrote:
* perl-Compress-Bzip2 -- Interface to Bzip2 compression library * perl-DBD-CSV -- DBI driver for CSV files * perl-DBD-SQLite -- Self Contained RDBMS in a DBI Driver * perl-FreezeThaw -- Convert Perl structures to strings and back * perl-Log-Log4perl -- Log4j implementation for Perl * perl-Pod-Coverage -- Checks if the documentation of a module is comprehensive * perl-Pod-Escapes -- Perl module for resolving POD escape sequences * perl-Pod-Simple -- Framework for parsing POD documentation * perl-Pod-Spell -- A formatter for spellchecking Pod * perl-Pod-Strip -- Remove POD from Perl code * perl-SQL-Statement -- SQL parsing and processing engine * perl-Test-Pod -- Perl module for checking for POD errors in files * perl-Test-Pod-Coverage -- Check for pod coverage in your distribution * perl-Text-CSV_XS -- Comma-separated values manipulation routinesI can take these. Is there a good way to mass-convert these modules, or do we just do individual requests?
I'll just handle them when I move everything else tomorrow. Anyone else interested in any of the remaining modules? (I'll take whatever remains...but I'd prefer to share the load)
I can also handle some of the excess, but there aren't any in particular that I'm interested in other than the ones quoted above.
-RN
On Mon, Nov 26, 2007 at 04:08:22PM -0500, Tom spot Callaway wrote:
I'll just handle them when I move everything else tomorrow. Anyone else interested in any of the remaining modules? (I'll take whatever remains...but I'd prefer to share the load)
Feel free to put me down as a co-maintainer on any of the remaining perl-* packages.
Steve
On Mon, 2007-11-26 at 16:08 -0500, Tom "spot" Callaway wrote:
On Mon, 2007-11-26 at 16:04 -0500, Robin Norwood wrote:
I can take these. Is there a good way to mass-convert these modules, or do we just do individual requests?
I'll just handle them when I move everything else tomorrow. Anyone else interested in any of the remaining modules? (I'll take whatever remains...but I'd prefer to share the load)
I'd be volunteering to assist maintaining/co-maintain all of the perl-modules and to act as principle maintainer for those which are direct deps of rt3 (I haven't checked which would qualify as such. Probably something similar to Steve's list).
But: I'd also prefer to share the load and prefer to see collective maintainership to be encouraged, so .. proposal:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
Ralf
On Nov 26, 2007 7:40 PM, Ralf Corsepius rc040203@freenet.de wrote:
On Mon, 2007-11-26 at 16:08 -0500, Tom "spot" Callaway wrote:
On Mon, 2007-11-26 at 16:04 -0500, Robin Norwood wrote:
I can take these. Is there a good way to mass-convert these modules, or do we just do individual requests?
I'll just handle them when I move everything else tomorrow. Anyone else interested in any of the remaining modules? (I'll take whatever remains...but I'd prefer to share the load)
I'd be volunteering to assist maintaining/co-maintain all of the perl-modules and to act as principle maintainer for those which are direct deps of rt3 (I haven't checked which would qualify as such. Probably something similar to Steve's list).
But: I'd also prefer to share the load and prefer to see collective maintainership to be encouraged, so .. proposal:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
+1! This is exactly what we should be doing.
-Chris
On Tue, Nov 27, 2007 at 04:40:33AM +0100, Ralf Corsepius wrote:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
This seems to me to be a very good idea.
-- Pat
On Tue, 2007-11-27 at 04:40 +0100, Ralf Corsepius wrote:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
Sure, this is acceptable to me. I just need to know who the "co maintainers" will be, packages cannot be owned by the perl SIG user.
As an aside, I don't ACL any of my perl packages, specifically to allow other perl SIG members who need to make changes while I am unavailable.
~spot
On Tue, 2007-11-27 at 09:00 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 04:40 +0100, Ralf Corsepius wrote:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
Sure, this is acceptable to me. I just need to know who the "co maintainers" will be, packages cannot be owned by the perl SIG user.
Why not?
As an aside, I don't ACL any of my perl packages, specifically to allow other perl SIG members who need to make changes while I am unavailable.
The same has applied to my packages, ever since they exist.
Ralf
On Tue, 2007-11-27 at 16:00 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 09:00 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 04:40 +0100, Ralf Corsepius wrote:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
Sure, this is acceptable to me. I just need to know who the "co maintainers" will be, packages cannot be owned by the perl SIG user.
Why not?
Not sure. I think it has to do with the fact that the perl-SIG isn't a legal entity, and thus, cannot sign the CLA.
As is, its really not an issue, as I don't intend to put acls on anything, its merely a question of who wants to see the bugzillas personally as opposed to through the perl-SIG email.
~spot
On Tue, 2007-11-27 at 10:04 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 16:00 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 09:00 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 04:40 +0100, Ralf Corsepius wrote:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
Sure, this is acceptable to me. I just need to know who the "co maintainers" will be, packages cannot be owned by the perl SIG user.
Why not?
Not sure. I think it has to do with the fact that the perl-SIG isn't a legal entity, and thus, cannot sign the CLA.
Hmm, is this a technical limitations of the fedora infrastructure or a legal issue? I would not understand the latter.
As is, its really not an issue, as I don't intend to put acls on anything, its merely a question of who wants to see the bugzillas personally as opposed to through the perl-SIG email.
So you indent to assign ownership to yourself but to allow perl-sig member to work on your packages?
IMO, this doesn't encourage "perl-sig seniors" to work on these packages, because it doesn't make the difference between "collectively maintained" packages and packages being maintained by "individuals who will shoot" when touching your packages apparent.
OK, the latter group could apply ACLs, but ... you are loosing the "marketing factor" of "collective maintainership".
Ralf
On Tue, 2007-11-27 at 16:13 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 10:04 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 16:00 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 09:00 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 04:40 +0100, Ralf Corsepius wrote:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
Sure, this is acceptable to me. I just need to know who the "co maintainers" will be, packages cannot be owned by the perl SIG user.
Why not?
Not sure. I think it has to do with the fact that the perl-SIG isn't a legal entity, and thus, cannot sign the CLA.
Hmm, is this a technical limitations of the fedora infrastructure or a legal issue? I would not understand the latter.
I think its a bit of both, as the SIG can't sign the CLA, and the infrastructure won't let users who haven't signed the CLA own anything.
As is, its really not an issue, as I don't intend to put acls on anything, its merely a question of who wants to see the bugzillas personally as opposed to through the perl-SIG email.
So you indent to assign ownership to yourself but to allow perl-sig member to work on your packages?
IMO, this doesn't encourage "perl-sig seniors" to work on these packages, because it doesn't make the difference between "collectively maintained" packages and packages being maintained by "individuals who will shoot" when touching your packages apparent.
I'm not actually sure how to accomplish "collective" maintainership, in the sense that you want it. Nor do I really want to lock them down via ACLs so only perl-sig elites can touch them.
I think the packages still need a primary maintainer, and then can have as many co-maintainers as desired.
~spot
On Nov 27, 2007 11:57 AM, Tom spot Callaway tcallawa@redhat.com wrote:
On Tue, 2007-11-27 at 16:13 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 10:04 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 16:00 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 09:00 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 04:40 +0100, Ralf Corsepius wrote:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
Sure, this is acceptable to me. I just need to know who the "co maintainers" will be, packages cannot be owned by the perl SIG user.
Why not?
Not sure. I think it has to do with the fact that the perl-SIG isn't a legal entity, and thus, cannot sign the CLA.
Hmm, is this a technical limitations of the fedora infrastructure or a legal issue? I would not understand the latter.
I think its a bit of both, as the SIG can't sign the CLA, and the infrastructure won't let users who haven't signed the CLA own anything.
Is there a way to enforce group ownership such that perl-sig members must also be members of cla-done? If we can do that, it should be a moot point... (Transitive property of CLA signing... heh)
As is, its really not an issue, as I don't intend to put acls on anything, its merely a question of who wants to see the bugzillas personally as opposed to through the perl-SIG email.
So you indent to assign ownership to yourself but to allow perl-sig member to work on your packages?
IMO, this doesn't encourage "perl-sig seniors" to work on these packages, because it doesn't make the difference between "collectively maintained" packages and packages being maintained by "individuals who will shoot" when touching your packages apparent.
I'm not actually sure how to accomplish "collective" maintainership, in the sense that you want it. Nor do I really want to lock them down via ACLs so only perl-sig elites can touch them.
I think the packages still need a primary maintainer, and then can have as many co-maintainers as desired.
I think the idea here is more of a way to put a better stamp of collective ownership here, not enable a lock down to us elites (and here I thought I was just another plebian<grin>). While possibly more symbolic than not, symbolisim is important, and I think it makes sense to do if we can find a reasonable way.
-Chris
On Tue, 2007-11-27 at 13:26 -0800, Chris Weyl wrote:
I think the idea here is more of a way to put a better stamp of collective ownership here, not enable a lock down to us elites (and here I thought I was just another plebian<grin>). While possibly more symbolic than not, symbolisim is important, and I think it makes sense to do if we can find a reasonable way.
OK, I'm on board with this. What I need is a list of the willing, to be comaintainers on this set of packages. Here's the list as I see it right now:
Tom Callaway (spot) Ralf Corsepius (corsepiu) Patrice Dumas (pertusus) Paul Howarth (pghmcfc) Robin Norwood (rnorwood) Steven Pritchard (steve) Chris Weyl (cweyl)
Anyone else? (I'll wait until tomorrow to add the comaintainers)
All of jpo's packages have a new maintainer now, here's the breakdown:
Tom Callaway (aka, no one asked for it explicitly)
* perl-Alien-wxWidgets -- Building, finding and using wxWidgets binaries * perl-AppConfig -- Perl module for reading configuration files * perl-Array-Compare -- Perl extension for comparing arrays * perl-Cairo -- Perl interface to the cairo library * perl-Carp-Assert -- Executable comments * perl-Carp-Assert-More -- Convenience wrappers around Carp::Assert * perl-Config-IniFiles -- A module for reading .ini-style configuration files * perl-Data-Compare -- Compare perl data structures * perl-DBD-XBase -- Perl module for reading and writing the dbf files * perl-Devel-Cover -- Code coverage metrics for Perl * perl-Email-Address -- RFC 2822 Address Parsing and Creation * perl-Email-MessageID -- Generate world unique message-ids * perl-Email-MIME -- Easy MIME message parsing * perl-Email-MIME-ContentType -- Parse a MIME Content-Type Header * perl-Email-MIME-Encodings -- Unified interface to MIME encoding and decoding * perl-Email-MIME-Modifier -- Modify Email::MIME Objects Easily * perl-Email-Simple -- Simple parsing of RFC2822 message format and headers * perl-ExtUtils-PkgConfig -- Simplistic interface to pkg-config * perl-File-Find-Rule-PPI -- Add support for PPI queries to File::Find::Rule * perl-File-HomeDir -- Get the home directory for yourself or other users * perl-File-Tail -- Perl extension for reading from continously updated files * perl-File-Which -- Portable implementation of the 'which' utility * perl-GD -- Perl interface to the GD graphics library * perl-GDGraph -- Graph generation package for Perl * perl-GDGraph3d -- 3D graph generation package for Perl * perl-GDTextUtil -- Text utilities for use with GD * perl-Geo-Constants -- Standard Geo:: constants * perl-Geo-Ellipsoids -- Standard Geo:: ellipsoids * perl-Geo-Forward -- Calculate geographic location from lat, lon, distance, and heading * perl-Geo-Functions -- Standard Geo:: functions * perl-Geo-Inverse -- Calculate geographic distance from a lat & lon pair * perl-Glib -- Perl interface to GLib * perl-GPS -- Perl interface to a GPS receiver that implements the Garmin protocol * perl-GPS-PRN -- Package for PRN - Object ID conversions * perl-Gtk2 -- Perl interface to the 2.x series of the Gimp Toolkit library * perl-Hook-LexWrap -- Lexically scoped subroutine wrappers * perl-HTML-Scrubber -- Library for scrubbing/sanitizing html * perl-HTML-Template -- Perl module to use HTML Templates * perl-HTTP-Proxy -- A pure Perl HTTP proxy * perl-HTTP-Recorder -- Record interaction with web sites * perl-HTTP-Request-Params -- Retrieve GET/POST Parameters from HTTP Requests * perl-HTTP-Server-Simple -- Very simple standalone HTTP daemon * perl-Image-Base -- Base class for loading, manipulating and saving images in Perl * perl-Image-Info -- Image meta information extraction module for Perl * perl-Image-Size -- Determine the size of images in several common formats in Perl * perl-Image-Xbm -- Load, create, manipulate and save xbm image files in Perl * perl-Image-Xpm -- Load, create, manipulate and save xpm image files in Perl * perl-IO-Capture -- Abstract Base Class to build modules to capture output * perl-IO-Interface -- Perl extension for accessing network card configuration information * perl-IO-Tty -- Perl interface to pseudo tty's * perl-IPC-Shareable -- Share Perl variables between processes * perl-IPC-SharedCache -- Perl module to manage a cache in SysV IPC shared memory * perl-Locale-Maketext-Fuzzy -- Maketext from already interpolated strings * perl-Log-Dispatch -- Dispatches messages to one or more outputs * perl-Log-Dispatch-FileRotate -- Log to files that archive/rotate themselves * perl-Mail-Sender -- Module for sending mails with attachments through an SMTP server * perl-Mail-Sendmail -- Simple platform independent mailer for Perl * perl-MARC-Record -- Object-oriented abstraction of MARC record handling * perl-Net-GPSD -- Provides an object client interface to the gpsd server daemon * perl-Net-SNMP -- Object oriented interface to SNMP * perl-PPI -- Parse, Analyze and Manipulate Perl * perl-PPI-HTML -- Generate syntax-hightlighted HTML for Perl using PPI * perl-PPI-Tester -- A wxPerl-based interactive PPI debugger/tester * perl-Scalar-Properties -- Run-time properties on scalar variables * perl-Set-Scalar -- Basic set operations * perl-SNMP_Session -- SNMP support for Perl 5 * perl-String-Format -- Sprintf-like string formatting capabilities with arbitrary format definitions * perl-Test-Cmd -- Perl module for portable testing of commands and scripts * perl-Test-Differences -- Test strings and data structures and show differences if not ok * perl-Test-File -- Test file attributes * perl-Test-Manifest -- Test case module for Perl * perl-Test-MockObject -- Perl extension for emulating troublesome interfaces * perl-Test-Number-Delta -- Compare the difference between numbers against a given tolerance * perl-Test-Object -- Thoroughly testing objects via registered handlers * perl-Test-Spelling -- Check for spelling errors in POD files * perl-Test-SubCalls -- Track the number of times subs are called * perl-Test-Warn -- Perl extension to test methods for warnings * perl-Text-Template -- Expand template text with embedded Perl * perl-Text-WikiFormat -- Translate Wiki formatted text into other formats * perl-Tie-IxHash -- Ordered associative arrays for Perl * perl-Tree-DAG_Node -- Class for representing nodes in a tree * perl-UNIVERSAL-can -- Hack around people calling UNIVERSAL::can() as a function * perl-UNIVERSAL-isa -- Hack around module authors using UNIVERSAL::isa as a function * perl-Wx -- Interface to the wxWidgets cross-platform GUI toolkit
Chris Weyl
* perl-B-Keywords -- Lists of reserved barewords and symbol names * perl-Config-Tiny -- Perl module for reading and writing .ini style configuration files * perl-CSS-Tiny -- Read/Write .css files with as little code as possible * perl-Expect -- Expect for Perl * perl-Expect-Simple -- Wrapper around the Expect module * perl-List-MoreUtils -- Provide the stuff missing in List::Util * perl-Module-Find -- Find and use installed modules in a (sub)category * perl-Module-Locate -- Locate modules in the same fashion as "require" and "use" * perl-Module-Versions-Report -- Report versions of all modules in memory * perl-Perl-Critic -- Critique Perl source code for best-practices * perl-pmtools -- A suite of small programs to help manage Perl modules * perl-Test-Expect -- Automated driving and testing of terminal-based programs * perl-Test-Perl-Critic -- Use Perl::Critic in test programs * perl-Test-WWW-Mechanize -- Testing-specific WWW::Mechanize subclass * perl-WWW-Bugzilla -- Handles submission/update of bugzilla bugs via WWW::Mechanize * perl-WWW-Mechanize -- Automates web page form & link interaction
Paul Howarth
* perl-Digest-MD4 -- Perl interface to the MD4 Algorithm
Steven Pritchard
* perl-Authen-SASL -- SASL Authentication framework for Perl * perl-Cache-Cache -- Generic cache interface and implementations * perl-DBD-SQLite (COMAINT) -- Self Contained RDBMS in a DBI Driver * perl-Devel-Cycle -- Find memory cycles in objects * perl-Error -- Error Perl module * perl-ExtUtils-CBuilder -- Compile and link C code for Perl modules * perl-ExtUtils-Depends -- Easily build XS extensions that depend on XS extensions * perl-ExtUtils-ParseXS -- Module and a script for converting Perl XS code into C code * perl-FreezeThaw (COMAINT) -- Convert Perl structures to strings and back * perl-GSSAPI -- Perl extension providing access to the GSSAPIv2 library * perl-MLDBM -- Store multi-level hash structure in single level tied hash * perl-Module-CoreList -- Perl core modules indexed by perl versions * perl-Module-ScanDeps -- Recursively scan Perl code for dependencies * perl-PadWalker -- Play with other peoples' lexical variables * perl-Pod-Coverage (COMAINT)-- Checks if the documentation of a module is comprehensive * perl-Pod-Escapes (COMAINT)-- Perl module for resolving POD escape sequences * perl-Pod-Simple (COMAINT) -- Framework for parsing POD documentation * perl-Sub-Uplevel -- Run a perl function in an upper stack frame * perl-Test-Builder-Tester -- Test runner for Test::Builder testsuites * perl-Test-Exception -- Library of test functions for exception based Perl code * perl-Test-Memory-Cycle -- Check for memory leaks and circular memory references * perl-Test-Pod (COMAINT) -- Perl module for checking for POD errors in files * perl-Test-Pod-Coverage (COMAINT) -- Check for pod coverage in your distribution * perl-TeX-Hyphen -- Hyphenate words using TeX's patterns
Robin Norwood (rnorwood)
* perl-Compress-Bzip2 -- Interface to Bzip2 compression library * perl-DBD-CSV -- DBI driver for CSV files * perl-DBD-SQLite -- Self Contained RDBMS in a DBI Driver * perl-FreezeThaw -- Convert Perl structures to strings and back * perl-Log-Log4perl -- Log4j implementation for Perl * perl-Pod-Coverage -- Checks if the documentation of a module is comprehensive * perl-Pod-Escapes -- Perl module for resolving POD escape sequences * perl-Pod-Simple -- Framework for parsing POD documentation * perl-Pod-Spell -- A formatter for spellchecking Pod * perl-Pod-Strip -- Remove POD from Perl code * perl-SQL-Statement -- SQL parsing and processing engine * perl-Test-Pod -- Perl module for checking for POD errors in files * perl-Test-Pod-Coverage -- Check for pod coverage in your distribution * perl-Text-CSV_XS -- Comma-separated values manipulation routines
On Tue, Nov 27, 2007 at 05:16:49PM -0500, Tom spot Callaway wrote:
Tom Callaway (aka, no one asked for it explicitly)
* perl-Alien-wxWidgets -- Building, finding and using wxWidgets binaries * perl-AppConfig -- Perl module for reading configuration files * perl-Array-Compare -- Perl extension for comparing arrays * perl-Cairo -- Perl interface to the cairo library * perl-Carp-Assert -- Executable comments * perl-Carp-Assert-More -- Convenience wrappers around Carp::Assert * perl-Config-IniFiles -- A module for reading .ini-style configuration files * perl-Data-Compare -- Compare perl data structures * perl-DBD-XBase -- Perl module for reading and writing the dbf files
Ummm -- I've asked for perl-DBD-XBase ...
On Tue, 2007-11-27 at 14:57 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 16:13 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 10:04 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 16:00 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 09:00 -0500, Tom "spot" Callaway wrote:
On Tue, 2007-11-27 at 04:40 +0100, Ralf Corsepius wrote:
Can't we agree upon to collectively maintain these "soon to be orphaned" packages in general? (Q: Who is "we" - perl-sig "seniors"? Everybody who maintains, say, more than 10 perl-modules?)
IMO, this doesn't encourage "perl-sig seniors" to work on these packages, because it doesn't make the difference between "collectively maintained" packages and packages being maintained by "individuals who will shoot" when touching your packages apparent.
I'm not actually sure how to accomplish "collective" maintainership, in the sense that you want it.
What I had in mind was to let one of * perl-sig or * an "alias" (whatever this would be) to a group of people to own a package. or * an explicit list of "perl seniors" to own the package.
I thought, at minimum the latter was technically possible.
Nor do I really want to lock them down via ACLs so only perl-sig elites can touch them.
I think the packages still need a primary maintainer, and then can have as many co-maintainers as desired.
Seems to me, as if Fedora doesn't support collective maintainership ://
Ralf
On Wed, 2007-11-28 at 03:58 +0100, Ralf Corsepius wrote:
Seems to me, as if Fedora doesn't support collective maintainership ://
Its a technicality. There is no difference in rights or permissions between primary maintainers and comaintainers, except that the packagedb requires there be a primary.
~spot
On Wed, Nov 28, 2007 at 07:40:15AM -0500, Tom spot Callaway wrote:
On Wed, 2007-11-28 at 03:58 +0100, Ralf Corsepius wrote:
Seems to me, as if Fedora doesn't support collective maintainership ://
Its a technicality. There is no difference in rights or permissions between primary maintainers and comaintainers, except that the packagedb requires there be a primary.
I think that Ralf point is not about having many comaintainers, but group comaintainers. Looks like the packagedb doesn't allow that.
-- Pat
On Wed, 2007-11-28 at 14:05 +0100, Patrice Dumas wrote:
On Wed, Nov 28, 2007 at 07:40:15AM -0500, Tom spot Callaway wrote:
On Wed, 2007-11-28 at 03:58 +0100, Ralf Corsepius wrote:
Seems to me, as if Fedora doesn't support collective maintainership ://
Its a technicality. There is no difference in rights or permissions between primary maintainers and comaintainers, except that the packagedb requires there be a primary.
I think that Ralf point is not about having many comaintainers, but group comaintainers. Looks like the packagedb doesn't allow that.
Almost.
What I wanted to find is how Fedora supports and destinguishes:
a) a "principal" w/ several co-maintainers under his directions b) "free for a specific group with changing members" e.g. free for perl-sig, free for FPG, free for "sponsors". c) "free for anybody" (free for any Fedora all CLA-signors) d) "orphaned"
My understanding of what Spot wrote is: Fedora doesn't support b) and c). He can't avoid folding them into a).
IMO, this lets appear "collective maintainership" as a "closed group/intriguing circle", because doesn't let appear such packages as "open for interested volunteers", but implies explicit "appointment" and explict knowledge about how somebody made it into such a "circle".
Or differently: one year ahead, nobody will remember these packages are open, because they can't be distinguished from the usual "closed circles" maintaining packages otherwise.
Ralf
On Wed, Nov 28, 2007 at 02:26:38PM +0100, Ralf Corsepius wrote:
What I wanted to find is how Fedora supports and destinguishes:
a) a "principal" w/ several co-maintainers under his directions b) "free for a specific group with changing members" e.g. free for perl-sig, free for FPG, free for "sponsors". c) "free for anybody" (free for any Fedora all CLA-signors) d) "orphaned"
My understanding of what Spot wrote is: Fedora doesn't support b) and c). He can't avoid folding them into a).
c) is technicaly possible, it corresponds with 'group members can commit?' selected. However, in general, having this selected doesn't mean that the maintainer is really willing to let everybody touch the package.
Or differently: one year ahead, nobody will remember these packages are open, because they can't be distinguished from the usual "closed circles" maintaining packages otherwise.
Right.
Maybe the solution could simply be to be able to add some comments in the pacakgedb, telling who is really allowed to touch the package? and select 'group members can commit?'.
-- Pat
On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
Maybe the solution could simply be to be able to add some comments in the pacakgedb, telling who is really allowed to touch the package? and select 'group members can commit?'.
IMO, the easiest approach would be to use "perl-sig" or similar (eg. an "email alias" or a packagedb "alias" (should such thing exist)) as owner ;)
Ralf
On Wed, 2007-11-28 at 14:46 +0100, Ralf Corsepius wrote:
On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
Maybe the solution could simply be to be able to add some comments in the pacakgedb, telling who is really allowed to touch the package? and select 'group members can commit?'.
IMO, the easiest approach would be to use "perl-sig" or similar (eg. an "email alias" or a packagedb "alias" (should such thing exist)) as owner ;)
Which, we can't do, without dirty hacks, currently.
You should talk to Toshio about this.
~spot
On Wed, 2007-11-28 at 09:25 -0500, Tom "spot" Callaway wrote:
On Wed, 2007-11-28 at 14:46 +0100, Ralf Corsepius wrote:
On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
Maybe the solution could simply be to be able to add some comments in the pacakgedb, telling who is really allowed to touch the package? and select 'group members can commit?'.
IMO, the easiest approach would be to use "perl-sig" or similar (eg. an "email alias" or a packagedb "alias" (should such thing exist)) as owner ;)
Which, we can't do, without dirty hacks, currently.
You should talk to Toshio about this.
Me? I don't have a problem when the packagedb stuff denotes you to maintain all these packages all alone, because nobody can distinguish them from "true Spot" packages nor when these packages doen't receive cpancheck from because of this.
This is solely your problem - Sooner or later.
Ralf
On Wed, 2007-11-28 at 15:41 +0100, Ralf Corsepius wrote:
On Wed, 2007-11-28 at 09:25 -0500, Tom "spot" Callaway wrote:
On Wed, 2007-11-28 at 14:46 +0100, Ralf Corsepius wrote:
On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
Maybe the solution could simply be to be able to add some comments in the pacakgedb, telling who is really allowed to touch the package? and select 'group members can commit?'.
IMO, the easiest approach would be to use "perl-sig" or similar (eg. an "email alias" or a packagedb "alias" (should such thing exist)) as owner ;)
Which, we can't do, without dirty hacks, currently.
You should talk to Toshio about this.
Me? I don't have a problem when the packagedb stuff denotes you to maintain all these packages all alone, because nobody can distinguish them from "true Spot" packages nor when these packages doen't receive cpancheck from because of this.
This is solely your problem - Sooner or later.
I don't have any problem with this. They'll show up in cpancheck as packages that I need to fix. You're the one who is getting worked up over technical limitations.
~spot
On Wed, Nov 28, 2007 at 09:46:32AM -0500, Tom spot Callaway wrote:
I don't have any problem with this. They'll show up in cpancheck as packages that I need to fix. You're the one who is getting worked up over technical limitations.
And where would one find this cpancheck that knows how to check the packagedb? :-)
Steve
On Wed, 2007-11-28 at 09:22 -0600, Steven Pritchard wrote:
On Wed, Nov 28, 2007 at 09:46:32AM -0500, Tom spot Callaway wrote:
I don't have any problem with this. They'll show up in cpancheck as packages that I need to fix. You're the one who is getting worked up over technical limitations.
And where would one find this cpancheck that knows how to check the packagedb? :-)
Yet another individual facing this regression?
Am using a script to restore a local owners.list from the packagedb and than run a slight modified derivative of a very early version of your script.
<snip> #!/bin/sh
owners=$(HOME)/src/fedora/local
lftp -c get "https://admin.fedoraproject.org/pkgdb/acls/bugzilla?tg_format=plain" \ -o $owners/owners.list.raw
cat $owners/owners.list.raw | grep '^Fedora|' > $owners/owners.fedora.list <snip>
As my local cpancheck only checks for packages being maintained by me, ... it will not check spots packages.
So be it - He receives what he wants.
Collective maintainership has failed due to infrastructural defects - period.
Ralf
On Wed, 2007-11-28 at 09:22 -0600, Steven Pritchard wrote:
On Wed, Nov 28, 2007 at 09:46:32AM -0500, Tom spot Callaway wrote:
I don't have any problem with this. They'll show up in cpancheck as packages that I need to fix. You're the one who is getting worked up over technical limitations.
And where would one find this cpancheck that knows how to check the packagedb? :-)
http://fedoraproject.org/wiki/PackageMaintainers/UsefulScripts
That cpancheck seems fully capable of checking the packagedb.
~spot
On Wed, Nov 28, 2007 at 01:05:45PM -0500, Tom spot Callaway wrote:
http://fedoraproject.org/wiki/PackageMaintainers/UsefulScripts
That cpancheck seems fully capable of checking the packagedb.
I'll be damned. So it does.
Isn't collaborative development great? ;-)
Steve
On Nov 28, 2007 6:25 AM, Tom spot Callaway tcallawa@redhat.com wrote:
On Wed, 2007-11-28 at 14:46 +0100, Ralf Corsepius wrote:
On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
Maybe the solution could simply be to be able to add some comments in the pacakgedb, telling who is really allowed to touch the package? and select 'group members can commit?'.
IMO, the easiest approach would be to use "perl-sig" or similar (eg. an "email alias" or a packagedb "alias" (should such thing exist)) as owner ;)
Which, we can't do, without dirty hacks, currently.
You should talk to Toshio about this.
I'm unfamiliar with the limitations of the accounts/grouping/packagedb system, but if we can have the accounts system enforce a requirement that members of one group must be a subset of another group (e.g. perl-sig group members must be members of the cla-done group), would this satisfy the requirement that all package owners have signed CLA's? Can we have a group own a package?
I'm buying what Ralf is saying here: to attempt to have collective ownership via individual ownership and extensive co-maintainers is another variant of "dirty hacks".
Of course, I may be totally misunderstanding how the systems work together here :)
-Chris
On Wed, 2007-11-28 at 08:09 -0800, Chris Weyl wrote:
I'm buying what Ralf is saying here: to attempt to have collective ownership via individual ownership and extensive co-maintainers is another variant of "dirty hacks".
Of course, I may be totally misunderstanding how the systems work together here :)
The perl-SIG is not a user, hence it cannot own packages.
Reference:
"Note: You may be asked to CC fedora-perl-devel-list on a perl package. This can be done with the username "perl-sig". This is presently a user, not a group so it cannot be used as an owner or comaintainer, only for CC."
http://fedoraproject.org/wiki/CVSPrivate
Any more than that, I do not know, and you should be talking to Toshio about making possible improvements. Please do not shoot the messenger. :)
~spot
On Wed, 2007-11-28 at 11:58 -0500, Tom "spot" Callaway wrote:
On Wed, 2007-11-28 at 08:09 -0800, Chris Weyl wrote:
I'm buying what Ralf is saying here: to attempt to have collective ownership via individual ownership and extensive co-maintainers is another variant of "dirty hacks".
Of course, I may be totally misunderstanding how the systems work together here :)
The perl-SIG is not a user,
And what prevents you from making it one, or creating email alias you could use, instead?
Reference:
"Note: You may be asked to CC fedora-perl-devel-list on a perl package. This can be done with the username "perl-sig". This is presently a user, not a group so it cannot be used as an owner or comaintainer, only for CC."
http://fedoraproject.org/wiki/CVSPrivate
Any more than that, I do not know, and you should be talking to Toshio about making possible improvements. Please do not shoot the messenger. :)
Yes, it the appropriate target isn't you.
All I can add, provided the limitations of current implementation, I'd suggest you to put everybody having volunteered explicitly into InitialCC list or directly into the Owner field (AFAICT, multiple owners are possible).
This would allow scripted update checks (cpancheck) without accidentally interfering with those packages you have acls in effect (e.g. the main perl package)
Also it would be appropriate to contact FESCO (ain't you a FESCO member?) to have Toshio implement this missing feature.
Ralf
Chris, if this bounces from the list, feel free to forward it there.
Chris Weyl wrote:
On Nov 28, 2007 6:25 AM, Tom spot Callaway tcallawa@redhat.com wrote:
On Wed, 2007-11-28 at 14:46 +0100, Ralf Corsepius wrote:
On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
Maybe the solution could simply be to be able to add some comments in the pacakgedb, telling who is really allowed to touch the package? and select 'group members can commit?'.
IMO, the easiest approach would be to use "perl-sig" or similar (eg. an "email alias" or a packagedb "alias" (should such thing exist)) as owner ;)
Which, we can't do, without dirty hacks, currently.
You should talk to Toshio about this.
I'm unfamiliar with the limitations of the accounts/grouping/packagedb system, but if we can have the accounts system enforce a requirement that members of one group must be a subset of another group (e.g. perl-sig group members must be members of the cla-done group), would this satisfy the requirement that all package owners have signed CLA's?
Yes, this part is currently possible. We're changing over to an LDAP backend and better web frontend in a few months, though, so I don't know the limitations and abilities of that system.
One other thing is that people would need to be a member of cvsextras as well as cla_done in order to login to the cvs server.
Can we have a group own a package?
Not currently. Pseudo groups like the current perl-sig can own a package but a real group cannot. This requires a bit of recoding in order to change.
OTOH, letting a group be comaintainer (equivalent rights to owner) of a package is fairly complete (there are a few places where we are currently checking for cvsextras explicitly, but we can change those to list other groups without much difficulty.
The biggest area where group ownership won't work precisely right at this time is in the webUI. cvsextras is our only current group and we aren't showing all the acls for it, just the commit acl. For the perl-sig, I imagine that you'll want to have at least commit, watchbugzilla, and watchcommits set. I can code this into the commandline tool admins are using to set permissions but doing the same for the webUI will require some rethinking of what it should look like and how complex it should be.
I'm buying what Ralf is saying here: to attempt to have collective ownership via individual ownership and extensive co-maintainers is another variant of "dirty hacks".
Agreed. If you want to move forward with getting this working in the packagedb you should open a ticket[1]_, we can try and record all the changes we need in the packagedb and account system to enable the change. Then I can talk to the FAS2 author to be sure it won't cause him any grief when we migrate and we can code something up.
We're shooting to deploy FAS2 in February. So if there are interdependencies between FAS and pkgdb that should wait on that deployment we would do so after that.
.. _[1]: https://hosted.fedoraproject.org/projects/packagedb/newticket -Toshio
Looks like this didn't make it :)
---------- Forwarded message ---------- From: Toshio Kuratomi a.badger@gmail.com Date: Nov 28, 2007 9:21 AM Subject: Re: time for perl 5.10.x in devel? To: Chris Weyl cweyl@alumni.drew.edu, fedora-perl-devel-list@redhat.com
Chris, if this bounces from the list, feel free to forward it there.
Chris Weyl wrote:
On Nov 28, 2007 6:25 AM, Tom spot Callaway tcallawa@redhat.com wrote:
On Wed, 2007-11-28 at 14:46 +0100, Ralf Corsepius wrote:
On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
Maybe the solution could simply be to be able to add some comments in the pacakgedb, telling who is really allowed to touch the package? and select 'group members can commit?'.
IMO, the easiest approach would be to use "perl-sig" or similar (eg. an "email alias" or a packagedb "alias" (should such thing exist)) as owner ;)
Which, we can't do, without dirty hacks, currently.
You should talk to Toshio about this.
I'm unfamiliar with the limitations of the accounts/grouping/packagedb system, but if we can have the accounts system enforce a requirement that members of one group must be a subset of another group (e.g. perl-sig group members must be members of the cla-done group), would this satisfy the requirement that all package owners have signed CLA's?
Yes, this part is currently possible. We're changing over to an LDAP backend and better web frontend in a few months, though, so I don't know the limitations and abilities of that system.
One other thing is that people would need to be a member of cvsextras as well as cla_done in order to login to the cvs server.
Can we have a group own a package?
Not currently. Pseudo groups like the current perl-sig can own a package but a real group cannot. This requires a bit of recoding in order to change.
OTOH, letting a group be comaintainer (equivalent rights to owner) of a package is fairly complete (there are a few places where we are currently checking for cvsextras explicitly, but we can change those to list other groups without much difficulty.
The biggest area where group ownership won't work precisely right at this time is in the webUI. cvsextras is our only current group and we aren't showing all the acls for it, just the commit acl. For the perl-sig, I imagine that you'll want to have at least commit, watchbugzilla, and watchcommits set. I can code this into the commandline tool admins are using to set permissions but doing the same for the webUI will require some rethinking of what it should look like and how complex it should be.
I'm buying what Ralf is saying here: to attempt to have collective ownership via individual ownership and extensive co-maintainers is another variant of "dirty hacks".
Agreed. If you want to move forward with getting this working in the packagedb you should open a ticket[1]_, we can try and record all the changes we need in the packagedb and account system to enable the change. Then I can talk to the FAS2 author to be sure it won't cause him any grief when we migrate and we can code something up.
We're shooting to deploy FAS2 in February. So if there are interdependencies between FAS and pkgdb that should wait on that deployment we would do so after that.
.. _[1]: https://hosted.fedoraproject.org/projects/packagedb/newticket -Toshio
On Mon, Nov 26, 2007 at 11:18:18AM -0500, Tom spot Callaway wrote:
The circular dependencies will be fun!
Hopefully a lot of those have been resolved with the EPEL rebuild.
First things first, lets divide up all of jpo's perl packages tomorrow (assuming that he doesn't come out of AWOL status in the next 24 hours), so that we have owners to help push this through.
Here's the list of his packages (mostly perl), feel free to start staking claims on what you'd like:
[...]
I'll definitely take the following:
* perl-Authen-SASL -- SASL Authentication framework for Perl
amavisd-new dependency.
* perl-Cache-Cache -- Generic cache interface and implementations
perl-HTML-Mason dependency.
* perl-DBD-SQLite -- Self Contained RDBMS in a DBI Driver
amavisd-new and sqlgrey both use this.
* perl-Devel-Cycle -- Find memory cycles in objects
Indirect depencency for several things.
* perl-Error -- Error Perl module
perl-Cache-Cache dependency.
* perl-ExtUtils-CBuilder -- Compile and link C code for Perl modules
perl-Module-Build dependency.
* perl-ExtUtils-Depends -- Easily build XS extensions that depend on XS extensions
perl-Imager build dependency.
* perl-ExtUtils-ParseXS -- Module and a script for converting Perl XS code into C code
perl-Module-Build dependency.
* perl-FreezeThaw -- Convert Perl structures to strings and back
Indirect perl-BerkeleyDB and perl-IO-All build dependency.
* perl-GSSAPI -- Perl extension providing access to the GSSAPIv2 library
perl-Authen-SASL dependency.
* perl-IO-Socket-SSL -- Perl library for transparent SSL
Indirect amavisd-new dependency (via spamassassin).
* perl-IO-String -- Emulate file interface for in-core strings
perl-Pipeline and perl-IO-All dependency.
* perl-IO-Zlib -- Perl IO:: style interface to Compress::Zlib
Indirect dependency for cpanspec and amavisd-new.
* perl-MLDBM -- Store multi-level hash structure in single level tied hash
perl-BerkeleyDB and perl-IO-All build dependency.
* perl-Module-CoreList -- Perl core modules indexed by perl versions
cpanspec, perl-CPANPLUS, and various others...
* perl-Module-ScanDeps -- Recursively scan Perl code for dependencies
perl-Module-Install dependency.
* perl-Net-SSLeay -- Perl extension for using OpenSSL
perl-IO-Socket-SSL dependency.
* perl-PadWalker -- Play with other peoples' lexical variables
perl-Devel-Caller dependency.
* perl-Pod-Coverage -- Checks if the documentation of a module is comprehensive
perl-Graphics-ColorNames dependency.
* perl-Pod-Escapes -- Perl module for resolving POD escape sequences * perl-Pod-Simple -- Framework for parsing POD documentation
cpanspec dependencies.
* perl-Sub-Uplevel -- Run a perl function in an upper stack frame
perl-Test-Warn dependency.
* perl-Test-Builder-Tester -- Test runner for Test::Builder testsuites
Various build dependencies.
* perl-Test-Exception -- Library of test functions for exception based Perl code
Various build dependencies.
* perl-Test-Memory-Cycle -- Check for memory leaks and circular memory references
perl-HTML-Mason and perl-Spoon build dependency.
* perl-Test-Pod -- Perl module for checking for POD errors in files * perl-Test-Pod-Coverage -- Check for pod coverage in your distribution
Nearly everything requires these now...
* perl-TeX-Hyphen -- Hyphenate words using TeX's patterns
perl-Text-Reform dependency.
Those are all of the obvious ones (and their dependencies). In addition...
* perl-Digest-MD4 -- Perl interface to the MD4 Algorithm
Paul Howarth should probably take that. It's used by Perl-Crypt-SmbHash.
* perl-Hook-LexWrap -- Lexically scoped subroutine wrappers * perl-HTML-Scrubber -- Library for scrubbing/sanitizing html * perl-Locale-Maketext-Fuzzy -- Maketext from already interpolated strings * perl-Log-Dispatch -- Dispatches messages to one or more outputs * perl-Module-Versions-Report -- Report versions of all modules in memory * perl-Text-Template -- Expand template text with embedded Perl * perl-XML-Simple -- Easy API to maintain XML in Perl
It looks like rt3 is the main user (or at least one of the big users) of these.
Steve
Steven Pritchard wrote:
On Mon, Nov 26, 2007 at 11:18:18AM -0500, Tom spot Callaway wrote:
The circular dependencies will be fun!
Hopefully a lot of those have been resolved with the EPEL rebuild.
First things first, lets divide up all of jpo's perl packages tomorrow (assuming that he doesn't come out of AWOL status in the next 24 hours), so that we have owners to help push this through.
Here's the list of his packages (mostly perl), feel free to start staking claims on what you'd like:
[...]
I'll definitely take the following:
...
* perl-IO-Socket-SSL -- Perl library for transparent SSLIndirect amavisd-new dependency (via spamassassin).
I also have an interest in this for smbldap-tools, but the package database says that Warren is the owner, not JPO... Same applies for perl-Net-SSLeay.
...
Those are all of the obvious ones (and their dependencies). In addition...
* perl-Digest-MD4 -- Perl interface to the MD4 AlgorithmPaul Howarth should probably take that. It's used by Perl-Crypt-SmbHash.
Yes, I'll take that one.
And +1 to Ralf's suggestion re the perl SIG owning all this stuff.
Paul.
On Nov 26, 2007 8:18 AM, Tom spot Callaway tcallawa@redhat.com wrote:
On Sat, 2007-11-24 at 11:16 -0800, Chris Weyl wrote:
642 noarch 172 x86_64
814 total
I suspect we can ease the pain by coordinating a mass rebuild here, and just kicking off the rebuilds centrally. (e.g. an annointed Rebuilder In Chief)
The circular dependencies will be fun!
Aw man -- I'd forgotten about those :)
I have a number of outstanding BZ's to deal with a few of those (215637, 232736, 232380) but I haven't run into any others. If no one screams, I'll create a PERL-5_10 blocker bug.
First things first, lets divide up all of jpo's perl packages tomorrow (assuming that he doesn't come out of AWOL status in the next 24 hours), so that we have owners to help push this through.
Here's the list of his packages (mostly perl), feel free to start staking claims on what you'd like:
I'm trying to not take on too many more, as I have my eyes on the MooseX namespace next :) The ones I'll proffer to take over completely are below; I second Robin's comments.
* perl-B-Keywords -- Lists of reserved barewords and symbol names * perl-Config-Tiny -- Perl module for reading and writing .ini style configuration files * perl-CSS-Tiny -- Read/Write .css files with as little code as possible * perl-Expect -- Expect for Perl * perl-Expect-Simple -- Wrapper around the Expect module * perl-List-MoreUtils -- Provide the stuff missing in List::Util * perl-Module-Find -- Find and use installed modules in a (sub)category * perl-Module-Locate -- Locate modules in the same fashion as "require" and "use" * perl-Module-Versions-Report -- Report versions of all modules in memory * perl-Perl-Critic -- Critique Perl source code for best-practices * perl-pmtools -- A suite of small programs to help manage Perl modules * perl-Test-Expect -- Automated driving and testing of terminal-based programs * perl-Test-Perl-Critic -- Use Perl::Critic in test programs * perl-Test-WWW-Mechanize -- Testing-specific WWW::Mechanize subclass * perl-WWW-Bugzilla -- Handles submission/update of bugzilla bugs via WWW::Mechanize * perl-WWW-Mechanize -- Automates web page form & link interaction
-Chris
"Chris Weyl" cweyl@alumni.drew.edu writes:
Along these lines... Do we have a plan for including 5.10 in F-9/devel? With the RC out, it sounds like 5.10 will GA not-too-horribly-soon from now, and we're at a point in devel where it's probably the Right Time to think about bumping from 5.8 to 5.10.
http://perlbuzz.com/project-hum/2007/10/perl-5100-nears-code-freeze-release....
Now that progress has been made on dividing up the other packages, I played around for a few minutes with hacking a perl 5.10.0 spec file based upon our 5.8.8 one. Many of you have probably already done the same, but here's what I found:
o Most of our patches to 5.8.8 are either applied in 5.10.0, or fixed differently. - Many due to spot submitting all of them upstream when he did the package review. Spot rocks. - The others seem to be RH/Fedora specific, including the diddling we do with the path for the perlmodcompat stuff.
o Speaking of the perlmodcompat stuff - is 5.10.0 a good time to get rid of it? Or we be kicking ourselves when 5.10.x is released and we need to rebuild everything?
o A bunch of formerly CPAN modules have been moved into core. Here's an incomplete list:
perl-Module-CoreList perl-version perl-IO-Compress-Base perl-IO-Compress-Gzip perl-IO-Compress-Zip perl-IO-Compress-Zlib perl-Archive-Tar perl-Module-Build perl-Compress-Zlib perl-IO-Zlib perl-Compress-Gzip perl-Module-Build perl-Compress-Raw-Zlib perl-ExtUtils-CBuilder perl-Pod-Simple perl-ExtUtils-ParseXS perl-Pod-Escapes
- shall we just do these as subpackages? Are there any that would be more appropriate leaving in the main perl package? I assume we'll want to keep the perl-core convention Requiring the new subpackages.
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-ExtUtils-MakeMaker-6.30 perl-Test-Harness-2.56 perl-CPAN-1.76 perl-ExtUtils-Embed-1.26 perl-Test-Simple-0.62
This means that the release field for the 5.8.8 packages will be 31 (or whatever), while the release field for 5.10.0 will probably start at 1...meaning the 5.8.8 versions will win vercomp.
How to fix it?
- Start at whatever the last perl.5.8.8 release is + 1? (Yuck!) - Epoch (double yuck!) - Something smarter? (Smarter would be good)
o How to develop the spec file? Shall we throw one up on the wiki somewhere for easier editing?
-RN
---------- Forwarded message ---------- From: Steven Bakker sb@monkey-mind.net Date: Nov 23, 2007 2:04 AM Subject: Re: AWOL: jpo To: Development discussions related to Fedora fedora-devel-list@redhat.com
On Tue, 20 Nov 2007 11:41:25 -0700 Richi Plana wrote:
As much as I love Perl and I prefer it over all existing scripting languages I'm familiar with, it's hard to get excited about its future since the developers are extremely quiet about it.
They're probably quiet about it because they prefer coding over talking :-)
Perl 5.10-RC1 has been unleashed recently[1], full of nice new features[2], borrowing some from (the still-vaporware) Perl6 (named capture buffers!).
[1] http://search.cpan.org/~rgarcia/perl-5.10.0-RC1/ [2] http://www.slideshare.net/rjbs/perl-510-for-people-who-arent-totally-insane
-- Steven
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- Chris Weyl Ex astris, scientia
On 05/12/2007, Robin Norwood rnorwood@redhat.com wrote:
o Most of our patches to 5.8.8 are either applied in 5.10.0, or fixed differently.
- Many due to spot submitting all of them upstream when he
did the package review. Spot rocks.
Submitting upstream rocks. I'd like more vendors to do this.
- The others seem to be RH/Fedora specific, including the diddling we
do with the path for the perlmodcompat stuff.
o Speaking of the perlmodcompat stuff - is 5.10.0 a good time to get rid of it? Or we be kicking ourselves when 5.10.x is released and we need to rebuild everything?
What's the perlmodcompat stuff, if I may ask?
o A bunch of formerly CPAN modules have been moved into core. Here's an incomplete list:
You'll get a full list from pod/perl5100delta.pod.
[...]
- shall we just do these as subpackages? Are there any that would be more appropriate leaving in the main perl package? I assume we'll want to keep the perl-core convention Requiring the new subpackages.
Except perl-version, which is really tied to the core, I assume you can make them subpackages, if that would ease upgrading them separately.
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-ExtUtils-MakeMaker-6.30 perl-Test-Harness-2.56 perl-CPAN-1.76 perl-ExtUtils-Embed-1.26 perl-Test-Simple-0.62
This means that the release field for the 5.8.8 packages will be 31 (or whatever), while the release field for 5.10.0 will probably start at 1...meaning the 5.8.8 versions will win vercomp.
How to fix it?
- Start at whatever the last perl.5.8.8 release is + 1? (Yuck!)
Forget it: that could cause problems with intermediate perl upgrades for 5.8.8 in maintenance branches (like, security fixes).
- Epoch (double yuck!)
Epoch isn't nice, but works, it wouldn't dismiss it from the start.
- Something smarter? (Smarter would be good)
Smarter means tricky. My two cents: you could produce those subpackages with a Requires on perl-base >= 5.10.0 and a Conflicts on perl-base < 5.10.0. Not sure how upgraders (as yum) will cope with that though.
"Rafael Garcia-Suarez" rgarciasuarez@gmail.com writes:
On 05/12/2007, Robin Norwood rnorwood@redhat.com wrote:
o Most of our patches to 5.8.8 are either applied in 5.10.0, or fixed differently.
- Many due to spot submitting all of them upstream when he
did the package review. Spot rocks.
Submitting upstream rocks. I'd like more vendors to do this.
- The others seem to be RH/Fedora specific, including the diddling we
do with the path for the perlmodcompat stuff.
o Speaking of the perlmodcompat stuff - is 5.10.0 a good time to get rid of it? Or we be kicking ourselves when 5.10.x is released and we need to rebuild everything?
What's the perlmodcompat stuff, if I may ask?
This is the business that creates the directories:
/usr/lib/perl5/{5.8.6,5.8.7,5.8.8}
So that rpms built for older releases will still work. It's kindof nasty, but as I understand it, it was to prevent having to rebuilt all the perl modules when perl does a point release. I think we can deal with this a lot better from an infrastructure point of view than in the old days...though a big red 'rebuild all of perl magically' button would be nice.
o A bunch of formerly CPAN modules have been moved into core. Here's an incomplete list:
You'll get a full list from pod/perl5100delta.pod.
Oh, excellent.
[...]
- shall we just do these as subpackages? Are there any that would be more appropriate leaving in the main perl package? I assume we'll want to keep the perl-core convention Requiring the new subpackages.
Except perl-version, which is really tied to the core, I assume you can make them subpackages, if that would ease upgrading them separately.
Ok. I'll leave that in for now.
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-ExtUtils-MakeMaker-6.30 perl-Test-Harness-2.56 perl-CPAN-1.76 perl-ExtUtils-Embed-1.26 perl-Test-Simple-0.62
This means that the release field for the 5.8.8 packages will be 31 (or whatever), while the release field for 5.10.0 will probably start at 1...meaning the 5.8.8 versions will win vercomp.
How to fix it?
- Start at whatever the last perl.5.8.8 release is + 1? (Yuck!)
Forget it: that could cause problems with intermediate perl upgrades for 5.8.8 in maintenance branches (like, security fixes).
- Epoch (double yuck!)
Epoch isn't nice, but works, it wouldn't dismiss it from the start.
- Something smarter? (Smarter would be good)
Smarter means tricky. My two cents: you could produce those subpackages with a Requires on perl-base >= 5.10.0 and a Conflicts on perl-base < 5.10.0. Not sure how upgraders (as yum) will cope with that though.
Eeeh. Tricky.
Yeah, epoch is probably the way to go.
-RN
On Dec 6, 2007 8:35 AM, Robin Norwood rnorwood@redhat.com wrote:
"Rafael Garcia-Suarez" rgarciasuarez@gmail.com writes:
What's the perlmodcompat stuff, if I may ask?
This is the business that creates the directories:
/usr/lib/perl5/{5.8.6,5.8.7,5.8.8}
So that rpms built for older releases will still work. It's kindof nasty, but as I understand it, it was to prevent having to rebuilt all the perl modules when perl does a point release. I think we can deal with this a lot better from an infrastructure point of view than in the old days...though a big red 'rebuild all of perl magically' button would be nice.
I'm not opposed to dropping it in principle, but do we have a nice way to determine that a built rpm will work with a given perl rpm? E.g. If we have perl-Foo, a noarch perl package built against 5.10.:
a) will we need to rebuild it against 5.10.1? b) do we have meta-information embedded in the rpm that will let yum/apt go "this no workie"?
a is just an awareness issue, and maybe the building out of a Big Red Button. b is pretty clutch, or we're going to break a bunch of stuff...
[...]
- shall we just do these as subpackages? Are there any that would be more appropriate leaving in the main perl package? I assume we'll want to keep the perl-core convention Requiring the new subpackages.
Except perl-version, which is really tied to the core, I assume you can make them subpackages, if that would ease upgrading them separately.
Ok. I'll leave that in for now.
I'm starting to relax on this :) I do think any version bumps of dual-life'd core modules, outside of a core upgrade itself, ought to be the subject of discussion here.
-Chris
"Chris Weyl" cweyl@alumni.drew.edu writes:
On Dec 6, 2007 8:35 AM, Robin Norwood rnorwood@redhat.com wrote:
"Rafael Garcia-Suarez" rgarciasuarez@gmail.com writes:
What's the perlmodcompat stuff, if I may ask?
This is the business that creates the directories:
/usr/lib/perl5/{5.8.6,5.8.7,5.8.8}
So that rpms built for older releases will still work. It's kindof nasty, but as I understand it, it was to prevent having to rebuilt all the perl modules when perl does a point release. I think we can deal with this a lot better from an infrastructure point of view than in the old days...though a big red 'rebuild all of perl magically' button would be nice.
I'm not opposed to dropping it in principle, but do we have a nice way to determine that a built rpm will work with a given perl rpm? E.g. If we have perl-Foo, a noarch perl package built against 5.10.:
a) will we need to rebuild it against 5.10.1? b) do we have meta-information embedded in the rpm that will let yum/apt go "this no workie"?
a is just an awareness issue, and maybe the building out of a Big Red Button. b is pretty clutch, or we're going to break a bunch of stuff...
Well, for b), we still have: Provides: perl(:MODULE_COMPAT_5.10.0) in the perl RPM, and:
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
In all of our Fedora RPMs. The way the 5.10.0 rpm is now, that will require that all of the perl RPMs be specifically built for 5.10.0 before they can be installed. When 5.10.1 rolls around, we could either:
1) Return to creating the permodcompat directories, and include Provides for both 5.10.0 and 5.10.1.
2) Rebuild the whole darn world (and make people download all those updates if we do it during a release).
Neither seems particularly appealing to me, to be honest. But if we already know we're going to do (1), we might as well leave the rest of the perlmodcompat spec stuff in.
Except perl-version, which is really tied to the core, I assume you can make them subpackages, if that would ease upgrading them separately.
Ok. I'll leave that in for now.
I'm starting to relax on this :) I do think any version bumps of dual-life'd core modules, outside of a core upgrade itself, ought to be the subject of discussion here.
Yes, I agree.
-RN
On Dec 10, 2007 8:50 AM, Robin Norwood rnorwood@redhat.com wrote:
Well, for b), we still have: Provides: perl(:MODULE_COMPAT_5.10.0) in the perl RPM, and:
Ohhh, duh. I was conflating the two.
-Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[My apologies for my digression, feel free to ignore it.]
Robin Norwood wrote:
/usr/lib/perl5/{5.8.6,5.8.7,5.8.8} So that rpms built for older releases will still work. It's kindof nasty, but as I understand it, it was to prevent having to rebuilt all the perl modules when perl does a point release. I think we can deal with this a lot better from an infrastructure point of view than in the old days...though a big red 'rebuild all of perl magically' button would be nice.
Now, if you're talking about a major "all Perl related" rebuild, maybe this could be a good point for raising a "better" (YM*M*V) Perl infrastructure:
a) let "site" be "site" (as in "local" IS "local"), e.g.: ./Configure [..] -Dsiteprefix=/usr/local \ -Dsitelib="/usr/local/lib/perl5" \ -Dsitearch="/usr/local/lib/perl5/%{perl_archname}" \ -Dsiteman1dir=/usr/local/share/man/man1 \ -Dsiteman3dir=/usr/local/share/man/man3 \ [...] (if some of you think Debian like, than paranoid may be good, so you could decide involving a %{perl_version} there as some handy/safe "site" handler - not that it would matter, but I'd nay it)
b) no more creepo "compat stuff", let there be a "perl(abi..)" BS of some kind if you need it (IMHO, there *is* an inherent need for something like that for RPM's sake), e.g.: ./Configure [..] [...] -Dprivlib=%{_datadir}/perl/%{perl_abi} -Darchlib=%{_libdir}/perl/%{perl_abi} -Dvendorlib=%{_datadir}/perl/%{perl_abi} -Dvendorarch=%{_libdir}/perl/%{perl_abi} (yes, "vendor" should be the very same thing as "priv", and "perl_abi" should be anything "Fedora Perl master" decides - "5.8", "5.10", etc)
As you may have noticed, there is nothing new here, they're proved paths by (many) other *nix distros ("Debian" will be my only example, as I already had to mention it).
On a different cue ("rant-wise"), looking at the "split" thingie, there is still a lot more to require from upstream (I mean "rpm" - you know, perl.prov/req & co) until we could get some "real" (as in "useful"... or maybe "granular"?) require/provide computing. But that (again) is handled with as much care as it could be imposed for a voluntary project by the many Fedora Perl modules packagers.
Cheers - -- Marius Feraru
Marius Feraru altblue@n0i.net writes:
[My apologies for my digression, feel free to ignore it.]
Robin Norwood wrote:
/usr/lib/perl5/{5.8.6,5.8.7,5.8.8} So that rpms built for older releases will still work. It's kindof nasty, but as I understand it, it was to prevent having to rebuilt all the perl modules when perl does a point release. I think we can deal with this a lot better from an infrastructure point of view than in the old days...though a big red 'rebuild all of perl magically' button would be nice.
Now, if you're talking about a major "all Perl related" rebuild, maybe this could be a good point for raising a "better" (YM*M*V) Perl infrastructure:
a) let "site" be "site" (as in "local" IS "local"), e.g.: ./Configure [..] -Dsiteprefix=/usr/local \ -Dsitelib="/usr/local/lib/perl5" \ -Dsitearch="/usr/local/lib/perl5/%{perl_archname}" \ -Dsiteman1dir=/usr/local/share/man/man1 \ -Dsiteman3dir=/usr/local/share/man/man3 \ [...] (if some of you think Debian like, than paranoid may be good, so you could decide involving a %{perl_version} there as some handy/safe "site" handler - not that it would matter, but I'd nay it)
This seems to me to be perfectly sane and more in keeping with the LSB filesystem guidelines. I'm not sure all of the historical reasons for the way our paths are set up. I don't have an objection to changing them after some debate, though.
b) no more creepo "compat stuff", let there be a "perl(abi..)" BS of some kind if you need it (IMHO, there *is* an inherent need for something like that for RPM's sake), e.g.: ./Configure [..] [...] -Dprivlib=%{_datadir}/perl/%{perl_abi} -Darchlib=%{_libdir}/perl/%{perl_abi} -Dvendorlib=%{_datadir}/perl/%{perl_abi} -Dvendorarch=%{_libdir}/perl/%{perl_abi} (yes, "vendor" should be the very same thing as "priv", and "perl_abi" should be anything "Fedora Perl master" decides - "5.8", "5.10", etc)
As you may have noticed, there is nothing new here, they're proved paths by (many) other *nix distros ("Debian" will be my only example, as I already had to mention it).
I'm probably missing the point, but I don't really see how this is significantly better than the way we do the perlmodcompat stuff now.
On a different cue ("rant-wise"), looking at the "split" thingie, there is still a lot more to require from upstream (I mean "rpm" - you know, perl.prov/req & co) until we could get some "real" (as in "useful"... or maybe "granular"?) require/provide computing. But that (again) is handled with as much care as it could be imposed for a voluntary project by the many Fedora Perl modules packagers.
Well, RH/Fedora are spending more resources on our variant of RPM these days, so there's a there's a better chance that specific bugs will get attention, or, even better, patches.
-RN
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Robin Norwood wrote:
I'm probably missing the point, but I don't really see how this is significantly better than the way we do the perlmodcompat stuff now.
Let's detail what these changes mean: a) using "ABI based" layout (instead "version based"); b) moving "arch independent" components in "/usr/share"; c) unifying "install" and "vendor" folders; d) moving "site" folders to "/usr/local".
So here's what comes to mind as (maybe not so significant) advantages: - - [a),c)] less items in @INC [1] => faster module/functions loading => light performance gain; - - [b),c),d)] more FHS conformity; - - [a),c),d)] less rebuilds/updates/conflicts/metadata => vendor maintenance cost reduction; - - [d)] leveraging local sysop's job/ownership [2]; ...(FIXME: add more pros and - more importantly - *cons*)...
[1] a "uniq" patch is needed in order to drop duplicate paths from @INC.
[2] a vendor update would not override sysop's "temporary" system "patching", so that's why Debian (among others) prefers adding "precise" (version based) suffixes to locally maintained folders (e.g. "/usr/local/lib/perl/5.10.0" instead "/usr/local/lib/perl/5.10").
Well, RH/Fedora are spending more resources on our variant of RPM these days, so there's a there's a better chance that specific bugs will get attention, or, even better, patches.
Hehe, as I mentioned, I was merely "ranting" as I'm pretty confident the current approach used by perl.(prov|req) (or perldeps.pl) will lead us nowhere even if we keep on monkey patching it on a daily/package basis. As I'm sure you know, each vendor uses its "custom" way of detecting these dependencies/provides, each with its own flaws. :) I guess we will talk about patches in January, when we'll deal with rpm5's perl helper ;-)
cheers - -- Marius Feraru
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom "spot" Callaway wrote:
Last time I looked, Fedora wasn't planning to use that fork.
Right, I remember the discussions; I should have kept the "still-ranting" mark for that paragraph. Sorry ;-)
- -- Marius Feraru
On Wed, 2007-12-05 at 15:32 -0500, Robin Norwood wrote:
o Speaking of the perlmodcompat stuff - is 5.10.0 a good time to get rid of it? Or we be kicking ourselves when 5.10.x is released and we need to rebuild everything?
I think we should try to drop it. Upstream perl doesn't really like that we're carrying it, and it doesn't have a significant benefit these days. If we get a huge uproar, it shouldn't be too hard to enable it later.
o A bunch of formerly CPAN modules have been moved into core. Here's an incomplete list:
<snip>
- shall we just do these as subpackages? Are there any that would be more appropriate leaving in the main perl package? I assume we'll want to keep the perl-core convention Requiring the new subpackages.
This seems reasonable to me, but I know that the subpackages are controversial for some people.
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-CPAN-1.76
This is baffling. Upstream CPAN is at 1.9205, I thought for sure this would get updated in 5.10.0. :P
- Epoch (double yuck!)
I think this is the lesser evil. I can't think of anything more clever.
- Something smarter? (Smarter would be good)
o How to develop the spec file? Shall we throw one up on the wiki somewhere for easier editing?
I'd planned to start working on it when I got back to the US and put it on the Fedora wiki for commentss, but don't feel like you need to wait for me (I'm in the middle of FOSS.in at the moment).
~spot
On 06/12/2007, Tom spot Callaway tcallawa@redhat.com wrote:
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-CPAN-1.76
This is baffling. Upstream CPAN is at 1.9205, I thought for sure this would get updated in 5.10.0. :P
Now that you mention it, 5.10.0 RC2 does have 1.9205. As far as I know most modules are synchronized with their CPAN versions. A notable exception is Test::Harness, since on CPAN we have the 3.00 major release of it, and it was too late to tempt a major upgrade of such a central module.
On Thu, 2007-12-06 at 11:01 +0100, Rafael Garcia-Suarez wrote:
On 06/12/2007, Tom spot Callaway tcallawa@redhat.com wrote:
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-CPAN-1.76
This is baffling. Upstream CPAN is at 1.9205, I thought for sure this would get updated in 5.10.0. :P
Now that you mention it, 5.10.0 RC2 does have 1.9205. As far as I know most modules are synchronized with their CPAN versions. A notable exception is Test::Harness, since on CPAN we have the 3.00 major release of it, and it was too late to tempt a major upgrade of such a central module.
Oh, good. That makes a lot more sense, and should minimize the subpackage epoch needs.
~spot
"Rafael Garcia-Suarez" rgarciasuarez@gmail.com writes:
On 06/12/2007, Tom spot Callaway tcallawa@redhat.com wrote:
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-CPAN-1.76
This is baffling. Upstream CPAN is at 1.9205, I thought for sure this would get updated in 5.10.0. :P
Now that you mention it, 5.10.0 RC2 does have 1.9205. As far as I know most modules are synchronized with their CPAN versions. A notable exception is Test::Harness, since on CPAN we have the 3.00 major release of it, and it was too late to tempt a major upgrade of such a central module.
" %package CPAN Version: 1.76_02 "
Oh, duh. I didn't realize that the version was hardcoded in the spec file. I'll fix that today.
-RN
On Thu, 2007-12-06 at 15:23 +0530, Tom "spot" Callaway wrote:
On Wed, 2007-12-05 at 15:32 -0500, Robin Norwood wrote:
- shall we just do these as subpackages? Are there any that would be more appropriate leaving in the main perl package? I assume we'll want to keep the perl-core convention Requiring the new subpackages.
This seems reasonable to me, but I know that the subpackages are controversial for some people.
I think, we should use the upgrade to perl-5.10.x as an opportunity to systematically split out all "dual life" perl dists.
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-CPAN-1.76
This is baffling. Upstream CPAN is at 1.9205, I thought for sure this would get updated in 5.10.0. :P
One reason more to split out "dual life" perl dists ;)
Ralf
"Tom "spot" Callaway" tcallawa@redhat.com writes:
On Wed, 2007-12-05 at 15:32 -0500, Robin Norwood wrote:
o Speaking of the perlmodcompat stuff - is 5.10.0 a good time to get rid of it? Or we be kicking ourselves when 5.10.x is released and we need to rebuild everything?
I think we should try to drop it. Upstream perl doesn't really like that we're carrying it, and it doesn't have a significant benefit these days. If we get a huge uproar, it shouldn't be too hard to enable it later.
Alright, I'll see what changes I need to make to yank it out.
- shall we just do these as subpackages? Are there any that would be more appropriate leaving in the main perl package? I assume we'll want to keep the perl-core convention Requiring the new subpackages.
This seems reasonable to me, but I know that the subpackages are controversial for some people.
Yup - if anyone doesn't like it...speak up.
o Some of the packages that we split into subpackages for 5.8.8 didn't change version in 5.10.0:
perl-CPAN-1.76
This is baffling. Upstream CPAN is at 1.9205, I thought for sure this would get updated in 5.10.0. :P
Yeah, as Rafael points out, this was my mistake. If there are any that are lower/the same in 5.10.0, I'll bump the epoch unless/until someone figures something better out.
o How to develop the spec file? Shall we throw one up on the wiki somewhere for easier editing?
I'd planned to start working on it when I got back to the US and put it on the Fedora wiki for commentss, but don't feel like you need to wait for me (I'm in the middle of FOSS.in at the moment).
I'll do that today.
-RN
Robin Norwood rnorwood@redhat.com writes:
"Chris Weyl" cweyl@alumni.drew.edu writes:
Along these lines... Do we have a plan for including 5.10 in F-9/devel? With the RC out, it sounds like 5.10 will GA not-too-horribly-soon from now, and we're at a point in devel where it's probably the Right Time to think about bumping from 5.8 to 5.10.
http://perlbuzz.com/project-hum/2007/10/perl-5100-nears-code-freeze-release....
Here's my attempt at said spec file:
http://fedoraproject.org/wiki/RobinNorwood/Perl510Spec
Any comments/fixes/etc? Have at it. It's wiki so other people can edit it, so don't be shy about fixing things.
-RN
Robin Norwood rnorwood@redhat.com writes:
Robin Norwood rnorwood@redhat.com writes:
"Chris Weyl" cweyl@alumni.drew.edu writes:
Along these lines... Do we have a plan for including 5.10 in F-9/devel? With the RC out, it sounds like 5.10 will GA not-too-horribly-soon from now, and we're at a point in devel where it's probably the Right Time to think about bumping from 5.8 to 5.10.
http://perlbuzz.com/project-hum/2007/10/perl-5100-nears-code-freeze-release....
Here's my attempt at said spec file:
http://fedoraproject.org/wiki/RobinNorwood/Perl510Spec
Any comments/fixes/etc? Have at it. It's wiki so other people can edit it, so don't be shy about fixing things.
Oh, and don't forget to Subscribe to that page if you want to keep an eye on changes. (via the Subscribe link in the righthand column of the page)
-RN
perl-devel@lists.fedoraproject.org
-
Chris Weyl -
Jan Pazdziora -
Marius Feraru -
Patrice Dumas -
Paul Howarth -
Rafael Garcia-Suarez -
Ralf Corsepius -
Robin Norwood -
Steven Pritchard -
Tom Callaway -
Toshio Kuratomi