the maintainership/upstream situation of the Cwd/File::Spec dist is very unclear #15665
Comments
From @wchristianThis is a bug report for perl from walde.christian@gmail.com, I ran into a bug in Cwd and while trying to figure out who's responsible, The dist itself still claims Ken Williams is the maintainer. The dist itself on sco and metacpan points at 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 The most recent releaser has been RJBS, presumably in his capacity of 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 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 Flags: 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: Locally applied patches: @INC for perl 5.18.4: Environment for perl 5.18.4: |
From @xsawyerxOn Sun Oct 16 11:49:05 2016, walde.christian@gmail.com wrote:
Hi Mithaldu, :) Let me see if I can help clarify this.
Yup.
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.)
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.
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! :)
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.
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 0b6f930.
RJBS is correct. You can see this here:
Yup.
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.
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.
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. |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jkeenanOn Tue Oct 18 02:35:16 2016, xsawyerx@cpan.org wrote:
Technically, yes -- but ...
It's difficult to argue that a CPAN distro whose bug queue has 69 open tickets is being *actively* maintained.
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.
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. -- |
From @wchristianSawyer, 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? 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). 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. 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? |
From @xsawyerxOn 10/18/2016 01:49 PM, James E Keenan via RT wrote:
I'm not arguing it is actively maintained. At the same time though, let's not fall into the trap of "many tickets
Indeed. Brian Carpenter and Dan Collins are doing a good job of bringing
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 Task-force: * I think prior to an action such as setting up a special task-force for * Once we have this done, we can prioritize it as part of regular p5p I hope I covered everything. |
From @xsawyerxOn 10/18/2016 02:45 PM, Christian Walde via RT wrote:
I don't think you're wrong on this and I agree this is undesirable, to
I think Jim raised a few possible solutions to this. Let's continue on |
From @wchristianOn Wed Oct 19 03:37:58 2016, xsawyerx@gmail.com wrote:
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 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 File::Spec userid type owner File::Spec::AmigaOS userid type owner File::Spec::<Cygwin|Epoc|Functions|Mac|OS2|Unix|VMS|Win32> userid type owner 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? I think once we have those answered, and AmigaOS perms fixed, we should move ahead with Jim's step #1 as soon as possible. |
From @wchristianHey 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? |
From @wchristianFirst 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? |
From @wchristianHi 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? |
From @xsawyerxOn 10/23/2016 04:53 PM, Christian Walde via RT wrote:
Hi Christian, I don't think there's need to CC the list (or the ticket, which is You can simply include in the ticket the responses you received from Thank you. |
From @LeontOn Sun, Oct 23, 2016 at 4:20 PM, Christian Walde via RT <
Not quite, he's more accurately described as the first packager. File::Spec
I think that's because there are various very different reasons for module
Keeping them in tandem should be the default IMO. I can't see any reason to Leon |
From @wchristianOn 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:
Thanks for that correction, i had indeed misunderstood that.
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.
So you're saying new releases of Pathtools on CPAN should not happen for bugfixes, only for Perl releases and security fixes? |
From @tseeWow, 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:
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, |
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:
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, |
From kwilliams@cpan.orgHi 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. |
Migrated from rt.perl.org#129896 (status was 'open')
Searchable as RT129896$
The text was updated successfully, but these errors were encountered: