11:34 a.m.
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-relea...
-Chris
---------- Forwarded message ----------
From: Steven Bakker <sb(a)monkey-mind.net>
Date: Nov 23, 2007 2:04 AM
Subject: Re: AWOL: jpo
To: Development discussions related to Fedora <fedora-devel-list(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Chris Weyl
Ex astris, scientia
12:03 p.m.
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
12:17 p.m.
On 24/11/2007, Tom spot Callaway <tcallawa(a)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.
1:16 p.m.
On Nov 24, 2007 10:17 AM, Rafael Garcia-Suarez <rgarciasuarez(a)gmail.com> wrote:
On 24/11/2007, Tom spot Callaway <tcallawa(a)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
--
Chris Weyl
Ex astris, scientia
10:18 a.m.
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
10:56 a.m.
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 ...
--
Jan Pazdziora
Satellite Engineering, Red Hat
3:04 p.m.
"Tom \"spot\" Callaway" <tcallawa(a)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
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
3:08 p.m.
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 routines
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)
~spot
3:19 p.m.
"Tom \"spot\" Callaway" <tcallawa(a)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 routines
>
> 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 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
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
3:48 p.m.
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
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)624-4440 Mobile: (618)567-7320
9:40 p.m.
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
11:36 p.m.
On Nov 26, 2007 7:40 PM, Ralf Corsepius <rc040203(a)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
--
Chris Weyl
Ex astris, scientia
2:58 a.m.
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
8 a.m.
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
9 a.m.
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
9:04 a.m.
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
9:13 a.m.
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
1:57 p.m.
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
3:26 p.m.
On Nov 27, 2007 11:57 AM, Tom spot Callaway <tcallawa(a)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
--
Chris Weyl
Ex astris, scientia
4:16 p.m.
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
2:15 a.m.
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 ...
--
Jan Pazdziora
Satellite Engineering, Red Hat
8:58 p.m.
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
6:40 a.m.
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
7:05 a.m.
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
7:26 a.m.
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
7:35 a.m.
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
7:46 a.m.
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
8:25 a.m.
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
8:41 a.m.
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
8:46 a.m.
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
9:22 a.m.
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
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)624-4440 Mobile: (618)567-7320
9:53 a.m.
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
12:05 p.m.
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
1:57 p.m.
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
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)624-4440 Mobile: (618)567-7320
10:09 a.m.
On Nov 28, 2007 6:25 AM, Tom spot Callaway <tcallawa(a)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
--
Chris Weyl
Ex astris, scientia
10:58 a.m.
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
11:44 a.m.
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
11:21 a.m.
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(a)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
12:39 p.m.
New subject: Fwd: time for perl 5.10.x in devel?
Looks like this didn't make it :)
---------- Forwarded message ----------
From: Toshio Kuratomi <a.badger(a)gmail.com>
Date: Nov 28, 2007 9:21 AM
Subject: Re: time for perl 5.10.x in devel?
To: Chris Weyl <cweyl(a)alumni.drew.edu>, fedora-perl-devel-list(a)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(a)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
--
Chris Weyl
Ex astris, scientia
3:47 p.m.
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 - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)624-4440 Mobile: (618)567-7320
4:58 a.m.
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 SSL
Indirect 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 Algorithm
Paul 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.
4:44 p.m.
On Nov 26, 2007 8:18 AM, Tom spot Callaway <tcallawa(a)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
Ex astris, scientia
2:32 p.m.
"Chris Weyl" <cweyl(a)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-relea...
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(a)monkey-mind.net>
Date: Nov 23, 2007 2:04 AM
Subject: Re: AWOL: jpo
To: Development discussions related to Fedora <fedora-devel-list(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Chris Weyl
Ex astris, scientia
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
3:39 a.m.
On 05/12/2007, Robin Norwood <rnorwood(a)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.
10:35 a.m.
"Rafael Garcia-Suarez" <rgarciasuarez(a)gmail.com> writes:
On 05/12/2007, Robin Norwood <rnorwood(a)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
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
noon
On Dec 6, 2007 8:35 AM, Robin Norwood <rnorwood(a)redhat.com> wrote:
"Rafael Garcia-Suarez" <rgarciasuarez(a)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
Ex astris, scientia
10:50 a.m.
"Chris Weyl" <cweyl(a)alumni.drew.edu> writes:
On Dec 6, 2007 8:35 AM, Robin Norwood <rnorwood(a)redhat.com>
wrote:
> "Rafael Garcia-Suarez" <rgarciasuarez(a)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
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
6:14 p.m.
-----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
-----BEGIN PGP SIGNATURE-----
iD8DBQFHXIT+tZHp/AYZiNkRAmSqAJ9xtOHfZn4s+qF/tAChfVKI04XMIQCfQgDy
YhdIbH8e8yK7g/GYYnX376A=
=txiY
-----END PGP SIGNATURE-----
11:40 a.m.
Marius Feraru <altblue(a)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
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
8:26 p.m.
-----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 SIGNATURE-----
iD8DBQFHXfVltZHp/AYZiNkRAr1OAJ9lKFC2GKoGocRwn1BeErAdzIa19wCeI2Jx
E9dR58bpK/+zbLKeIXzLIeM=
=rGEZ
-----END PGP SIGNATURE-----
9:19 p.m.
-----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
-----BEGIN PGP SIGNATURE-----
iD8DBQFHXgHAtZHp/AYZiNkRArYaAKC0zYdKp1ahd1+iGXAKWNXG4wiU6QCdEz3I
+JLGYtsaE+Gq2AQA66m71Ck=
=KW3Z
-----END PGP SIGNATURE-----
3:53 a.m.
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
4:01 a.m.
On 06/12/2007, Tom spot Callaway <tcallawa(a)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.
4:09 a.m.
On Thu, 2007-12-06 at 11:01 +0100, Rafael Garcia-Suarez wrote:
On 06/12/2007, Tom spot Callaway <tcallawa(a)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
10:12 a.m.
"Rafael Garcia-Suarez" <rgarciasuarez(a)gmail.com> writes:
On 06/12/2007, Tom spot Callaway <tcallawa(a)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
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
4:12 a.m.
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
10:14 a.m.
"Tom \"spot\" Callaway" <tcallawa(a)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
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
1:46 p.m.
Robin Norwood <rnorwood(a)redhat.com> writes:
"Chris Weyl" <cweyl(a)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-relea...
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
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
2:15 p.m.
Robin Norwood <rnorwood(a)redhat.com> writes:
Robin Norwood <rnorwood(a)redhat.com> writes:
> "Chris Weyl" <cweyl(a)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-relea...
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
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
5974
days inactive
5991
days old
perl-devel@lists.fedoraproject.org
60 comments
11 participants
participants (11)
-
Chris Weyl -
Jan Pazdziora -
Marius Feraru -
Patrice Dumas -
Paul Howarth -
Rafael Garcia-Suarez -
Ralf Corsepius -
Robin Norwood -
Steven Pritchard -
Tom Callaway -
Toshio Kuratomi