the maintainership/upstream situation of the Cwd/File::Spec dist is very unclear

[p5pRT]

Migrated from rt.perl.org#129896 (status was 'open')

Searchable as RT129896$

[p5pRT]

From @wchristian

This is a bug report for perl from walde.christian@​gmail.com\, generated with the help of perlbug 1.39 running under perl 5.18.4.

---

I ran into a bug in Cwd and while trying to figure out who's responsible\,
who can help with fixing it\, where to fix it\, and other related facts\, i
found that the situation of the entire dist is very unclear.

The dist itself still claims Ken Williams is the maintainer.

The dist itself on sco and metacpan points at
https://rt.cpan.org/Dist/Display.html?Queue=PathTools

Said page lists FLORA\, KJALB\, KWILLIAMS\, RJBS\, SMUELLER as releasers.

The RT queue has 69 open tickets (more than resolved)\, most of them over 3
years old old.

The most recent releaser has been RJBS\, presumably in his capacity of
pumpking.

RJBS claims he doesn't have a lot of expertise to offer.

The official repository according to RJBS is blead in /dist/PathTools.

The committers to that have been a wide variety of perl5porters.

Relatedly\, the lack of link to source repo\, and some confusion about
responsibility has also been discussed here​:
https://rt.cpan.org/Ticket/Display.html?id=116342

As such the questions i ask of p5p is​:

Is p5p collectively currently the responsible maintainer?

If not\, who is?

If so\, should the ticket queue be moved over to perlbug\, and the dist
point at perlbug as well?

---

---

Flags​:   category=library   severity=medium   module=File​::Spec

---

Site configuration information for perl 5.18.4​:

Configured by strawberry-perl at Thu Oct 2 12​:12​:07 2014.

Summary of my perl5 (revision 5 version 18 subversion 4) configuration​:

  Platform​:   osname=MSWin32\, osvers=6.3\, archname=MSWin32-x86-multi-thread-64int   uname='Win32 strawberry-perl 5.18.4.1 #1 Thu Oct 2 12​:10​:29 2014 i386'   config_args='undef'   hint=recommended\, useposix=true\, d_sigaction=undef   useithreads=define\, usemultiplicity=define   useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef   use64bitint=define\, use64bitall=undef\, uselongdouble=undef   usemymalloc=n\, bincompat5005=undef   Compiler​:   cc='gcc'\, ccflags =' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO
-fno-strict-aliasing -mms-bitfields'\,   optimize='-s -O2'\,   cppflags='-DWIN32'   ccversion=''\, gccversion='4.7.3'\, gccosandvers=''   intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=12345678   d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12   ivtype='long long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off_t='long
long'\, lseeksize=8   alignbytes=8\, prototype=define   Linker and Libraries​:   ld='g++'\, ldflags ='-s -L"C​:\strawberry\perl\lib\CORE"
-L"C​:\strawberry\c\lib"'   libpth=C​:\strawberry\c\lib C​:\strawberry\c\i686-w64-mingw32\lib
C​:\strawberry\c\lib\gcc\i686-w64-mingw32\4.7.3   libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32   perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32   libc=\, so=dll\, useshrplib=true\, libperl=libperl518.a   gnulibc_version=''   Dynamic Linking​:   dlsrc=dl_win32.xs\, dlext=dll\, d_dlsymun=undef\, ccdlflags=' '   cccdlflags=' '\, lddlflags='-mdll -s -L"C​:\strawberry\perl\lib\CORE"
-L"C​:\strawberry\c\lib"'

Locally applied patches​:

---

@​INC for perl 5.18.4​:   C​:/strawberry/perl/site/lib/MSWin32-x86-multi-thread-64int   C​:/strawberry/perl/site/lib   C​:/strawberry/perl/vendor/lib   C​:/strawberry/perl/lib   .

---

Environment for perl 5.18.4​:   CYGWIN=nodosfilewarning   HOME (unset)   LANG=en_US.utf8   LANGUAGE (unset)   LD_LIBRARY_PATH (unset)   LOGDIR (unset)   PATH=C​:\Program Files
(x86)\ImageMagick-6.9.5-Q16;c​:\python27\;c​:\python27\scripts;c​:\programdata\oracle\java\javapath;c​:\windows\system32;c​:\perl\site\bin;c​:\perl\bin;c​:\program
files\intel\wifi\bin\;c​:\program files\common
files\intel\wirelesscommon\;c​:\program
files\openvpn\bin;c​:\windows;c​:\windows\system32\wbem;c​:\windows\system32\windowspowershell\v1.0\;c​:\program
files (x86)\skype\phone\;c​:\program files (x86)\miktex
2.9\miktex\bin\;c​:\program files\git\cmd;c​:\program files
(x86)\intel\opencl sdk\2.0\bin\x86;c​:\program files (x86)\intel\opencl
sdk\2.0\bin\x64;C​:\Program Files (x86)\Intel\OpenCL
SDK\2.0\bin\x86;C​:\Program Files (x86)\Intel\OpenCL
SDK\2.0\bin\x64;C​:\Program Files (x86)\Windows Kits\8.1\Windows
Performance Toolkit\;C​:\Program
Files\TSVN\bin;C​:\strawberry\c\bin;C​:\strawberry\perl\site\bin;C​:\strawberry\perl\bin;c​:\cygwin\bin;C​:\Program
Files\PostgreSQL\pg95\bin;C​:\Program Files (x86)\NVIDIA
Corporation\PhysX\Common;C​:\Program
Files\FileBot\;C​:\WINDOWS\system32;C​:\WINDOWS;C​:\WINDOWS\System32\Wbem;C​:\WINDOWS\System32\WindowsPowerShell\v1.0\;C​:\Program
Files\TortoiseGit\bin;C​:\Program
Files\Git\cmd;C​:\KFFirstAide;C​:\Users\Mithaldu\AppData\Roaming\npm;d​:\android\android-ndk-r10d\;C​:\Program
Files\Intel\WiFi\bin\;C​:\Program Files\Common
Files\Intel\WirelessCommon\;d​:\j\MeCab\bin\;C​:\Program Files
(x86)\Diffuse;C​:\Users\Mithaldu\AppData\Local\Microsoft\WindowsApps   PERL_BADLANG (unset)   SHELL (unset)

[p5pRT]

From @xsawyerx

On Sun Oct 16 11​:49​:05 2016\, walde.christian@​gmail.com wrote​:

I ran into a bug in Cwd and while trying to figure out who's responsible\, who can help with fixing it\, where to fix it\, and other related facts\, i found that the situation of the entire dist is very unclear.

Hi Mithaldu\, :)

Let me see if I can help clarify this.

The dist itself still claims Ken Williams is the maintainer.

Yup.

The dist itself on sco and metacpan points at https://rt.cpan.org/Dist/Display.html?Queue=PathTools

I would imagine this grew out of comfort and usage. I'm not aware of a rule that says a core module can not have its own RT queue. (I'm not being sarcastic or cynical.)

Said page lists FLORA\, KJALB\, KWILLIAMS\, RJBS\, SMUELLER as releasers.

Yes. These are people who have released it to CPAN\, separate from core. We try to have as many modules dual-life as possible\, so users may reap the benefits of it without having to upgrade their perl. These are people who are given the right to make a release of a core module outside the core.

This does not make them maintainers or developers of it\, as they might have been helping out with the release process at any point. On the other hand\, it's a good hint to know who else is familiar with the project.

The RT queue has 69 open tickets (more than resolved)\, most of them over 3 years old old.

That is unfortunate. However\, the maintainer(s) (and p5p at large) only have few resources available and tickets can pile up. Some of them might be esoteric and require additional research\, some might require additional feedback from the reporter\, and some might just be lower priority.

Patches are always welcome! :)

The most recent releaser has been RJBS\, presumably in his capacity of pumpking.

Yup.

The most recent release (3.62) contained a fix for a security issue (CVE-2015-8607)\, which would require making a separate CPAN release of this as well\, not to force users to upgrade their perl. RJBS pushed that release out.

RJBS claims he doesn't have a lot of expertise to offer.

I would take RJBS at his word. :)

He made the release since it was an important fix that had to be released\, not because he made the fix and is knowledgeable in the project. This goes back to people who have permissions to release because they are helping out (or in RJBS' situation - are responsible) rather than being intimately familiar with the code.

The fix which resulted in this release was by Tony Cook\, just for reference. Commit 0b6f93036de171c12ba95d415e264d9cf7f4e1fd.

The official repository according to RJBS is blead in /dist/PathTools.

RJBS is correct. You can see this here​: http​://perl5.git.perl.org/perl.git/tree/HEAD​:/dist/PathTools

The committers to that have been a wide variety of perl5porters.

Yup.

Relatedly\, the lack of link to source repo\, and some confusion about responsibility has also been discussed here​: https://rt.cpan.org/Ticket/Display.html?id=116342

As such the questions i ask of p5p is​:

Is p5p collectively currently the responsible maintainer?

Those are two different questions\, unfortunately. "Maintainer" is one thing\, "responsible" is another.

p5p is the responsible party\, but it is not necessarily the current maintainer. The maintainer is one or more people\, usually from p5p.

If not\, who is?

According to the documentation\, it's "officially" (as documentation is not always up-to-date) Ken Williams. Effectively\, I can see several people who put work into it\, including Dave Mitchell\, Father Chrysostomos\, Tony Cook\, Dagfinn Ilmari Mannsåker\, Bulk88\, and Steffen Mueller.

If so\, should the ticket queue be moved over to perlbug\, and the dist point at perlbug as well?

Not necessarily. As far as I know\, a core module is allowed to maintain its own RT queue. It depends on what the current people maintaining it find comfortable. rt.perl.org maintains a hefty amount of tickets and I can see why maintaining a separate queue can be easier.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @jkeenan

On Tue Oct 18 02​:35​:16 2016\, xsawyerx@​cpan.org wrote​:

On Sun Oct 16 11​:49​:05 2016\, walde.christian@​gmail.com wrote​:

I ran into a bug in Cwd and while trying to figure out who's responsible\, who can help with fixing it\, where to fix it\, and other related facts\, i found that the situation of the entire dist is very unclear.

Hi Mithaldu\, :)

Let me see if I can help clarify this.

The dist itself still claims Ken Williams is the maintainer.

Yup.

The dist itself on sco and metacpan points at https://rt.cpan.org/Dist/Display.html?Queue=PathTools

I would imagine this grew out of comfort and usage. I'm not aware of a rule that says a core module can not have its own RT queue. (I'm not being sarcastic or cynical.)

Said page lists FLORA\, KJALB\, KWILLIAMS\, RJBS\, SMUELLER as releasers.

Yes. These are people who have released it to CPAN\, separate from core. We try to have as many modules dual-life as possible\, so users may reap the benefits of it without having to upgrade their perl. These are people who are given the right to make a release of a core module outside the core.

This does not make them maintainers or developers of it\, as they might have been helping out with the release process at any point. On the other hand\, it's a good hint to know who else is familiar with the project.

The RT queue has 69 open tickets (more than resolved)\, most of them over 3 years old old.

That is unfortunate. However\, the maintainer(s) (and p5p at large) only have few resources available and tickets can pile up. Some of them might be esoteric and require additional research\, some might require additional feedback from the reporter\, and some might just be lower priority.

Patches are always welcome! :)

The most recent releaser has been RJBS\, presumably in his capacity of pumpking.

Yup.

The most recent release (3.62) contained a fix for a security issue (CVE-2015-8607)\, which would require making a separate CPAN release of this as well\, not to force users to upgrade their perl. RJBS pushed that release out.

RJBS claims he doesn't have a lot of expertise to offer.

I would take RJBS at his word. :)

He made the release since it was an important fix that had to be released\, not because he made the fix and is knowledgeable in the project. This goes back to people who have permissions to release because they are helping out (or in RJBS' situation - are responsible) rather than being intimately familiar with the code.

The fix which resulted in this release was by Tony Cook\, just for reference. Commit 0b6f93036de171c12ba95d415e264d9cf7f4e1fd.

The official repository according to RJBS is blead in /dist/PathTools.

RJBS is correct. You can see this here​: http​://perl5.git.perl.org/perl.git/tree/HEAD​:/dist/PathTools

The committers to that have been a wide variety of perl5porters.

Yup.

Relatedly\, the lack of link to source repo\, and some confusion about responsibility has also been discussed here​: https://rt.cpan.org/Ticket/Display.html?id=116342

As such the questions i ask of p5p is​:

Is p5p collectively currently the responsible maintainer?

Those are two different questions\, unfortunately. "Maintainer" is one thing\, "responsible" is another.

p5p is the responsible party\, but it is not necessarily the current maintainer. The maintainer is one or more people\, usually from p5p.

If not\, who is?

According to the documentation\, it's "officially" (as documentation is not always up-to-date) Ken Williams. Effectively\, I can see several people who put work into it\, including Dave Mitchell\, Father Chrysostomos\, Tony Cook\, Dagfinn Ilmari Mannsåker\, Bulk88\, and Steffen Mueller.

If so\, should the ticket queue be moved over to perlbug\, and the dist point at perlbug as well?

Not necessarily. As far as I know\, a core module is allowed to maintain its own RT queue.

Technically\, yes -- but ...

It depends on what the current people maintaining it find comfortable.

It's difficult to argue that a CPAN distro whose bug queue has 69 open tickets is being *actively* maintained.

rt.perl.org maintains a hefty amount of tickets

Don't I know! Our New + Open total is 1637 as I write. At one point about three years back we were in the mid-1200s\, and we were holding below 1600 until quite recently.

... and I can see why maintaining a separate queue can be easier.

Here is one possible battle plan​:

1. Prepare a new version/release to CPAN which does nothing but change the location for reporting PathTools bugs to rt.perl.org via perlbug. With this\, *new* bugs will be reported to the bug queue of the responsible party\, i.e.\, P5P.

2. Given the size of the remaining queue on rt.cpan.org\, trying to find just one person to serve as *the* maintainer of PathTools is not likely to be successful. We should instead form a *task force* of people who will work through the existing bug queue. (Precedents​: Perl-Toolchain-Gang; the group being assembled to maintain DBIx-Class (hopefully sans acrimony).) This task force would move issues from the older queue to the new one as it deems appropriate and/or as patches are submitted to rt.perl.org.

3. The above presumes the cooperation of the current maintainers/releasors -- who of course may be part of the task force.

4. I recommend that this and other proposals be discussed at the upcoming P5P hackathon Nov 11-14.

Thank you very much.

-- James E Keenan (jkeenan@​cpan.org)

[p5pRT]

From @wchristian

Sawyer\, thanks for taking the time to verify that the facts as i understood them are in fact understood correctly. However\, i have to apologize\, as the questions i asked were a step ahead of the actual questions i did care about (and mentally answered pessimistically\, resulting in the questions you saw).

The questions that are unclear to me are as follows.

Assume an average\, casual Perl developer\, who's largely unaware of p5p and only uses Perl to write things\, grabs stuff from CPAN\, and if a module is broken\, occasionally reports problems or maybe makes a patch. It's not a person from p5p\, not anyone like you or me\, or in fact anyone who'd be regular on IRC. All they have is​: http​://search.cpan.org/~rjbs/PathTools-3.62/

What exactly are they supposed to do\, for this distribution\, in order to\, with a reasonable amount of success\, and a reasonable amount of timeliness​:

- Report a bug and see it responded to and discussed in earnest? - Provide a patch and have it evaluated\, integrated and released?

With the information available there\, such a person could only understand the answers to be​:

- Put a ticket in the RT queue or contact Ken (documented maintainer)\, or contact RJBS (last releaser). - Make a patch by downloading the latest release and creating a diff\, then do the above.

These answers though are wrong or misleading\, since​:

- The documented maintainer has not done any maintenance in 8 years\, so is unlikely to suddenly start again. - The current releaser only did so for an important hotfix\, and is not doing active maintenance. - There are no links to any repository\, resulting in any patches made to not account for the ~12 commits in blead since then. - In the past year only one ticket in the queue was touched by any of the listed maintainers and that was RJBS\, so it's unlikely that any new tickets there at this point would receive much love.

So right now\, it looks like the answer to both of the questions above is​:

You can't do either.

Is this correct?

If not\, what are the correct answers and how can we get them documented in the dist and released?

If it is correct\, should it be changed and what can it realistically be changed to?

[p5pRT]

From @xsawyerx

On 10/18/2016 01​:49 PM\, James E Keenan via RT wrote​:

On Tue Oct 18 02​:35​:16 2016\, xsawyerx@​cpan.org wrote​:

On Sun Oct 16 11​:49​:05 2016\, walde.christian@​gmail.com wrote​: [...]

If so\, should the ticket queue be moved over to perlbug\, and the dist point at perlbug as well? Not necessarily. As far as I know\, a core module is allowed to maintain its own RT queue. Technically\, yes -- but ...

It depends on what the current people maintaining it find comfortable. It's difficult to argue that a CPAN distro whose bug queue has 69 open tickets is being *actively* maintained.

I'm not arguing it is actively maintained.

At the same time though\, let's not fall into the trap of "many tickets equals unmaintained". perl has quite a few tickets and more every week. :)

rt.perl.org maintains a hefty amount of tickets Don't I know! Our New + Open total is 1637 as I write. At one point about three years back we were in the mid-1200s\, and we were holding below 1600 until quite recently.

Indeed. Brian Carpenter and Dan Collins are doing a good job of bringing that ticket count high\, despite your best efforts at cleaning the old ones up. :)

... and I can see why maintaining a separate queue can be easier. Here is one possible battle plan​:

1. Prepare a new version/release to CPAN which does nothing but change the location for reporting PathTools bugs to rt.perl.org via perlbug. With this\, *new* bugs will be reported to the bug queue of the responsible party\, i.e.\, P5P.

2. Given the size of the remaining queue on rt.cpan.org\, trying to find just one person to serve as *the* maintainer of PathTools is not likely to be successful. We should instead form a *task force* of people who will work through the existing bug queue. (Precedents​: Perl-Toolchain-Gang; the group being assembled to maintain DBIx-Class (hopefully sans acrimony).) This task force would move issues from the older queue to the new one as it deems appropriate and/or as patches are submitted to rt.perl.org.

3. The above presumes the cooperation of the current maintainers/releasors -- who of course may be part of the task force.

4. I recommend that this and other proposals be discussed at the upcoming P5P hackathon Nov 11-14.

I think you're raising several interesting and important points.

Moving the queue​:

* I'm not against having the queue now be rt.perl.org\, to reflect the responsibility of p5p to resolve issues and to possibly get more eyes on it. I rarely see RT notifications of new tickets\, even for ones I own myself. This will already move the new tickets to appear on rt.perl.org (and as a result on p5p)\, which means more people will see them. * Another step in this direction would be to move the tickets from rt.cpan.org to rt.perl.org. Closing the original tickets with a note of their new location. This will help put them in one location. * We could then do a release\, as you suggest\, with an update of the location.

Task-force​:

* I think prior to an action such as setting up a special task-force for this module to plow through issues and clearing them\, we should have those reviewed to decide which are important\, which require additional feedback from the reporter\, which are subject to larger decision-marking (API changes)\, which require more research (FS-specific behavior)\, etc. This will allow us to determine how much work there is to do\, the skill of the people required\, and the urgency of issues.

* Once we have this done\, we can prioritize it as part of regular p5p work and elicit the help of any developer familiar with the project. We need to reach out to Ken and determine his current level of involvement. If he's still the "active maintainer"\, then his voice is important here.

I hope I covered everything.

[p5pRT]

From @xsawyerx

On 10/18/2016 02​:45 PM\, Christian Walde via RT wrote​:

[...]

Assume an average\, casual Perl developer\, who's largely unaware of p5p and only uses Perl to write things\, grabs stuff from CPAN\, and if a module is broken\, occasionally reports problems or maybe makes a patch. It's not a person from p5p\, not anyone like you or me\, or in fact anyone who'd be regular on IRC. All they have is​: http​://search.cpan.org/~rjbs/PathTools-3.62/

What exactly are they supposed to do\, for this distribution\, in order to\, with a reasonable amount of success\, and a reasonable amount of timeliness​:

- Report a bug and see it responded to and discussed in earnest? - Provide a patch and have it evaluated\, integrated and released?

With the information available there\, such a person could only understand the answers to be​:

- Put a ticket in the RT queue or contact Ken (documented maintainer)\, or contact RJBS (last releaser). - Make a patch by downloading the latest release and creating a diff\, then do the above.

These answers though are wrong or misleading\, since​:

- The documented maintainer has not done any maintenance in 8 years\, so is unlikely to suddenly start again. - The current releaser only did so for an important hotfix\, and is not doing active maintenance. - There are no links to any repository\, resulting in any patches made to not account for the ~12 commits in blead since then. - In the past year only one ticket in the queue was touched by any of the listed maintainers and that was RJBS\, so it's unlikely that any new tickets there at this point would receive much love.

So right now\, it looks like the answer to both of the questions above is​:

You can't do either.

Is this correct?

I don't think you're wrong on this and I agree this is undesirable\, to say the least.

If not\, what are the correct answers and how can we get them documented in the dist and released?

If it is correct\, should it be changed and what can it realistically be changed to?

I think Jim raised a few possible solutions to this. Let's continue on that front?

[p5pRT]

From @wchristian

On Wed Oct 19 03​:37​:58 2016\, xsawyerx@​gmail.com wrote​:

I don't think you're wrong on this and I agree this is undesirable\, to say the least.

I think Jim raised a few possible solutions to this. Let's continue on that front?

As already mentioned on IRC\, but said here also for the record​: Excellent. Thank you. :)

I agree with Jim's battle plan\, and have the following thoughts on it​:

* I think prior to an action such as setting up a special task-force for this module to plow through issues and clearing them\, we should have those reviewed

I think that would end up being the same thing\, since any such moving would require review of each ticket. Otoh i also agree since "review first\, then move" splits the work up into smaller parts.

Review could be done by anyone by way of leaving a comment in the rt.cpan ticket\, or\, to avoid unnecessary notifications being sent to people\, it could be done via a side channel like Trello. Only the closing of tickets requires action by someone with the right perms.

This combines with your question of figuring out the stated maintainers involvements\, and i found there is a way to answer this conclusively​: Look at CPAN perms. For the involved modules they look as follows​:

Cwd

userid type owner FLORA co-maint P5P KWILLIAMS co-maint P5P P5P modulelist P5P RJBS co-maint P5P SMUELLER co-maint P5P

File​::Spec

userid type owner KJALB co-maint P5P KWILLIAMS modulelist KWILLIAMS P5P first-come P5P RJBS co-maint P5P SMUELLER co-maint P5P

File​::Spec​::AmigaOS

userid type owner RJBS first-come RJBS

File​::Spec​::\<Cygwin|Epoc|Functions|Mac|OS2|Unix|VMS|Win32>

userid type owner KWILLIAMS co-maint P5P P5P first-come P5P RJBS co-maint P5P SMUELLER co-maint P5P

AmigaOS looks like an accident of some kind due to the way RJBS put out the fix for that\, so i think we can leave that one out of consideration.

FLORA and KJALB seem to only be in there for historical reasons or maybe to manage the ticket queue.

KWILLIAMS is the original author\, and has clearly passed his mantle of authority on since 2008.

P5P is the current authority and clear owner of the namespace (bar some fixing needed for Amiga).

RJBS is only involved in there since he did some emergency releases.

SMUELLER seems to have been the de-factor maintainer from 2008 to 2014\, but seems to have lost his supply of tuits.

So after this mail i'll cc FLORA\, KJALB\, KWILLIAMS and SMUELLER in individual replies to try and get their input.

Lastly there is the wider question of​:

What's this module's life cycle supposed to be?

http​://perldoc.perl.org/perlsource.html#Core-modules states things clearly for cpan/\, but for dist/ it only says the repo is canonical\, nothing about the life cycle.

How are releases of File​::Spec/Cwd supposed to be handled?

- Primarily with Perl and to CPAN only security/critical fixes? - Perl and CPAN in tandem? - Primarily CPAN as soon as a release is viable\, and in Perl only to keep new installs up-to-date?

I think once we have those answered\, and AmigaOS perms fixed\, we should move ahead with Jim's step #1 as soon as possible.

[p5pRT]

From @wchristian

Hey Florian\, Kenneth\,

You're listed as COMAINT for Cwd and File​::Spec\, respectively. We're currently trying to figure out how to enliven development for the dist again. Are either of you interested in helping with that or is your comaint at this point more historical?

[p5pRT]

From @wchristian

First off\, sorry if this email went to the wrong person. I shotgunned it to all Ken Williams rt.perl.org knows about\, and intend for this to be received by the Ken William who is currently documented as the maintainer of Cwd/File​::Spec.

We are currently trying to figure out ways to enliven development of the dist again. Do you have any interest in continued involvement\, or do you have any objections to being removed as the documented maintainer and listed as previous maintainer?

[p5pRT]

From @wchristian

Hi Steffen\, you've been the last active maintainer of Cwd/File​::Spec\, but it looks like you've run out of tuits on that one.

We're currently trying to figure out how to enliven development of the dist again. Would you like to be involved with that\, or do you think you're out of tuits on this permanently?

[p5pRT]

From @xsawyerx

On 10/23/2016 04​:53 PM\, Christian Walde via RT wrote​:

Hi Steffen\, you've been the last active maintainer of Cwd/File​::Spec\, but it looks like you've run out of tuits on that one.

Hi Christian\,

I don't think there's need to CC the list (or the ticket\, which is equivalent to emailing the list) on every email you send privately to people. It is considered impolite to suddenly send someone an email\, CC'ing an entire mailing list. It also adds emails to the mailing list which don't add much value in and of themselves.

You can simply include in the ticket the responses you received from those you emailed.

Thank you.

[p5pRT]

From @Leont

On Sun\, Oct 23\, 2016 at 4​:20 PM\, Christian Walde via RT \< perlbug-followup@​perl.org> wrote​:

KWILLIAMS is the original author\, and has clearly passed his mantle of authority on since 2008.

Not quite\, he's more accurately described as the first packager. File​::Spec has been shipped with core since 5.005 (1998) and dual-lifed by Ken in 2004. In fact it was originally a rib taken out of ExtUtils​::MakeMaker (which is why it inherits from File​::Spec).

Lastly there is the wider question of​:

What's this module's life cycle supposed to be?

http​://perldoc.perl.org/perlsource.html#Core-modules states things clearly for cpan/\, but for dist/ it only says the repo is canonical\, nothing about the life cycle.

I think that's because there are various very different reasons for module to be in dist/. In this particular case it makes sense because it's a rather mature and stable distribution\, and changes are likely to be caused by porting efforts (such as AmigaOS recently).

How are releases of File​::Spec/Cwd supposed to be handled?

- Primarily with Perl and to CPAN only security/critical fixes? - Perl and CPAN in tandem? - Primarily CPAN as soon as a release is viable\, and in Perl only to keep new installs up-to-date?

Keeping them in tandem should be the default IMO. I can't see any reason to not do that in this particular case.

Leon

[p5pRT]

From @wchristian

On Mon Oct 24 12​:14​:43 2016\, xsawyerx@​gmail.com wrote​:

[...]

I saw these mails as public-record outreach in the vein of modules@​-related emails\, but next time i consider something like this i'll verify with p5p people first whether it's appropiate. Thanks for the note. :)

On Mon Oct 24 14​:41​:55 2016\, LeonT wrote​:

Not quite\, he's more accurately described as the first packager.

Thanks for that correction\, i had indeed misunderstood that.

I think that's because there are various very different reasons for module to be in dist/. In this particular case it makes sense because it's a rather mature and stable distribution\, and changes are likely to be caused by porting efforts (such as AmigaOS recently).

Looking at the other entries in http​://perldoc.perl.org/perlsource.html#Core-modules it is absolutely clear why this one isn't in there​: It's not only mirrored perl core (/cpan)\, it is not core-only (/lib\, /ext).

I don't think there are any other reasons.

However because of that the exact nature of its lifecycle must be questioned\, and once determined\, documented.

- Primarily with Perl and to CPAN only security/critical fixes? - Perl and CPAN in tandem? - Primarily CPAN as soon as a release is viable\, and in Perl only to keep new installs up-to-date?

Keeping them in tandem should be the default IMO. I can't see any reason to not do that in this particular case.

So you're saying new releases of Pathtools on CPAN should not happen for bugfixes\, only for Perl releases and security fixes?

[p5pRT]

From @tsee

Wow\, terrible round-trip time on my part. I apologize for that. I'm trying to catch up with my email now\, but we just had our second child a month ago and everything is crazy.

On Sun\, 23 Oct 2016 07​:53​:10 -0700\, Mithaldu wrote​:

Hi Steffen\, you've been the last active maintainer of Cwd/File​::Spec\, but it looks like you've run out of tuits on that one.

We're currently trying to figure out how to enliven development of the dist again. Would you like to be involved with that\, or do you think you're out of tuits on this permanently?

Pretty much. For a while now\, I've been trying to at least take action when somebody explicitly pokes me\, but even that's getting a bit shady. My spare time pretty much imploded when we had our first kid two years ago.

For the record​: I'd be the last person to get annoyed by anybody taking over my code and giving it the attention & bug fixing it needs. (Though little of Cwd/File​::Spec is mine\, actually\, but I figured I'd make a bit more of a sweeping statement in case I come up as a blocker in other contexts.)

This all being said\, if somebody needs my help\, please do fire me an email to my CPAN address. I try to read it sufficiently regularly. Also\, all of the good folks at Booking.com that deal in Perl will know how to reach me. :)

Cheers\, Steffen

[p5pRT]

From [Unknown Contact. See original ticket]

Wow\, terrible round-trip time on my part. I apologize for that. I'm trying to catch up with my email now\, but we just had our second child a month ago and everything is crazy.

On Sun\, 23 Oct 2016 07​:53​:10 -0700\, Mithaldu wrote​:

Hi Steffen\, you've been the last active maintainer of Cwd/File​::Spec\, but it looks like you've run out of tuits on that one.

We're currently trying to figure out how to enliven development of the dist again. Would you like to be involved with that\, or do you think you're out of tuits on this permanently?

Pretty much. For a while now\, I've been trying to at least take action when somebody explicitly pokes me\, but even that's getting a bit shady. My spare time pretty much imploded when we had our first kid two years ago.

For the record​: I'd be the last person to get annoyed by anybody taking over my code and giving it the attention & bug fixing it needs. (Though little of Cwd/File​::Spec is mine\, actually\, but I figured I'd make a bit more of a sweeping statement in case I come up as a blocker in other contexts.)

This all being said\, if somebody needs my help\, please do fire me an email to my CPAN address. I try to read it sufficiently regularly. Also\, all of the good folks at Booking.com that deal in Perl will know how to reach me. :)

Cheers\, Steffen

[p5pRT]

From kwilliams@cpan.org

Hi everyone\, thanks for reaching out to straighten things out.

It's true I'm not really involved at all in File​::Spec or Cwd or PathTools development anymore\, so I would definitely vote to make all official ownership fields reflect the fact that P5P is ultimately responsible for maintenance right now.

Personally I do wish that all dual-life modules had their canonical versions (i.e. upstream) as the CPAN release\, and that the version distributed with 'perl' were simply pulled in from CPAN. But my understanding is that the P5P folks generally feel the opposite way\, so that's fine.