Mailing List Archive

Yes, am gravely concerned! I tried to raise this on committee (
https://perl.topicbox.com/groups/infrastructure/Te92859202f730470-M0ec0cd211f9dcd89a580957c/project-rt-cpan-org-static-hosting)
but didn't get anywhere. The best option at all would be to cancel the
decommissioning (or at least postpone to a much more reasonable timeline),
but I have been unable to even determine the motivations behind the
decision or identify what would be involved in keeping the service up.

I want to be clear that it is totally acceptable for a volunteer to decide
that they can't or won't have the time/energy/enthusiasm to continue a
task. Volunteer effort is greatly appreciated while it is there, but it
cannot be presumed to be provided in perpetuity. However, I find it greatly
distressing that the option for new volunteer(s) to step in and take over
is not being permitted. This is not something that can or should be decided
unilaterally.


On Tue, Jan 19, 2021 at 2:44 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> This isn't directly core's doing, nor problem, but I am attempting to
> raise awareness of the situation because it seems nobody is aware or
> talking about it.
>
> ****
>
> rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules
> [1], is going to be shut down on 1st March this year [2]; 41 days
> from when I write this email.
>
> ****
>
> I am rather concerned about this, as there doesn't appear to be any
> sort of co-ordinated bailout plan or migration of the *huge amount* of
> CPAN modules this is about to affect.
>
> I am furthermore concerned at the total lack of discussion or response
> that has so far been generated; aside from Karen Etheridge I haven't
> seen any noise of upset being generated at all. Nor am I aware of any
> sort of effort to handle what will become a huge outage of a major
> component of the CPAN ecosystem.
>
> I personally have 189 modules in need of migration - somehow. As yet
> I have no clue what I am going to do about it. Existing bugs need to be
> moved somewhere else (and I have no clue how I'm going to fix up URLs
> that currently point to those, in code comments, documentation, blog
> posts, ... anywhere else), and a new for users to report new bugs needs
> to exist. Of special note are the numerous "in progress" tickets I have
> across my distributions, containing ongoing discussions about design
> issues and the like. To say that I am "concerned" is an understatement;
> I am fairly close to panicing about this.
>
> I am quite sure I am but the smallest tip of the iceberg here. Every
> time I mention it on Freenode's #perl or irc.perl.org's #p5p there are
> always new folks who were totally unaware of this fact. This is going
> to hit lots of people in a very hard surprise.
>
> I am therefore interested to know if
>
> a) Perl5 Porters officially, and
>
> b) Individual CPAN authors who happen to subscribe to the
> perl5-porters mailing list
>
> have any sort of response to this; any kind of mass-migration plan or
> thoughts on continuing the service.
>
>
> To emphasise again: in 41 days time the bug tracker used by nearly 80%
> of all of CPAN is going to be shut down and become unavailable for
> either historic or newly-reported bugs. We *need* to find a solution in
> that time.
>
>
> 1: Add the "known to be RT" and "unknown" categories of
> https://cpan.rocks/; because metacpan.org defaults to RT in the
> latter case.
>
> 2: https://log.perl.org/2020/12/rtcpanorg-sunset.html
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>

Hey Paul,


On 1/19/21 11:44 PM, Paul "LeoNerd" Evans wrote:
> This isn't directly core's doing, nor problem, but I am attempting to
> raise awareness of the situation because it seems nobody is aware or
> talking about it.
>
> ****
>
> rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules
> [1], is going to be shut down on 1st March this year [2]; 41 days
> from when I write this email.
>
> ****
>
> I am rather concerned about this, as there doesn't appear to be any
> sort of co-ordinated bailout plan or migration of the *huge amount* of
> CPAN modules this is about to affect.
>
> I am furthermore concerned at the total lack of discussion or response
> that has so far been generated; aside from Karen Etheridge I haven't
> seen any noise of upset being generated at all. Nor am I aware of any
> sort of effort to handle what will become a huge outage of a major
> component of the CPAN ecosystem.
>
> I personally have 189 modules in need of migration - somehow. As yet
> I have no clue what I am going to do about it. Existing bugs need to be
> moved somewhere else (and I have no clue how I'm going to fix up URLs
> that currently point to those, in code comments, documentation, blog
> posts, ... anywhere else), and a new for users to report new bugs needs
> to exist. Of special note are the numerous "in progress" tickets I have
> across my distributions, containing ongoing discussions about design
> issues and the like. To say that I am "concerned" is an understatement;
> I am fairly close to panicing about this.


Without disregarding your concerns, there are both methods to move from
RT to GitHub (which the majority have done) and that rt.cpan will still
be readable so existing links will work, right? If so, does not that
alleviate some of your mentions issues above? (Specifically, existing
tickets need moving, links being fixed up in code, docs, and blog posts.)


New tickets, existing discussions, and any heavy usage of customized RT
tickets will clearly pose a problem.

> I am quite sure I am but the smallest tip of the iceberg here. Every
> time I mention it on Freenode's #perl or irc.perl.org's #p5p there are
> always new folks who were totally unaware of this fact. This is going
> to hit lots of people in a very hard surprise.
>
> I am therefore interested to know if
>
> a) Perl5 Porters officially, and
>
> b) Individual CPAN authors who happen to subscribe to the
> perl5-porters mailing list
>
> have any sort of response to this; any kind of mass-migration plan or
> thoughts on continuing the service.


This is infrastructure maintained by NOC volunteers. What would you
suggest Perl 5 Porters do?


> To emphasise again: in 41 days time the bug tracker used by nearly 80%
> of all of CPAN is going to be shut down and become unavailable for
> either historic or newly-reported bugs. We *need* to find a solution in
> that time.
>
>
> 1: Add the "known to be RT" and "unknown" categories of
> https://cpan.rocks/; because metacpan.org defaults to RT in the
> latter case.
>
> 2: https://log.perl.org/2020/12/rtcpanorg-sunset.html
>

On Wed, 20 Jan 2021 00:27:47 +0100
Sawyer X <xsawyerx@gmail.com> wrote:

> Without disregarding your concerns, there are both methods to move
> from RT to GitHub (which the majority have done)

I'm not sure where you can quote "the majority" from.

E.g. https://cpan.rocks/ shows that a mere 20.9% of all CPAN modules
are using GitHub as their bugtracker. A total of 32.4% are using git of
some flavour for source control, though it doesn't give a breakdown on
what proportion of that is on github vs. other places.

*Even if* every distribution which hosts source code on github were to
migrate its bug tracker there too (and some people have those turned
off deliberately for whatever reason), this does not help the >= 67.6%
of distributions not hosted on any flavour of git. That's two thirds of
them.

Plus a lot of these non-github distributions haven't had releases in
*years*, maybe a decade or so. Are we going to track down every last
developer to get them to push a new update to CPAN with a new
bughosting URL in the distribution's metadata? Again my initial reason
for starting this email thread is I don't think many people are even
aware that this shutdown is going to happen.

There is also the question of where they should migrate to. I would feel
at the very least somewhat nervous about the entire Perl language
ecosystem saying "We give up, everyone must now use github for all their
bugtrackers". Individual projects and authors could decide to do that
but the fact that two thirds have not done so is at least some amount
of signal here. For the past 20-odd years, rt.cpan has been provided as
part of the whole bundle of "ecosystem stuff". We've now got two months
to airlift everyone off it onto something else - as yet still
unspecified what.

> and that rt.cpan
> will still be readable so existing links will work, right?

I haven't seen any mention that this will be the case. I saw someone
offering to set up some hosting for that, but there has been no firm
public statement that this will definitely happen.

> If so,
> does not that alleviate some of your mentions issues above?
> (Specifically, existing tickets need moving, links being fixed up in
> code, docs, and blog posts.)

A small amount, but not much.

> New tickets, existing discussions, and any heavy usage of customized
> RT tickets will clearly pose a problem.

Indeed. I still have links in places that point to currently-open bugs
that specifically request these be the places to hold discussions; e.g.
the TODO notes in

https://metacpan.org/pod/Future::AsyncAwait

or

https://metacpan.org/pod/Object::Pad

> > I am quite sure I am but the smallest tip of the iceberg here. Every
> > time I mention it on Freenode's #perl or irc.perl.org's #p5p there
> > are always new folks who were totally unaware of this fact. This is
> > going to hit lots of people in a very hard surprise.
> >
> > I am therefore interested to know if
> >
> > a) Perl5 Porters officially, and
> >
> > b) Individual CPAN authors who happen to subscribe to the
> > perl5-porters mailing list
> >
> > have any sort of response to this; any kind of mass-migration plan
> > or thoughts on continuing the service.
>
>
> This is infrastructure maintained by NOC volunteers. What would you
> suggest Perl 5 Porters do?

I specifically said "response". I'm aware that P5P aren't in control of
this situation, but I also haven't heard any words of statement about
thoughts of it. Do we approve? Do we disapprove? Are we delighted,
unhappy - is anyone else in as much of a panic as I am?

Personally I find it very worrying that it seems like a single
volunteer can decide "I've given up, I'm turning this off", and nobody
worries about that situation. Of course people can decide to step down
and move on to other things, but they shouldn't be able to destroy a
major part of the CPAN ecosystem while they do so.

If it was threatened that PAUSE or metacpan.org were to be turned off
in a couple of months, would P5P just shrug and go "Ho hum", or would
there at least be noises and offers of "Hey, can we help, or find a
replacement by then?" It feels to me like a lot of people are at least
by inaction allowing this to be shut down.

I am trying to understand why.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

Hi again :)

On Tue, Jan 19, 2021 at 5:28 PM Sawyer X <xsawyerx@gmail.com> wrote:

> This is infrastructure maintained by NOC volunteers. What would you
> suggest Perl 5 Porters do?

I volunteer as the "community outreach" person with Fosshost[1] which
is a UK based non-profit started in 2020. We provide no-cost virtual
machines, mirrors, CDN and other goodies to FOSS projects. If the
pain here could be lessened by having a one or a few VMs I would be
happy to request expedited review of an application.

Note, this does not address maintenance of the VM(s). Fosshost
volunteers are generally "hands-off" provided services and have
hypervisor but not VM access once things are provisioned.

[1] https://fosshost.org - overview, "brag rag" of supported projects,
and link to apply (webform, much javascript)

Cheers,
Corwin

On Tue, 19 Jan 2021 18:10:37 -0600
Corwin Brust <corwin@bru.st> wrote:

> Hi again :)
>
> On Tue, Jan 19, 2021 at 5:28 PM Sawyer X <xsawyerx@gmail.com> wrote:
>
> > This is infrastructure maintained by NOC volunteers. What would you
> > suggest Perl 5 Porters do?
>
> I volunteer as the "community outreach" person with Fosshost[1] which
> is a UK based non-profit started in 2020. We provide no-cost virtual
> machines, mirrors, CDN and other goodies to FOSS projects. If the
> pain here could be lessened by having a one or a few VMs I would be
> happy to request expedited review of an application.

That could well be a handy offer that might help, or might not.
However, we on P5P aren't the source of the problem and can't comment
on what that might be.

The original announcement is here:

https://log.perl.org/2020/12/rtcpanorg-sunset.html

The quoted reasons being:

> rt.cpan.org will be sunset on March 1st, 2021 due to low and
> declining use.

That doesn't feel like the sort of situation that offering more hosting
hardware can help.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, 20 Jan 2021 00:27:47 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

> This is infrastructure maintained by NOC volunteers. What would you
> suggest Perl 5 Porters do?

Not sure if this is all possible in reality, but this is technically a feasible path forward.

1. See if we can find a different volunteer to take over rt.cpan.irg

2.a) See if we can find people to talk to said volunteer directly and convincingly. (e.g. someone who know the relevant person)
2.b) See if we can find people who can talk to said volunteer authoritatively. (e.g. whoever pays the server bill)

3. Ask people from 2. to convince said original volunteers to hand over maintenance to another volunteer instead of setting the thing on fire and throwing the keys away.

> If so, does not that alleviate some of your mentions issues above?

Only a miniscule part. The biggest issue is all the dists that won't get updated will suddenly have whatever well-meaning emails may come in drop into a black hole.

--
With regards,
Christian Walde

On Wed, Jan 20, 2021 at 1:03 AM Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
> On Wed, 20 Jan 2021 00:27:47 +0100
> Sawyer X <xsawyerx@gmail.com> wrote:
>
> > Without disregarding your concerns, there are both methods to move
> > from RT to GitHub (which the majority have done)
>
> I'm not sure where you can quote "the majority" from.
>
> E.g. https://cpan.rocks/ shows that a mere 20.9% of all CPAN modules
> are using GitHub as their bugtracker. A total of 32.4% are using git of
> some flavour for source control, though it doesn't give a breakdown on
> what proportion of that is on github vs. other places.
>
> *Even if* every distribution which hosts source code on github were to
> migrate its bug tracker there too (and some people have those turned
> off deliberately for whatever reason), this does not help the >= 67.6%
> of distributions not hosted on any flavour of git. That's two thirds of
> them.
>
> Plus a lot of these non-github distributions haven't had releases in
> *years*, maybe a decade or so. Are we going to track down every last
> developer to get them to push a new update to CPAN with a new
> bughosting URL in the distribution's metadata? Again my initial reason
> for starting this email thread is I don't think many people are even
> aware that this shutdown is going to happen.

Yeah, this. It's not that this can't be fixed, it's that the amount of
work for the community is huge. We're literally talking about
re-releasing tens of thousands of distributions, by thousands of
authors. For me it means migrating and re-releasing ±85 dists.

Leon

On Wed, 20 Jan 2021 01:28:41 +0100, Leon Timmermans <fawaka@gmail.com> wrote:

> On Wed, Jan 20, 2021 at 1:03 AM Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
>> On Wed, 20 Jan 2021 00:27:47 +0100
>> Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> > Without disregarding your concerns, there are both methods to move
>> > from RT to GitHub (which the majority have done)
>>
>> I'm not sure where you can quote "the majority" from.
>>
>> E.g. https://cpan.rocks/ shows that a mere 20.9% of all CPAN modules
>> are using GitHub as their bugtracker. A total of 32.4% are using git of
>> some flavour for source control, though it doesn't give a breakdown on
>> what proportion of that is on github vs. other places.
>>
>> *Even if* every distribution which hosts source code on github were to
>> migrate its bug tracker there too (and some people have those turned
>> off deliberately for whatever reason), this does not help the >= 67.6%
>> of distributions not hosted on any flavour of git. That's two thirds of
>> them.
>>
>> Plus a lot of these non-github distributions haven't had releases in
>> *years*, maybe a decade or so. Are we going to track down every last
>> developer to get them to push a new update to CPAN with a new
>> bughosting URL in the distribution's metadata? Again my initial reason
>> for starting this email thread is I don't think many people are even
>> aware that this shutdown is going to happen.
>
> Yeah, this. It's not that this can't be fixed, it's that the amount of
> work for the community is huge. We're literally talking about
> re-releasing tens of thousands of distributions, by thousands of
> authors. For me it means migrating and re-releasing ?85 dists.
>
> Leon
>

And there is no technical solution to prevent the data loss if rt.cpan.org goes away that isn't iffy on legal and moral grounds.

--
With regards,
Christian Walde

On Wed, 20 Jan 2021 01:27:16 +0100
"Christian Walde" <walde.christian@gmail.com> wrote:

> > If so, does not that alleviate some of your mentions issues above?
>
> Only a miniscule part. The biggest issue is all the dists that won't
> get updated will suddenly have whatever well-meaning emails may come
> in drop into a black hole.

Yes - let us not forget that choosing to migrate to a new bugtracker is
up to the dist's author, as a service to the users of that dist who may
report bugs.

If nothing else happens and this shutdown goes ahead as planned on
1st March, that will leave *thousands* of distributions with no
bugtracker at all. What are users who wish to report bugs going to do
at that point? Often the bugtracker is their only means of contact with
the upstream author. If that breaks - well they can't even report the
bug that the bugtracker is now broken, can they? ;)

It is *imperative* that after 1st March, there should be *some* kind of
user->author communication ability to cover all those dists who haven't
specified any other means of handling it. Otherwise, 80% of all CPAN
distributions become - quite literally - unsupported.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

Hey Bryan,

I remember you being in talks about the below topic. Is there any chance you can tell is what the situation on your end is?

--
With regards,
Christian Walde

On Tue, 19 Jan 2021 23:44:25 +0100, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> This isn't directly core's doing, nor problem, but I am attempting to
> raise awareness of the situation because it seems nobody is aware or
> talking about it.
>
> ****
>
> rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules
> [1], is going to be shut down on 1st March this year [2]; 41 days
> from when I write this email.
>
> ****
>
> I am rather concerned about this, as there doesn't appear to be any
> sort of co-ordinated bailout plan or migration of the *huge amount* of
> CPAN modules this is about to affect.
>
> I am furthermore concerned at the total lack of discussion or response
> that has so far been generated; aside from Karen Etheridge I haven't
> seen any noise of upset being generated at all. Nor am I aware of any
> sort of effort to handle what will become a huge outage of a major
> component of the CPAN ecosystem.
>
> I personally have 189 modules in need of migration - somehow. As yet
> I have no clue what I am going to do about it. Existing bugs need to be
> moved somewhere else (and I have no clue how I'm going to fix up URLs
> that currently point to those, in code comments, documentation, blog
> posts, ... anywhere else), and a new for users to report new bugs needs
> to exist. Of special note are the numerous "in progress" tickets I have
> across my distributions, containing ongoing discussions about design
> issues and the like. To say that I am "concerned" is an understatement;
> I am fairly close to panicing about this.
>
> I am quite sure I am but the smallest tip of the iceberg here. Every
> time I mention it on Freenode's #perl or irc.perl.org's #p5p there are
> always new folks who were totally unaware of this fact. This is going
> to hit lots of people in a very hard surprise.
>
> I am therefore interested to know if
>
> a) Perl5 Porters officially, and
>
> b) Individual CPAN authors who happen to subscribe to the
> perl5-porters mailing list
>
> have any sort of response to this; any kind of mass-migration plan or
> thoughts on continuing the service.
>
>
> To emphasise again: in 41 days time the bug tracker used by nearly 80%
> of all of CPAN is going to be shut down and become unavailable for
> either historic or newly-reported bugs. We *need* to find a solution in
> that time.
>
>
> 1: Add the "known to be RT" and "unknown" categories of
> https://cpan.rocks/; because metacpan.org defaults to RT in the
> latter case.
>
> 2: https://log.perl.org/2020/12/rtcpanorg-sunset.html

> On 1/19/21 11:44 PM, Paul "LeoNerd" Evans wrote:

> > To emphasise again: in 41 days time the bug tracker used by nearly 80%
> > of all of CPAN is going to be shut down and become unavailable for
> > either historic or newly-reported bugs. We *need* to find a solution in
> > that time.

On Wed, Jan 20, 2021 at 12:27:47AM +0100, Sawyer X wrote:
> This is infrastructure maintained by NOC volunteers. What would you suggest
> Perl 5 Porters do?

Can we estimate what the cost would be to *hire* someone
to administer the existing system?

Perhaps donations could support this resource until we have
a smooth path forward? I, for one, would contribute.

Can the Perl Foundation receive funds for this purpose?
I think many in the community would pony up to help.

--
Joel Roth

On 1/20/21 4:25 AM, Joel Roth wrote:
>> On 1/19/21 11:44 PM, Paul "LeoNerd" Evans wrote:
>
>>> To emphasise again: in 41 days time the bug tracker used by nearly 80%
>>> of all of CPAN is going to be shut down and become unavailable for
>>> either historic or newly-reported bugs. We *need* to find a solution in
>>> that time.
>
> On Wed, Jan 20, 2021 at 12:27:47AM +0100, Sawyer X wrote:
>> This is infrastructure maintained by NOC volunteers. What would you suggest
>> Perl 5 Porters do?
>
> Can we estimate what the cost would be to *hire* someone
> to administer the existing system?
>
> Perhaps donations could support this resource until we have
> a smooth path forward? I, for one, would contribute.
>
> Can the Perl Foundation receive funds for this purpose?
> I think many in the community would pony up to help.


Indeed. If there is a straight-forward solution which involves putting
in a reasonably amount of money, it's not a problem, it's an expense. I,
too, will donate.

--
Eric Herman

> On 2021-01-20 01:41:25, Christian Walde wrote:
>
> I remember you being in talks about the below topic. Is there any chance you
> can tell is what the situation on your end is?

Robert kindly gave me access to the VM running RT currently, and I started
poking a few weeks ago, but work is currently consuming about 12 hours of every
day, and my kids whatever's left. :-)

My goal is to get it migrated into some portable state this weekend, and then
talk about where a more permanent home might be once I have it running. I'm
happy to update this thread with progress in a few days.

Cheers.
--
bdha

Hi Bryan,

Thank you for including me on this. Obviously your real life must take priority!

Would there be a way to open up access a bit to the information on a read-only basis? If you wanted to express requirements in a way so people could jump in and help you, I am confident there would be a lot of takers!

Best regards,
Ed

From: Bryan Horstmann-Allen<mailto:bryan@pobox.com>
Sent: 21 January 2021 22:25
To: Christian Walde<mailto:walde.christian@gmail.com>
Cc: Perl5 Porters<mailto:perl5-porters@perl.org>; "Paul "LeoNerd" Evans"<mailto:leonerd@leonerd.org.uk>; Bryan Horstmann-Allen<mailto:bryan@pobox.com>; ej_zg@hotmail.com<mailto:ej_zg@hotmail.com>
Subject: Re: FYI rt.cpan.org is going away

> On 2021-01-20 01:41:25, Christian Walde wrote:
>
> I remember you being in talks about the below topic. Is there any chance you
> can tell is what the situation on your end is?

Robert kindly gave me access to the VM running RT currently, and I started
poking a few weeks ago, but work is currently consuming about 12 hours of every
day, and my kids whatever's left. :-)

My goal is to get it migrated into some portable state this weekend, and then
talk about where a more permanent home might be once I have it running. I'm
happy to update this thread with progress in a few days.

Cheers.
--
bdha

Additionally: those interested folks I alluded to, many are on the IRC #london.pm on irc.perl.org. If you were to join that at least for this period, that would be a medium to hopefully get instant interaction with motivated potential helpers.

From: Ed .<mailto:ej_zg@hotmail.com>
Sent: 21 January 2021 22:44
To: bryan@pobox.com<mailto:bryan@pobox.com>; Christian Walde<mailto:walde.christian@gmail.com>
Cc: Perl5 Porters<mailto:perl5-porters@perl.org>; "Paul "LeoNerd" Evans"<mailto:leonerd@leonerd.org.uk>; Bryan Horstmann-Allen<mailto:bryan@pobox.com>
Subject: RE: FYI rt.cpan.org is going away

Hi Bryan,

Thank you for including me on this. Obviously your real life must take priority!

Would there be a way to open up access a bit to the information on a read-only basis? If you wanted to express requirements in a way so people could jump in and help you, I am confident there would be a lot of takers!

Best regards,
Ed

From: Bryan Horstmann-Allen<mailto:bryan@pobox.com>
Sent: 21 January 2021 22:25
To: Christian Walde<mailto:walde.christian@gmail.com>
Cc: Perl5 Porters<mailto:perl5-porters@perl.org>; "Paul "LeoNerd" Evans"<mailto:leonerd@leonerd.org.uk>; Bryan Horstmann-Allen<mailto:bryan@pobox.com>; ej_zg@hotmail.com<mailto:ej_zg@hotmail.com>
Subject: Re: FYI rt.cpan.org is going away

> On 2021-01-20 01:41:25, Christian Walde wrote:
>
> I remember you being in talks about the below topic. Is there any chance you
> can tell is what the situation on your end is?

Robert kindly gave me access to the VM running RT currently, and I started
poking a few weeks ago, but work is currently consuming about 12 hours of every
day, and my kids whatever's left. :-)

My goal is to get it migrated into some portable state this weekend, and then
talk about where a more permanent home might be once I have it running. I'm
happy to update this thread with progress in a few days.

Cheers.
--
bdha

On Thu, 21 Jan 2021 17:24:58 -0500
Bryan Horstmann-Allen <bryan@pobox.com> wrote:

> > On 2021-01-20 01:41:25, Christian Walde wrote:
> >
> > I remember you being in talks about the below topic. Is there any
> > chance you can tell is what the situation on your end is?
>
> Robert kindly gave me access to the VM running RT currently, and I
> started poking a few weeks ago, but work is currently consuming about
> 12 hours of every day, and my kids whatever's left. :-)
>
> My goal is to get it migrated into some portable state this weekend,
> and then talk about where a more permanent home might be once I have
> it running. I'm happy to update this thread with progress in a few
> days.

If you need any more emergency assistance please feel free to prod me.
Perl literally is my fulltime job these days, so if getting more hands
on things would help I'd be happy to lend them.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Thu, 21 Jan 2021 23:24:58 +0100, Bryan Horstmann-Allen <bryan@pobox.com> wrote:

>> On 2021-01-20 01:41:25, Christian Walde wrote:
>>
>> I remember you being in talks about the below topic. Is there any chance you
>> can tell is what the situation on your end is?
>
> Robert kindly gave me access to the VM running RT currently, and I started
> poking a few weeks ago, but work is currently consuming about 12 hours of every
> day, and my kids whatever's left. :-)
>
> My goal is to get it migrated into some portable state this weekend, and then
> talk about where a more permanent home might be once I have it running. I'm
> happy to update this thread with progress in a few days.
>
> Cheers.

That is absolutely amazing news to us here and the entire perl toolchain and thousands of authors who may not end up forced to do rereleases.

Thank you so much.

And, whatever help you might end up needing, please do let us know. :)

--
With regards,
Christian Walde

On Tue, Jan 19, 2021 at 2:44 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

>
> rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules
>
>
To be blunt, this statistic is not correct.

It depends on your definition of "used", but for my definition of "used"
it's much smaller -- in the low single digit %s.

You may feel disproportionately affected because you have a lot of
modules. The statistics tell me that the vast majority of them have never
had a bug filed against them.

-R

On Sat, 23 Jan 2021 19:16:32 +0100, Robert Spier <rspier@pobox.com> wrote:

> On Tue, Jan 19, 2021 at 2:44 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>
>> rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules
>>
>
> To be blunt, this statistic is not correct.
>
> It depends on your definition of "used", but for my definition of "used" it's much smaller -- in the low single digit >%s.
>
> You may feel disproportionately affected because you have a lot of modules. The statistics tell me that the vast >majority of them have never had a bug filed against them.
>
> -R

"Used" in this case is factually anything which may ever receive a mail that way, because any other definition provokes data loss, and the one thing that cannot be abided is data loss.

If you could demonstrate that data loss would not happen with a certainty approaching guarantee, that would be a convincing argument.

--
With regards,
Christian Walde

On 1/20/21 1:02 AM, Paul "LeoNerd" Evans wrote:
> On Wed, 20 Jan 2021 00:27:47 +0100
> Sawyer X <xsawyerx@gmail.com> wrote:
>
>> Without disregarding your concerns, there are both methods to move
>> from RT to GitHub (which the majority have done)
> I'm not sure where you can quote "the majority" from.
>
> E.g. https://cpan.rocks/ shows that a mere 20.9% of all CPAN modules
> are using GitHub as their bugtracker. A total of 32.4% are using git of
> some flavour for source control, though it doesn't give a breakdown on
> what proportion of that is on github vs. other places.


I meant that for people who moved elsewhere already, the single largest
hosting provider is GitHub.


>
> *Even if* every distribution which hosts source code on github were to
> migrate its bug tracker there too (and some people have those turned
> off deliberately for whatever reason), this does not help the >= 67.6%
> of distributions not hosted on any flavour of git. That's two thirds of
> them.


This isn't accurate. I refer to this further down, but to create the
context, those 67% are not about "this isn't hosted on any flavor of
Git" but I believe it's "we don't know of any public hosting of this
repository." The author might host it in an unidentified one, not link
to it, or host it privately (whether versioned or not).


>
> Plus a lot of these non-github distributions haven't had releases in
> *years*, maybe a decade or so. Are we going to track down every last
> developer to get them to push a new update to CPAN with a new
> bughosting URL in the distribution's metadata? Again my initial reason
> for starting this email thread is I don't think many people are even
> aware that this shutdown is going to happen.
>
> There is also the question of where they should migrate to. I would feel
> at the very least somewhat nervous about the entire Perl language
> ecosystem saying "We give up, everyone must now use github for all their
> bugtrackers". Individual projects and authors could decide to do that
> but the fact that two thirds have not done so is at least some amount
> of signal here. For the past 20-odd years, rt.cpan has been provided as
> part of the whole bundle of "ecosystem stuff". We've now got two months
> to airlift everyone off it onto something else - as yet still
> unspecified what.


I think it's really unfair to view this as "the entire Perl language
ecosystem saying 'we give up, everyone must now use github [...]'." You
had volunteers who provided a service. That service - while is still
useful for some - is no longer even remotely worthwhile maintaining for
those volunteers. That's it. "The Perl Language" has not "given up" or
has told anyone where to go and what to do.


I'm not saying RT isn't useful. I think there is a set of scenarios in
which RT is useful:


1. Posting patches for unmaintained code.

2. A ticket system when an author does not host their code publicly.
(The 67%, of which we don't know how much is actually used or useful.)

3. Based on your comments below, using RT as a form of CPAN::Forum.

4. Having discussions with unauthenticated users via email.


The way I see it:


1. Yeah, this sucks. Is it enough to keep it running? Not IMHO.

2. Sure, if the overhead is low. It isn't. It's money not well spent.
There are numerous ticket system to use, many for free.

3. See #2.

4. I think this is a very small "nice-to-have" for a *really* big cost.


I don't know if I'm missing more use-cases that fall under these, but I
think the bigger question is not whether we all agree on the benefits or
comments on them, but rather how we deal with the existing situation.
That's aside from when RT is useful or not.


I think the strongest reason that comes up here is "it existed so it
must continue to exist" and not "this serves a purpose nothing else can
or should." I strongly disagree with the latter. Neither of these
reasons are going to make NOC continue maintaining it. I doubt there is
anyone else who would properly maintain it, given the amount of time it
requires and for the little gain it provides nowadays.


>
>> and that rt.cpan
>> will still be readable so existing links will work, right?
> I haven't seen any mention that this will be the case. I saw someone
> offering to set up some hosting for that, but there has been no firm
> public statement that this will definitely happen.


Okay, this I interpreted from the post. We don't actually know this,
you're right.


>
>> If so,
>> does not that alleviate some of your mentions issues above?
>> (Specifically, existing tickets need moving, links being fixed up in
>> code, docs, and blog posts.)
> A small amount, but not much.
>
>> New tickets, existing discussions, and any heavy usage of customized
>> RT tickets will clearly pose a problem.
> Indeed. I still have links in places that point to currently-open bugs
> that specifically request these be the places to hold discussions; e.g.
> the TODO notes in
>
> https://metacpan.org/pod/Future::AsyncAwait
>
> or
>
> https://metacpan.org/pod/Object::Pad


I think there's a problem here in the expectations. You're assuming that
a ticket system be used as a forum. Just because you use it as such does
not mean that you can depend on it for it. I understand your concerns
are much greater because of how you use RT.


>
>>> I am quite sure I am but the smallest tip of the iceberg here. Every
>>> time I mention it on Freenode's #perl or irc.perl.org's #p5p there
>>> are always new folks who were totally unaware of this fact. This is
>>> going to hit lots of people in a very hard surprise.
>>>
>>> I am therefore interested to know if
>>>
>>> a) Perl5 Porters officially, and
>>>
>>> b) Individual CPAN authors who happen to subscribe to the
>>> perl5-porters mailing list
>>>
>>> have any sort of response to this; any kind of mass-migration plan
>>> or thoughts on continuing the service.
>>
>> This is infrastructure maintained by NOC volunteers. What would you
>> suggest Perl 5 Porters do?
> I specifically said "response". I'm aware that P5P aren't in control of
> this situation, but I also haven't heard any words of statement about
> thoughts of it. Do we approve?


Approve? We don't have a say in it. Someone who is not us has given 17
years of their life to maintain it and they want to stop. What do you
mean, do we approve?


> Do we disapprove? Are we delighted,
> unhappy - is anyone else in as much of a panic as I am?


Some are as concerned as you are, some aren't as concerned. I don't
think anyone is delighted in it being stopped. I can tell you I'm not
surprised.


>
> Personally I find it very worrying that it seems like a single
> volunteer can decide "I've given up, I'm turning this off", and nobody
> worries about that situation. Of course people can decide to step down
> and move on to other things, but they shouldn't be able to destroy a
> major part of the CPAN ecosystem while they do so.


These people received no money, barely any recognition, zero support,
had to deal with a ton of crap because they care. Now that they can't
continue doing it, it turned into "you shouldn't be allowed to do that."


>
> If it was threatened that PAUSE or metacpan.org were to be turned off
> in a couple of months, would P5P just shrug and go "Ho hum", or would
> there at least be noises and offers of "Hey, can we help, or find a
> replacement by then?" It feels to me like a lot of people are at least
> by inaction allowing this to be shut down.


Very, very different situation.


RT has numerous alternatives, many of which serve its purposes far
better. PAUSE is *the* only interface. It also has several active
contributors trying to help maintain it. (Whether it's easy or not, I
don't dare venture.) If RT goes down, uploads and downloads are
available, MetaCPAN and its API is available, testing is available, etc.
You just won't be able to post an issue to RT or view something that was
only in RT. If, as the NOC post mentioned, the data will be available,
then it's just opening or responding to tickets that are on RT. That's
the only disruption. Whether it's big or small for you is another
matter, but definitely not the comparison of RT to PAUSE.

On 1/20/21 1:41 AM, Paul "LeoNerd" Evans wrote:
> On Wed, 20 Jan 2021 01:27:16 +0100
> "Christian Walde" <walde.christian@gmail.com> wrote:
>
>>> If so, does not that alleviate some of your mentions issues above?
>> Only a miniscule part. The biggest issue is all the dists that won't
>> get updated will suddenly have whatever well-meaning emails may come
>> in drop into a black hole.
> Yes - let us not forget that choosing to migrate to a new bugtracker is
> up to the dist's author, as a service to the users of that dist who may
> report bugs.
>
> If nothing else happens and this shutdown goes ahead as planned on
> 1st March, that will leave *thousands* of distributions with no
> bugtracker at all. What are users who wish to report bugs going to do
> at that point?


They will need to:


1. Look at the documentation and search for "reporting a bug."

2. Reach out to the author via their email. If the author has a public
hosting, they will likely point them there.

3. Search for the project on a hosting provider.


Many people jump to #3 because it could yield a faster response, myself
included.


In any case, these are the normal steps when wanting to report a bug on
a project.



> Often the bugtracker is their only means of contact with
> the upstream author. If that breaks - well they can't even report the
> bug that the bugtracker is now broken, can they? ;)


If the author wants bugs reported, they will include information on how
to do this or will respond in their email.


>
> It is *imperative* that after 1st March, there should be *some* kind of
> user->author communication ability to cover all those dists who haven't
> specified any other means of handling it. Otherwise, 80% of all CPAN
> distributions become - quite literally - unsupported.


Again, there is. These authors can provide information on how to report
bugs and they can respond to emails.


Put differently, if an author doesn't provide any information on how to
report bugs and refuses to respond to emails (or even has an
unresponsive email), then... do they really want to receive your tickets?


>

On 1/20/21 11:34 PM, Eric Herman wrote:
> On 1/20/21 4:25 AM, Joel Roth wrote:
>>> On 1/19/21 11:44 PM, Paul "LeoNerd" Evans wrote:
>>
>>>> To emphasise again: in 41 days time the bug tracker used by nearly 80%
>>>> of all of CPAN is going to be shut down and become unavailable for
>>>> either historic or newly-reported bugs. We *need* to find a
>>>> solution in
>>>> that time.
>>
>> On Wed, Jan 20, 2021 at 12:27:47AM +0100, Sawyer X wrote:
>>> This is infrastructure maintained by NOC volunteers. What would you
>>> suggest
>>> Perl 5 Porters do?
>>
>> Can we estimate what the cost would be to *hire* someone
>> to administer the existing system?
>>
>> Perhaps donations could support this resource until we have
>> a smooth path forward? I, for one, would contribute.
>>
>> Can the Perl Foundation receive funds for this purpose?
>> I think many in the community would pony up to help.
>
>
> Indeed. If there is a straight-forward solution which involves putting
> in a reasonably amount of money, it's not a problem, it's an expense.
> I, too, will donate.


This assumes on a major benefit to this expenditure. I personally doubt
the benefit outweighs the cost.

On Sat, Jan 23, 2021 at 7:17 PM Robert Spier <rspier@pobox.com> wrote:
> To be blunt, this statistic is not correct.
>
> It depends on your definition of "used", but for my definition of "used" it's much smaller -- in the low single digit %s.
>
> You may feel disproportionately affected because you have a lot of modules. The statistics tell me that the vast majority of them have never had a bug filed against them.

That argument boils down to "people aren't filing enough bugs against
CPAN modules, therefore a bug tracker isn't necessary". The ecosystem
is relatively rich in mature modules, so of course there will be few
new bug reports. And pervasive support of a bug tracker was essential
to get there.

Don't get me wrong, if you don't feel like it's a useful use of your
time because of this then that's entirely valid, but for downstream
users and especially packagers for example it is absolutely essential
that every package has a public bugtracker. Losing that would be felt
by a lot of people, authors and users alike.

Can we achieve the same without rt.cpan.org? Of course, but that would
be a lot more work than rt.cpan.org in the air.

Leon

> On Jan 24, 2021, at 07:20, Leon Timmermans <fawaka@gmail.com> wrote:
>
> it is absolutely essential
> that every package has a public bugtracker.

What about a PrePAN-like setup where GitHub becomes the bug tracker for anything that lacks something else? Then folks can keep posting patches, etc.

-F

On Sun, 24 Jan 2021 12:42:54 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

>
> On 1/20/21 11:34 PM, Eric Herman wrote:
>> On 1/20/21 4:25 AM, Joel Roth wrote:
>>>> On 1/19/21 11:44 PM, Paul "LeoNerd" Evans wrote:
>>>
>>>>> To emphasise again: in 41 days time the bug tracker used by nearly 80%
>>>>> of all of CPAN is going to be shut down and become unavailable for
>>>>> either historic or newly-reported bugs. We *need* to find a
>>>>> solution in
>>>>> that time.
>>>
>>> On Wed, Jan 20, 2021 at 12:27:47AM +0100, Sawyer X wrote:
>>>> This is infrastructure maintained by NOC volunteers. What would you
>>>> suggest
>>>> Perl 5 Porters do?
>>>
>>> Can we estimate what the cost would be to *hire* someone
>>> to administer the existing system?
>>>
>>> Perhaps donations could support this resource until we have
>>> a smooth path forward? I, for one, would contribute.
>>>
>>> Can the Perl Foundation receive funds for this purpose?
>>> I think many in the community would pony up to help.
>>
>>
>> Indeed. If there is a straight-forward solution which involves putting
>> in a reasonably amount of money, it's not a problem, it's an expense.
>> I, too, will donate.
>
>
> This assumes on a major benefit to this expenditure. I personally doubt
> the benefit outweighs the cost.

Requests for data on this have been made multiple times by various people and outright rejected.

I cite:

rjbs:
>>>>>> The question of rt.cpan.org's continued operation is an ongoing one.

rob:
>>>>> Depends who you ask.

ether:
>>>> Could you elaborate on this point please?

rob:
>>> I'd really rather not. The analysis of the data from the volunteers running it is that it is (past) time to turn it down. If someone else is going to step up and run an equivalent service, they're welcome to. There's not really a discussion to have.

ether:
>> No, I'm sorry, we *do* need to have this conversation, so we can identify what resources and/or volunteers we need to find should we want to keep the service running.
>>If *you* don't want to be involved in running the service, that's fine, but you cannot prevent anyone else from doing so, or even knowing what would be involved so they can decide if they want to.
>>Thousands of widely-used perl modules still use rt.cpan.org as their issue tracker, and turning off this service in less than three months will have a huge impact on the ecosystem and also the optics of Perl's viability, so I want to get a good understanding of what the issues are and what the tradeoffs would be of the various paths forward.
>>Could you please share your analysis?

rob:
> *never responded*

--
With regards,
Christian Walde

On Sun, 24 Jan 2021 12:41:36 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

> Again, there is. These authors can provide information on how to report
> bugs and they can respond to emails.
>
> Put differently, if an author doesn't provide any information on how to
> report bugs and refuses to respond to emails (or even has an
> unresponsive email), then... do they really want to receive your tickets?

This logical conclusion drawn there does of course apply to all cpan authors who operate like ether or other top-100 authors. But it does not apply universally.

It is inherently very unsympathetic to all other types of authors and especially so in a global pandemic.

It is also unsympathetic to the use mode where bug reports are received and collected in a way that they are accessible publicly and continue to be of use in more than one way even without the author.

--
With regards,
Christian Walde

On Sun, 24 Jan 2021 12:36:05 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

>> Personally I find it very worrying that it seems like a single
>> volunteer can decide "I've given up, I'm turning this off", and nobody
>> worries about that situation. Of course people can decide to step down
>> and move on to other things, but they shouldn't be able to destroy a
>> major part of the CPAN ecosystem while they do so.
>
> These people received no money, barely any recognition, zero support,
> had to deal with a ton of crap because they care. Now that they can't
> continue doing it, it turned into "you shouldn't be allowed to do that."

You wrote a lot here, but most of it doesn't need response, as it is based in this assumption you made, which must be addressed first.

Nobody, not a single person, ever, was saying "Robert you must continue doing this".

Everybody was saying, very specifically and very clearly: "Ok, wow this is new, so what is actually going on here, help us understand and avoid the result without tying you to it."

I already gave an example in response to another email, but many other questions like this were unanswered:

> there's also a matter of definitions
> what exactly are the volunteers volunteering?
> the last few times i was in a position where i was the official volunteer for a thing there was another person who owned the thing i was volunteering my time to and whose agreement i had to get to do something like "shut it down"

And in light of this, i don't think it's in the slightest bit fair to anybody to try and claim that this was an attempt from anyone to forbid Robert from stepping away.

And particularly as for the money/recognition thing: Nothing on the service indicates what exactly its hosting situation is, so anybody concerned was hoping it was a TPF-handled thing. (Regardless of whether it would've stated out like this or became it later.) It's not possible to have thoughts about something if the facts about that thing are in no single way public.

--
With regards,
Christian Walde

On 1/24/21 3:04 PM, Christian Walde wrote:
> On Sun, 24 Jan 2021 12:36:05 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>
>>> Personally I find it very worrying that it seems like a single
>>> volunteer can decide "I've given up, I'm turning this off", and nobody
>>> worries about that situation. Of course people can decide to step down
>>> and move on to other things, but they shouldn't be able to destroy a
>>> major part of the CPAN ecosystem while they do so.
>>
>> These people received no money, barely any recognition, zero support,
>> had to deal with a ton of crap because they care. Now that they can't
>> continue doing it, it turned into "you shouldn't be allowed to do that."
>
> You wrote a lot here, but most of it doesn't need response, as it is
> based in this assumption you made, which must be addressed first.
>
> Nobody, not a single person, ever, was saying "Robert you must
> continue doing this".
>
> Everybody was saying, very specifically and very clearly: "Ok, wow
> this is new, so what is actually going on here, help us understand and
> avoid the result without tying you to it."


I respectfully disagree. I found the tone of words to reflect criticism
of people making a decision based on personal needs.


I definitely understand the "Okay, wow, this is new. What's going on,
what can we do, what damage will occur and how could we minimize it?"
That's absolutely reasonable and I have zero objections or problems with
it.? The email to which I responded included both a concern for future
and a critic of individuals, so I objected to that latter notion and I
maintain that objection.



>
> I already gave an example in response to another email, but many other
> questions like this were unanswered:
>
>> there's also a matter of definitions
>> what exactly are the volunteers volunteering?
>> the last few times i was in a position where i was the official
>> volunteer for a thing there was another person who owned the thing i
>> was volunteering my time to and whose agreement i had to get to do
>> something like "shut it down"
>
> And in light of this, i don't think it's in the slightest bit fair to
> anybody to try and claim that this was an attempt from anyone to
> forbid Robert from stepping away.


I read the sentence "[...] but they shouldn't be able to destroy a major
part of the CPAN ecosystem while they do so." as "they shouldn't be
allowed to make a decision to step off and go ahead and do that." (Also,
the comparison to PAUSE was wrong, but I won't focus on that part of the
sentence.)


NOC did not say "We will burn this to ashes and no one gets a voice."
The announcement included working on a plan and this thread included a
message from someone receiving direct access to RT, so clearly it's not
deleting the hard drive and walking away from a grand explosion.


As much as we're concerned about the state of matters, other people
might have *other* concerns which are not *us* or what *we* worry about.
NOC are not under any legal obligation toward any of us. I think it will
serve us better to approach this from an "understanding" perspective
rather than accusatory.


>
> And particularly as for the money/recognition thing: Nothing on the
> service indicates what exactly its hosting situation is, so anybody
> concerned was hoping it was a TPF-handled thing. (Regardless of
> whether it would've stated out like this or became it later.) It's not
> possible to have thoughts about something if the facts about that
> thing are in no single way public.


Not knowing whether it's paid or not is fair. But responding under the
assumption it's a paid service and someone owes us is probably not the
best foot to start conversations on. I'm not saying "You should know
it's unpaid," I'm saying "Don't act like it is."

On 1/24/21 2:44 PM, Christian Walde wrote:
> On Sun, 24 Jan 2021 12:42:54 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>
>>
>> On 1/20/21 11:34 PM, Eric Herman wrote:
>>> On 1/20/21 4:25 AM, Joel Roth wrote:
>>>>> On 1/19/21 11:44 PM, Paul "LeoNerd" Evans wrote:
>>>>
>>>>>> To emphasise again: in 41 days time the bug tracker used by
>>>>>> nearly 80%
>>>>>> of all of CPAN is going to be shut down and become unavailable for
>>>>>> either historic or newly-reported bugs. We *need* to find a
>>>>>> solution in
>>>>>> that time.
>>>>
>>>> On Wed, Jan 20, 2021 at 12:27:47AM +0100, Sawyer X wrote:
>>>>> This is infrastructure maintained by NOC volunteers. What would you
>>>>> suggest
>>>>> Perl 5 Porters do?
>>>>
>>>> Can we estimate what the cost would be to *hire* someone
>>>> to administer the existing system?
>>>>
>>>> Perhaps donations could support this resource until we have
>>>> a smooth path forward? I, for one, would contribute.
>>>>
>>>> Can the Perl Foundation receive funds for this purpose?
>>>> I think many in the community would pony up to help.
>>>
>>>
>>> Indeed. If there is a straight-forward solution which involves putting
>>> in a reasonably amount of money, it's not a problem, it's an expense.
>>> I, too, will donate.
>>
>>
>> This assumes on a major benefit to this expenditure. I personally doubt
>> the benefit outweighs the cost.
>
> Requests for data on this have been made multiple times by various
> people and outright rejected.


I don't think what you posted addresses the point I made and I don't
want to comment when not knowing all the facts.

On Sun, 24 Jan 2021 16:25:36 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

> NOC did not say "We will burn this to ashes and no one gets a voice."

The first and second messages about this matter very clearly, explicitly, unmistakably and in every single possible way undeniably said that the inbound pathways of RT would be shut off and allowed for no discussion at the time, not just by tone, but by the very words.

> I definitely understand the "Okay, wow, this is new. What's going on,
> what can we do, what damage will occur and how could we minimize it?"
> That's absolutely reasonable and I have zero objections or problems with
> it. The email to which I responded included both a concern for future
> and a critic of individuals, so I objected to that latter notion and I
> maintain that objection.

I see. Any chance you could answer the questions and explain the situation so we have documentation?

The public is still in "educated guessing" mode.

--
With regards,
Christian Walde

On Sun, 24 Jan 2021 16:33:25 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

>
> On 1/24/21 2:44 PM, Christian Walde wrote:
>> On Sun, 24 Jan 2021 12:42:54 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>>
>>>
>>> On 1/20/21 11:34 PM, Eric Herman wrote:
>>>> On 1/20/21 4:25 AM, Joel Roth wrote:
>>>>>> On 1/19/21 11:44 PM, Paul "LeoNerd" Evans wrote:
>>>>>
>>>>>>> To emphasise again: in 41 days time the bug tracker used by
>>>>>>> nearly 80%
>>>>>>> of all of CPAN is going to be shut down and become unavailable for
>>>>>>> either historic or newly-reported bugs. We *need* to find a
>>>>>>> solution in
>>>>>>> that time.
>>>>>
>>>>> On Wed, Jan 20, 2021 at 12:27:47AM +0100, Sawyer X wrote:
>>>>>> This is infrastructure maintained by NOC volunteers. What would you
>>>>>> suggest
>>>>>> Perl 5 Porters do?
>>>>>
>>>>> Can we estimate what the cost would be to *hire* someone
>>>>> to administer the existing system?
>>>>>
>>>>> Perhaps donations could support this resource until we have
>>>>> a smooth path forward? I, for one, would contribute.
>>>>>
>>>>> Can the Perl Foundation receive funds for this purpose?
>>>>> I think many in the community would pony up to help.
>>>>
>>>>
>>>> Indeed. If there is a straight-forward solution which involves putting
>>>> in a reasonably amount of money, it's not a problem, it's an expense.
>>>> I, too, will donate.
>>>
>>>
>>> This assumes on a major benefit to this expenditure. I personally doubt
>>> the benefit outweighs the cost.
>>
>> Requests for data on this have been made multiple times by various
>> people and outright rejected.
>
>
> I don't think what you posted addresses the point I made and I don't
> want to comment when not knowing all the facts.

Given that we have a solution in progress i am trying to focus on bringing the most salient facts about the situation "into record" and asking questions that matter for the future.

If you feel i skipped over something i should address, please let me know.

That said: I feel "we'd like to have actual data to be able to weigh benefit and cost" is fairly relevant here.

--
With regards,
Christian Walde

On 1/24/21 4:35 PM, Christian Walde wrote:
> On Sun, 24 Jan 2021 16:25:36 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>
>> NOC did not say "We will burn this to ashes and no one gets a voice."
>
> The first and second messages about this matter very clearly,
> explicitly, unmistakably and in every single possible way undeniably
> said that the inbound pathways of RT would be shut off and allowed for
> no discussion at the time, not just by tone, but by the very words.


The emails I'm responding to refer to a post that mentions data will be
made available, so whatever the first or second messages were, they are
not relevant to the emails I responded to or to my responses to those
emails.


>
>> I definitely understand the "Okay, wow, this is new. What's going on,
>> what can we do, what damage will occur and how could we minimize it?"
>> That's absolutely reasonable and I have zero objections or problems with
>> it.? The email to which I responded included both a concern for future
>> and a critic of individuals, so I objected to that latter notion and I
>> maintain that objection.
>
> I see. Any chance you could answer the questions and explain the
> situation so we have documentation?


I am not part of NOC and am not part of any work on RT or any plan of
decommissioning rt.cpan, so I cannot field any questions on the matter.



>
> The public is still in "educated guessing" mode.


I don't think this is a good place to be in. We raised this topic in PSC
and intend to dive further into it in the next meeting. (The last
meeting - of which the notes are forthcoming - had other topics, but
this was raised as "we should discuss it at length next meeting.")

On Sun, 24 Jan 2021 16:48:05 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

>
> On 1/24/21 4:35 PM, Christian Walde wrote:
>> On Sun, 24 Jan 2021 16:25:36 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>>
>>> NOC did not say "We will burn this to ashes and no one gets a voice."
>>
>> The first and second messages about this matter very clearly,
>> explicitly, unmistakably and in every single possible way undeniably
>> said that the inbound pathways of RT would be shut off and allowed for
>> no discussion at the time, not just by tone, but by the very words.
>
> The emails I'm responding to refer to a post that mentions data will be
> made available, so whatever the first or second messages were, they are
> not relevant to the emails I responded to or to my responses to those
> emails.

LeoNerd's email was directly concerned with the inbound pathways of RT that were going to be shut down. See excerpt below:

On Tue, 19 Jan 2021 23:44:25 +0100, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules
> [1], is going to be shut down on 1st March this year [2]; 41 days
> from when I write this email.
>
> ****
>
> [...] the *huge amount* of CPAN modules this is about to affect.
>
> [...] a huge outage of a major component of the CPAN ecosystem.
>
> I personally have 189 modules in need of migration - somehow. [...] a new for users to report new bugs needs to exist. Of special note are the numerous "in progress" tickets I have across my distributions, containing ongoing discussions about design issues and the like

Also, fyi, the linked blog post was edited at least once (maybe more, memory ugh), replacing the body of it. Neither iteration contained any consideration of offering anyone to take over and allow the inbound pathways to stay up. Nor was there any such thing in the books in the IWG conversation.

As far as i can tell it was only sheer luck that someone stepped up who seemed amenable enough to have their offer taken.

>> The public is still in "educated guessing" mode.
>
> I don't think this is a good place to be in. We raised this topic in PSC
> and intend to dive further into it in the next meeting. (The last
> meeting - of which the notes are forthcoming - had other topics, but
> this was raised as "we should discuss it at length next meeting.")

Thanks. Hopefully this leads to more consistent documentation of currently non-public information.

--
With regards,
Christian Walde

On Sun, 24 Jan 2021 16:35:10 +0100
"Christian Walde" <walde.christian@gmail.com> wrote:

> On Sun, 24 Jan 2021 16:25:36 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>
> > NOC did not say "We will burn this to ashes and no one gets a voice."
>
> The first and second messages about this matter very clearly, explicitly, unmistakably and in every single possible way undeniably said that the inbound pathways of RT would be shut off and allowed for no discussion at the time, not just by tone, but by the very words.

Exactly. Everything that has been officially said about the shutdown
boils down to "we're killing it and there's nothing you can do about it".
This isn't a bad faith interpretation, this is literally how I understood
it.

On Sun, 24 Jan 2021 17:33:57 +0100, Tomasz Konojacki <me@xenu.pl> wrote:

> On Sun, 24 Jan 2021 16:35:10 +0100
> "Christian Walde" <walde.christian@gmail.com> wrote:
>
>> On Sun, 24 Jan 2021 16:25:36 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> > NOC did not say "We will burn this to ashes and no one gets a voice."
>>
>> The first and second messages about this matter very clearly, explicitly, unmistakably and in every single possible way undeniably said that the inbound pathways of RT would be shut off and allowed for no discussion at the time, not just by tone, but by the very words.
>
> Exactly. Everything that has been officially said about the shutdown
> boils down to "we're killing it and there's nothing you can do about it".
> This isn't a bad faith interpretation, this is literally how I understood
> it.

Thanks for your voice, and yeah, i don't know how anyone can read this:

On Mon, Dec 14, 2020 at 1:59 PM Robert Spier <rspier@pobox.com> wrote:

> [...] it is (past) time to turn it down. If someone else is going to step up and run an equivalent service, they're welcome to. There's not really a discussion to have.

And interpret it as "being open to keeping RT running".

--
With regards,
Christian Walde

On Sun, Jan 24, 2021 at 9:05 AM Christian Walde <walde.christian@gmail.com>
wrote:

> On Sun, 24 Jan 2021 12:36:05 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>
> >> Personally I find it very worrying that it seems like a single
> >> volunteer can decide "I've given up, I'm turning this off", and nobody
> >> worries about that situation. Of course people can decide to step down
> >> and move on to other things, but they shouldn't be able to destroy a
> >> major part of the CPAN ecosystem while they do so.
> >
> > These people received no money, barely any recognition, zero support,
> > had to deal with a ton of crap because they care. Now that they can't
> > continue doing it, it turned into "you shouldn't be allowed to do that."
>
> You wrote a lot here, but most of it doesn't need response, as it is based
> in this assumption you made, which must be addressed first.
>
> Nobody, not a single person, ever, was saying "Robert you must continue
> doing this".
>
> Everybody was saying, very specifically and very clearly: "Ok, wow this is
> new, so what is actually going on here, help us understand and avoid the
> result without tying you to it."
>
> I already gave an example in response to another email, but many other
> questions like this were unanswered:
>
> > there's also a matter of definitions
> > what exactly are the volunteers volunteering?
> > the last few times i was in a position where i was the official
> volunteer for a thing there was another person who owned the thing i was
> volunteering my time to and whose agreement i had to get to do something
> like "shut it down"
>
> And in light of this, i don't think it's in the slightest bit fair to
> anybody to try and claim that this was an attempt from anyone to forbid
> Robert from stepping away.
>
> And particularly as for the money/recognition thing: Nothing on the
> service indicates what exactly its hosting situation is, so anybody
> concerned was hoping it was a TPF-handled thing. (Regardless of whether it
> would've stated out like this or became it later.) It's not possible to
> have thoughts about something if the facts about that thing are in no
> single way public.
>

I would like to second this post in that this is how I also interpreted the
situation, and I also am not interested in forcing Robert to do anything
except allow for other volunteers to continue to maintain this integral
ecosystem service until such time as a better replacement can be formed
(which cannot in my estimation happen in less than a year, even once
someone has an idea for it, of which I have not heard any yet). This leaves
to me only two reasonable options: 1. RT is maintained as it currently is
until there is an actual viable replacement already in place, 2. RT is
maintained somewhere else until there is an actual viable replacement
already in place. The latter seems to be much more to Robert's liking so I
am hopeful this path will be successful.

-Dan

Hi. Thank you so much for your incredible dedication to Perl!

On Sun, Jan 24, 2021 at 5:36 AM Sawyer X <xsawyerx@gmail.com> wrote:

> 2. Sure, if the overhead is low. It isn't. It's money not well spent.
> There are numerous ticket system to use, many for free.

Can you explain this more please?

What money exactly is being spent to maintain/host RT?
Where does it come from?
Have we already looked at free or community supported hosting options
in the past?

I'm asking because I understood form covo upthread that hosting (and
thus related costs?) were not perceived to be the principle issue but
seems to feature heavily in your comments.

>
> 3. See #2.
>
> 4. I think this is a very small "nice-to-have" for a *really* big cost.

Do respect, I strongly disagree. At least without understanding the
"costs" in practical terms (money diverted, SME time diverted that
would otherwise more directly contribute, etc), I would tend to assume
receiving (and retaining!) feedback from users regarding all aspects
of the "perl ecosystem" would be among the most core goals outside of
direct material contributions to Perl or the CPAN.

Regards,
Corwin

On 1/24/21 7:56 PM, Corwin Brust wrote:
> Hi. Thank you so much for your incredible dedication to Perl!
>
> On Sun, Jan 24, 2021 at 5:36 AM Sawyer X <xsawyerx@gmail.com> wrote:
>
>> 2. Sure, if the overhead is low. It isn't. It's money not well spent.
>> There are numerous ticket system to use, many for free.
> Can you explain this more please?
>
> What money exactly is being spent to maintain/host RT?
> Where does it come from?


It is being hosted privately by the Perl NOC.


> Have we already looked at free or community supported hosting options
> in the past?
>
> I'm asking because I understood form covo upthread that hosting (and
> thus related costs?) were not perceived to be the principle issue but
> seems to feature heavily in your comments.


I didn't mean that hosting is the expense. The maintenance is the
biggest expense. Enough that NOC decided they're done with it.


>
>> 3. See #2.
>>
>> 4. I think this is a very small "nice-to-have" for a *really* big cost.
> Do respect, I strongly disagree. At least without understanding the
> "costs" in practical terms (money diverted, SME time diverted that
> would otherwise more directly contribute, etc), I would tend to assume
> receiving (and retaining!) feedback from users regarding all aspects
> of the "perl ecosystem" would be among the most core goals outside of
> direct material contributions to Perl or the CPAN.


But this isn't the case. We have statistics that do not show us the full
picture. We just extrapolate liberally.


From the stats, you do not know:

* How many people actually use RT

* How many people who use RT *prefer* to keep using RT versus switching
to something more standardized across other languages and projects

* How many authors have their email working, and receive updates from
RT, aware of it, and check it

* How many users find RT useful when the author is not available to find
a patch or explanation of a bug

* How many users not submitting tickets because they don't know/like RT


and more.


The point I'm making here is that we can theorize about the value to an
inordinate amount, but we don't truly know it. I'm not saying we
shouldn't care about it. I'm saying that the maintenance cost should be
offset by value that we actually do know we will have from it, or to be
extrapolate from enough information.

On Thu, 21 Jan 2021 23:24:58 +0100, Bryan Horstmann-Allen <bryan@pobox.com> wrote:

>> On 2021-01-20 01:41:25, Christian Walde wrote:
>>
>> I remember you being in talks about the below topic. Is there any chance you
>> can tell is what the situation on your end is?
>
> Robert kindly gave me access to the VM running RT currently, and I started
> poking a few weeks ago, but work is currently consuming about 12 hours of every
> day, and my kids whatever's left. :-)
>
> My goal is to get it migrated into some portable state this weekend, and then
> talk about where a more permanent home might be once I have it running. I'm
> happy to update this thread with progress in a few days.
>
> Cheers.

https://metacpan.org/author/GETTY has also offered to help take it over. We live in the same house so if you can make use of additional help, feel free to contact me, or him directly at torsten@raudss.us

--
With regards,
Christian Walde

On Sun, 24 Jan 2021 16:48:05 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

> I am not part of NOC and am not part of any work on RT or any plan of decommissioning rt.cpan, so I cannot field any questions on the matter.

On Sun, 24 Jan 2021 21:32:20 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

> It is being hosted privately by the Perl NOC.
>
> [...] We have statistics that do not show us the full picture [...]

...




> we can theorize about the value to an inordinate amount, but we don't truly know it

I'm not sure if this is what you're doing, but it somewhat sounds like it: A big mistake would be to assume there is a singular value to be assigned to the thing. Value is subjective.

And as such, particularly in a case such as this, the procedure should always be to ask first "does anyone find this valuable enough to donate their resources?"

And in fact, the very first response to the first public announcement of this contained the question of being able to compare the costs so they can be weighed against the values by potential volunteers to take RT over. This question was never answered and deleted.



And we have multiple volunteers willing to do so, sight unseen, and i hope that if they run into troubles, to have whichever support, however small, you may be able to lend them, yes?


--
With regards,
Christian Walde

Thank you for the reply Sawyer!

On Sun, Jan 24, 2021 at 2:32 PM Sawyer X <xsawyerx@gmail.com> wrote:
>
>
> On 1/24/21 7:56 PM, Corwin Brust wrote:
> > Hi. Thank you so much for your incredible dedication to Perl!
> >
> > On Sun, Jan 24, 2021 at 5:36 AM Sawyer X <xsawyerx@gmail.com> wrote:
> >
> >> 2. Sure, if the overhead is low. It isn't. It's money not well spent.
> >> There are numerous ticket system to use, many for free.
> > Can you explain this more please?
> >
> > What money exactly is being spent to maintain/host RT?
> > Where does it come from?
>
>
> It is being hosted privately by the Perl NOC.

There are other hosting options that have no financial implication. I
know, because I suggested one of them (granted I cannot guarantee
Fosshost would accept an application from Perl, but I suspect so).
But I'll assume we are talking about "people-power" at least as much
as "money", however well spent.

> > Have we already looked at free or community supported hosting options
> > in the past?
> >
> > I'm asking because I understood form covo upthread that hosting (and
> > thus related costs?) were not perceived to be the principle issue but
> > seems to feature heavily in your comments.
>
>
> I didn't mean that hosting is the expense. The maintenance is the
> biggest expense. Enough that NOC decided they're done with it.

My understanding is that several people have volunteered to get
involved with maintenance. Please consider this note as my echoing
that sentiment: I'll help too, if I have the chops. Speaking for
myself, I'm not doing anything *else* to support the fabulous universe
of Perl.

> >> 3. See #2.
> >>
> >> 4. I think this is a very small "nice-to-have" for a *really* big cost.
> > Do respect, I strongly disagree. At least without understanding the
> > "costs" in practical terms (money diverted, SME time diverted that
> > would otherwise more directly contribute, etc), I would tend to assume
> > receiving (and retaining!) feedback from users regarding all aspects
> > of the "perl ecosystem" would be among the most core goals outside of
> > direct material contributions to Perl or the CPAN.
>
>
> But this isn't the case. We have statistics that do not show us the full
> picture. We just extrapolate liberally.

I'm quite uninterested in how RT is used. I'm much more interested in
the information for which RT is the system of record, access for
end-users to that information, and the integration of that data to the
rest of the tool-chain (metacpan, especially).

> From the stats, you do not know:
>
> * How many people actually use RT
>
> * How many people who use RT *prefer* to keep using RT versus switching
> to something more standardized across other languages and projects
>
> * How many authors have their email working, and receive updates from
> RT, aware of it, and check it
>
> * How many users find RT useful when the author is not available to find
> a patch or explanation of a bug
>
> * How many users not submitting tickets because they don't know/like RT
>
>
> and more.

Due respect, I don't see the relevance of these points. I assume
package authors do what they feel best to solicit and act on user
feedback. I would expect p5p to focus first on access to the Perl
ecosystem for end-users. That means answering such questions such as:
Does this unmaintained module still work? Does it have any known
problems? Do such problems have viable work-arounds?

> The point I'm making here is that we can theorize about the value to an
> inordinate amount, but we don't truly know it. I'm not saying we
> shouldn't care about it. I'm saying that the maintenance cost should be
> offset by value that we actually do know we will have from it, or to be
> extrapolate from enough information.

I'm still sitting with my same questions; I'll attempt reframing
in-terms of my own view:

People
- have offered to do work on this, and some are quite likely like me:
this would be their only material contribution back into the
ecosystem.
- have offered means to avoid capital expenditure but there hasn't
been any indication this will help.
- have lots of data in RT

This last point seems to me to go to the heart of the "open source"
value proposition. Dumping this data, making it harder to accrue such
data, making it harder to harvest this data, and driving workflows
reliant on this data to platforms that require significant privacy
concessions: it all feels rather like selling the community short.

--
Corwin
corwin@bru.st

On 1/24/21 9:56 PM, Christian Walde wrote:
> On Sun, 24 Jan 2021 16:48:05 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>
>> I am not part of NOC and am not part of any work on RT or any plan of
>> decommissioning rt.cpan, so I cannot field any questions on the matter.
>
> On Sun, 24 Jan 2021 21:32:20 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
>
>> It is being hosted privately by the Perl NOC.
>>
>> [...] We have statistics that do not show us the full picture [...]
>
> ...
>
>
>
>
>> we can theorize about the value to an inordinate amount, but we don't
>> truly know it
>
> I'm not sure if this is what you're doing, but it somewhat sounds like
> it: A big mistake would be to assume there is a singular value to be
> assigned to the thing. Value is subjective.
>
> And as such, particularly in a case such as this, the procedure should
> always be to ask first "does anyone find this valuable enough to
> donate their resources?"
>
> And in fact, the very first response to the first public announcement
> of this contained the question of being able to compare the costs so
> they can be weighed against the values by potential volunteers to take
> RT over. This question was never answered and deleted.


As before, not knowing enough about this, I cannot speak of what
happened or what I think about it.


>
>
> And we have multiple volunteers willing to do so, sight unseen, and i
> hope that if they run into troubles, to have whichever support,
> however small, you may be able to lend them, yes?


I would be happy to see RT existing. If there are volunteers and
financial assistance by those willing to provide it, all power to it, by
all means.

Hi Corwin,


Let me just give an umbrella comment here that I think you're responding
to me as if I object to your offer. I do not. My comments were general,
and in specific at TPF funding for resources. My comments are not
directed at the hosting offered by you or maintenance support offered by
others.



On 1/24/21 10:40 PM, Corwin Brust wrote:
> Thank you for the reply Sawyer!
>
> On Sun, Jan 24, 2021 at 2:32 PM Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> On 1/24/21 7:56 PM, Corwin Brust wrote:
>>> Hi. Thank you so much for your incredible dedication to Perl!
>>>
>>> On Sun, Jan 24, 2021 at 5:36 AM Sawyer X <xsawyerx@gmail.com> wrote:
>>>
>>>> 2. Sure, if the overhead is low. It isn't. It's money not well spent.
>>>> There are numerous ticket system to use, many for free.
>>> Can you explain this more please?
>>>
>>> What money exactly is being spent to maintain/host RT?
>>> Where does it come from?
>>
>> It is being hosted privately by the Perl NOC.
> There are other hosting options that have no financial implication. I
> know, because I suggested one of them (granted I cannot guarantee
> Fosshost would accept an application from Perl, but I suspect so).
> But I'll assume we are talking about "people-power" at least as much
> as "money", however well spent.
>
>>> Have we already looked at free or community supported hosting options
>>> in the past?
>>>
>>> I'm asking because I understood form covo upthread that hosting (and
>>> thus related costs?) were not perceived to be the principle issue but
>>> seems to feature heavily in your comments.
>>
>> I didn't mean that hosting is the expense. The maintenance is the
>> biggest expense. Enough that NOC decided they're done with it.
> My understanding is that several people have volunteered to get
> involved with maintenance. Please consider this note as my echoing
> that sentiment: I'll help too, if I have the chops. Speaking for
> myself, I'm not doing anything *else* to support the fabulous universe
> of Perl.
>
>>>> 3. See #2.
>>>>
>>>> 4. I think this is a very small "nice-to-have" for a *really* big cost.
>>> Do respect, I strongly disagree. At least without understanding the
>>> "costs" in practical terms (money diverted, SME time diverted that
>>> would otherwise more directly contribute, etc), I would tend to assume
>>> receiving (and retaining!) feedback from users regarding all aspects
>>> of the "perl ecosystem" would be among the most core goals outside of
>>> direct material contributions to Perl or the CPAN.
>>
>> But this isn't the case. We have statistics that do not show us the full
>> picture. We just extrapolate liberally.
> I'm quite uninterested in how RT is used. I'm much more interested in
> the information for which RT is the system of record, access for
> end-users to that information, and the integration of that data to the
> rest of the tool-chain (metacpan, especially).
>
>> From the stats, you do not know:
>>
>> * How many people actually use RT
>>
>> * How many people who use RT *prefer* to keep using RT versus switching
>> to something more standardized across other languages and projects
>>
>> * How many authors have their email working, and receive updates from
>> RT, aware of it, and check it
>>
>> * How many users find RT useful when the author is not available to find
>> a patch or explanation of a bug
>>
>> * How many users not submitting tickets because they don't know/like RT
>>
>>
>> and more.
> Due respect, I don't see the relevance of these points. I assume
> package authors do what they feel best to solicit and act on user
> feedback. I would expect p5p to focus first on access to the Perl
> ecosystem for end-users. That means answering such questions such as:
> Does this unmaintained module still work? Does it have any known
> problems? Do such problems have viable work-arounds?


In this thread, a lot of statistics was shared expressing the value of
RT. I had wanted to address that when discussing about cost/benefit
analysis, directly responding to raising funds for this through TPF.
This will require cost/value analysis and that would require
understanding what the statistics provide or do not provide. This is the
"relevance" of the points I raised.


I don't understand the rest of your paragraph. If you are suggesting
that Perl 5 Porters should care about end-user access to RT, I don't
understand why this comment is directed at me. I had not disagreed with
it or expressed a contradictory position. In my initial email to Paul, I
asked what in particular he thought P5P can help with.


>
>> The point I'm making here is that we can theorize about the value to an
>> inordinate amount, but we don't truly know it. I'm not saying we
>> shouldn't care about it. I'm saying that the maintenance cost should be
>> offset by value that we actually do know we will have from it, or to be
>> extrapolate from enough information.
> I'm still sitting with my same questions; I'll attempt reframing
> in-terms of my own view:
>
> People
> - have offered to do work on this, and some are quite likely like me:
> this would be their only material contribution back into the
> ecosystem.
> - have offered means to avoid capital expenditure but there hasn't
> been any indication this will help.
> - have lots of data in RT
>
> This last point seems to me to go to the heart of the "open source"
> value proposition. Dumping this data, making it harder to accrue such
> data, making it harder to harvest this data, and driving workflows
> reliant on this data to platforms that require significant privacy
> concessions: it all feels rather like selling the community short.



I think this can be wrapped up with my umbrella comment at the top and
my response to Mithaldu. I'm happy if there are resources. I *never*
said that if there are resources (hosting + people willing to work on
it), it shouldn't be hosted, maintained, or supported.

>

The way I see it, the only critical short term need is that the existing
rt.cpan.org content continues to be readily available in a read-only archive.

Existing bug reports won't be lost, and anyone wanting to file new reports or
make responses can deal with that on a case-by-case basis which is where
replacements would come into play, and the default for that is "contact the author".

Where projects are actively maintained, the authors would quickly setup
alternate bug tracking mechanisms where they haven't already, and for
non-maintained projects, new reports wouldn't be responded to anyway, but the
read-only archive would ensure any past reports aren't lost.

-- Darren Duncan

On Sun, Jan 24, 2021 at 4:10 PM Darren Duncan <darren@darrenduncan.net>
wrote:

> Where projects are actively maintained, the authors would quickly setup
> alternate bug tracking mechanisms where they haven't already, and for
> non-maintained projects, new reports wouldn't be responded to anyway, but
> the
> read-only archive would ensure any past reports aren't lost.
>

This isn't true, as you are forgetting about the vast middle ground of
distributions whose original authors have drifted away but have handed off
permissions to other people who are standing by able to perform maintenance
work as needed. I am in such a position for literally hundreds of these
modules where I have not needed to do a release *yet*, and as such the last
releaser is the original author, but I can do a release quickly when
needed. For these distributions I rely on RT to receive the bug reports,
and the sudden loss of RT creates a massive burden where I need to release
*all* of them in a matter of a month in order to ensure that bug reports
are not lost.

The current situation has been *massively* stressful, on top of a year that
has not exactly been a picnic to begin with. To hear statements that the
statistics simply aren't compelling enough is to deny my lived experience,
and strikes me as incredibly lacking in empathy.

On Mon, 25 Jan 2021 00:40:32 +0100, Sawyer X <xsawyerx@gmail.com> wrote:

> As before, not knowing enough about this, I cannot speak of what
> happened or what I think about it.

In that case i would recommend, for any future such instances: Please ask why people are saying what they're saying and what they mean with it, and whether they can provide citations (which we can), before making claims like:

> it turned into "you shouldn't be allowed to do that."

or

> NOC did not say "We will burn this to ashes and no one gets a voice."

Maybe ask in private too if necessary. I would have preferred to not drag this out in public, but things merited correction as LeoNerd's post was entirely based on reality.


>> And we have multiple volunteers willing to do so, sight unseen, and i
>> hope that if they run into troubles, to have whichever support,
>> however small, you may be able to lend them, yes?
>
>
> I would be happy to see RT existing. If there are volunteers and
> financial assistance by those willing to provide it, all power to it, by
> all means.

Thank you. :)


--
With regards,
Christian Walde

On Mon, Jan 25, 2021 at 2:46 AM Karen Etheridge <perl@froods.org> wrote:
> This isn't true, as you are forgetting about the vast middle ground of distributions whose original authors have drifted away but have handed off permissions to other people who are standing by able to perform maintenance work as needed. I am in such a position for literally hundreds of these modules where I have not needed to do a release *yet*, and as such the last releaser is the original author, but I can do a release quickly when needed. For these distributions I rely on RT to receive the bug reports, and the sudden loss of RT creates a massive burden where I need to release *all* of them in a matter of a month in order to ensure that bug reports are not lost.

Quite frankly, "rt loses all data" may actually be less work for me
than "rt becomes read-only"

Leon

Please forgive this top-post, hastily composed over a short lunch :)

Is there evidence suggesting a read-only RT will take less effort to
maintain?

On Mon, Jan 25, 2021, 02:57 Leon Timmermans <fawaka@gmail.com> wrote:

> On Mon, Jan 25, 2021 at 2:46 AM Karen Etheridge <perl@froods.org> wrote:
> > This isn't true, as you are forgetting about the vast middle ground of
> distributions whose original authors have drifted away but have handed off
> permissions to other people who are standing by able to perform maintenance
> work as needed. I am in such a position for literally hundreds of these
> modules where I have not needed to do a release *yet*, and as such the last
> releaser is the original author, but I can do a release quickly when
> needed. For these distributions I rely on RT to receive the bug reports,
> and the sudden loss of RT creates a massive burden where I need to release
> *all* of them in a matter of a month in order to ensure that bug reports
> are not lost.
>
> Quite frankly, "rt loses all data" may actually be less work for me
> than "rt becomes read-only"
>
> Leon
>

On 2021-01-25 10:51 a.m., Corwin Brust wrote:
> Please forgive this top-post, hastily composed over a short lunch :)
>
> Is there evidence suggesting a read-only RT will take less effort to maintain?
>
> On Mon, Jan 25, 2021, 02:57 Leon Timmermans wrote:
> Quite frankly, "rt loses all data" may actually be less work for me
> than "rt becomes read-only"

Part of my proposal is that the RT software goes away entirely and that the
read-only archive is just a set of static HTML pages plus a static database
dump, both downloadable and the former is what continues to be hosted.

Even if read-only, I understand the primary issue with continuing to use the RT
software is its being possibly unmaintained complex software that presents a
sizeable attack surface and sizeable maintenance burden.

So if the archive is simply a static dump in multiple formats, HTML for easy
reading which a generic search engine can index, and SQL etc for easy importing
for more complex analysis, this presents a minimal almost set it and forget it
maintenance burden, put it on a plain vanilla server, and it is easy for any
interested person to download a copy which is more backups.

So the RT software can just go away, just keep the data.

This is assuming that everything of value is safe to make public. If anything
in the database should only be seen by authenticated users or is privileged or
is security sensitive, that would have to be scrubbed from this.

-- Darren Duncan

On Mon, Jan 25, 2021 at 2:29 PM Darren Duncan <darren@darrenduncan.net>
wrote:

> On 2021-01-25 10:51 a.m., Corwin Brust wrote:
> > Please forgive this top-post, hastily composed over a short lunch :)
> >
> > Is there evidence suggesting a read-only RT will take less effort to
> maintain?
> >
> > On Mon, Jan 25, 2021, 02:57 Leon Timmermans wrote:
> > Quite frankly, "rt loses all data" may actually be less work for me
> > than "rt becomes read-only"
>
> Part of my proposal is that the RT software goes away entirely and that
> the
> read-only archive is just a set of static HTML pages plus a static
> database
> dump, both downloadable and the former is what continues to be hosted.
>
> Even if read-only, I understand the primary issue with continuing to use
> the RT
> software is its being possibly unmaintained complex software that presents
> a
> sizeable attack surface and sizeable maintenance burden.
>
> So if the archive is simply a static dump in multiple formats, HTML for
> easy
> reading which a generic search engine can index, and SQL etc for easy
> importing
> for more complex analysis, this presents a minimal almost set it and
> forget it
> maintenance burden, put it on a plain vanilla server, and it is easy for
> any
> interested person to download a copy which is more backups.
>
> So the RT software can just go away, just keep the data.
>
> This is assuming that everything of value is safe to make public. If
> anything
> in the database should only be seen by authenticated users or is
> privileged or
> is security sensitive, that would have to be scrubbed from this.
>

I appreciate the motivation for the suggestions, but this discussion is
rather moot, because 1) a static archive was always the plan, 2) a second
static archive already exists (https://github.com/rt-cpan/rt-cpan.github.io),
3) this doesn't solve the immediate concerns of active RT users.

-Dan

On Mon, Jan 25, 2021 at 8:29 PM Darren Duncan <darren@darrenduncan.net> wrote:
> Part of my proposal is that the RT software goes away entirely and that the
> read-only archive is just a set of static HTML pages plus a static database
> dump, both downloadable and the former is what continues to be hosted.
>
> Even if read-only, I understand the primary issue with continuing to use the RT
> software is its being possibly unmaintained complex software that presents a
> sizeable attack surface and sizeable maintenance burden.
>
> So if the archive is simply a static dump in multiple formats, HTML for easy
> reading which a generic search engine can index, and SQL etc for easy importing
> for more complex analysis, this presents a minimal almost set it and forget it
> maintenance burden, put it on a plain vanilla server, and it is easy for any
> interested person to download a copy which is more backups.
>
> So the RT software can just go away, just keep the data.
>
> This is assuming that everything of value is safe to make public. If anything
> in the database should only be seen by authenticated users or is privileged or
> is security sensitive, that would have to be scrubbed from this.

I think I phrased my point terribly, but let me try again: having a
readonly archive has limited practical value beyond saving historical
information. Not breaking existing links is nice, but that's really
just about it. It is in no way a situation that is less work to deal
with than it dropping out of existence entirely, the only advantage of
it is that we don't lose existing data if we postpone dealing with the
calamity. It doesn't make dealing with it any less work.

Because the calamity is that 80% of CPAN is suddenly no longer having
a working bug tracker, leaving users and vendors with no designated
and reliable way to contact the (current and future) authors. That
will need to be resolved regardless.

Leon

On 2021-01-19 4:27 p.m., Christian Walde wrote:
> Only a miniscule part. The biggest issue is all the dists that won't get updated
> will suddenly have whatever well-meaning emails may come in drop into a black hole.

Emails should be returned to sender with an appropriate error message, such as
the default un-deliverable, rather than just being ignored, so those attempting
to send them know it didn't work. -- Darren

On Tue, 26 Jan 2021 08:06:30 +0100, Darren Duncan <darren@darrenduncan.net> wrote:

> On 2021-01-19 4:27 p.m., Christian Walde wrote:
>> Only a miniscule part. The biggest issue is all the dists that won't get updated
>> will suddenly have whatever well-meaning emails may come in drop into a black hole.
>
> Emails should be returned to sender with an appropriate error message, such as
> the default un-deliverable, rather than just being ignored, so those attempting
> to send them know it didn't work. -- Darren

That is a necessity for the absolute worst case, but how to implement that is up in the air.

And in any case, we should wait for an update from Bryan as well.

--
With regards,
Christian Walde

On 1/25/21 2:45 AM, Karen Etheridge wrote:
>
> On Sun, Jan 24, 2021 at 4:10 PM Darren Duncan <darren@darrenduncan.net
> <mailto:darren@darrenduncan.net>> wrote:
>
> Where projects are actively maintained, the authors would quickly
> setup
> alternate bug tracking mechanisms where they haven't already, and for
> non-maintained projects, new reports wouldn't be responded to
> anyway, but the
> read-only archive would ensure any past reports aren't lost.
>
>
> [...] To hear statements that the statistics simply aren't compelling
> enough is to deny my lived experience, and strikes me as incredibly
> lacking in empathy.


Considering I pushed back on the statistics, I imagine this might be a
response to me. Just in case it is, I want to affirm that I am not
doubting the toll it takes on you or other contributors. My initial
response to Paul was careful and left a lot of room for me to understand
better. This is also why I'm following every message on this thread and
raising it in PSC.


My comment on statistics referred directly to the cost/benefit analysis
of RT as a system for the purposes of funding its continued maintenance.
I did not intend to suggest that the burden on you or other maintenance
authors is minimal or non-existent.

I'm happy to move my source code; I hope the ticket-migrating tools aren't
too hard to use. This is way overdue.

Lincoln

On Tue, Jan 19, 2021 at 5:44 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> This isn't directly core's doing, nor problem, but I am attempting to
> raise awareness of the situation because it seems nobody is aware or
> talking about it.
>
> ****
>
> rt.cpan.org, the bugtracker used by nearly 80% of all CPAN modules
> [1], is going to be shut down on 1st March this year [2]; 41 days
> from when I write this email.
>
> ****
>
> I am rather concerned about this, as there doesn't appear to be any
> sort of co-ordinated bailout plan or migration of the *huge amount* of
> CPAN modules this is about to affect.
>
> I am furthermore concerned at the total lack of discussion or response
> that has so far been generated; aside from Karen Etheridge I haven't
> seen any noise of upset being generated at all. Nor am I aware of any
> sort of effort to handle what will become a huge outage of a major
> component of the CPAN ecosystem.
>
> I personally have 189 modules in need of migration - somehow. As yet
> I have no clue what I am going to do about it. Existing bugs need to be
> moved somewhere else (and I have no clue how I'm going to fix up URLs
> that currently point to those, in code comments, documentation, blog
> posts, ... anywhere else), and a new for users to report new bugs needs
> to exist. Of special note are the numerous "in progress" tickets I have
> across my distributions, containing ongoing discussions about design
> issues and the like. To say that I am "concerned" is an understatement;
> I am fairly close to panicing about this.
>
> I am quite sure I am but the smallest tip of the iceberg here. Every
> time I mention it on Freenode's #perl or irc.perl.org's #p5p there are
> always new folks who were totally unaware of this fact. This is going
> to hit lots of people in a very hard surprise.
>
> I am therefore interested to know if
>
> a) Perl5 Porters officially, and
>
> b) Individual CPAN authors who happen to subscribe to the
> perl5-porters mailing list
>
> have any sort of response to this; any kind of mass-migration plan or
> thoughts on continuing the service.
>
>
> To emphasise again: in 41 days time the bug tracker used by nearly 80%
> of all of CPAN is going to be shut down and become unavailable for
> either historic or newly-reported bugs. We *need* to find a solution in
> that time.
>
>
> 1: Add the "known to be RT" and "unknown" categories of
> https://cpan.rocks/; because metacpan.org defaults to RT in the
> latter case.
>
> 2: https://log.perl.org/2020/12/rtcpanorg-sunset.html
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>


--
*Lincoln Stein*
Head, Adaptive Oncology, OICR
Senior Principal Investigator, OICR
Professor, Department of Molecular Genetics, University of Toronto

Tel: 416-673-8514
Cell: 416-817-8240
lincoln.stein@gmail.com

*Executive Assistant*
Tiia Kihlanki
Tel: 647-259-4253
tiia.kihlanki@oicr.on.ca

*Ontario Institute for Cancer Research*
MaRS Centre, 661 University Avenue, Suite 510, Toronto, Ontario, Canada M5G
0A3
@OICR_news <https://twitter.com/oicr_news> | www.oicr.on.ca

*Collaborate. Translate. Change lives.*

This message and any attachments may contain confidential and/or privileged
information for the sole use of the intended recipient. Any review or
distribution by anyone other than the person for whom it was originally
intended is strictly prohibited. If you have received this message in
error, please contact the sender and delete all copies. Opinions,
conclusions or other information contained in this message may not be that
of the organization.

On Wed, 27 Jan 2021 14:20:27 -0500
Lincoln Stein <lincoln.stein@gmail.com> wrote:

> I'm happy to move my source code; I hope the ticket-migrating tools
> aren't too hard to use. This is way overdue.

Individuals authors have always[*] been able to elect to configure some
other bugtracker for each distribution. The main issue here is that 80%
have either not done so, or specifically elected to keep rt.cpan.org -
so those 80% of distributions are going to become unsupported.

If you wish to use something else for your own dists, you have had that
option for a long time now...

(*: Well, for many years at least.)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Wed, 27 Jan 2021 19:38:17 +0100, Sawyer X <xsawyerx@gmail.com> wrote:
> On 1/25/21 2:45 AM, Karen Etheridge wrote:
>> On Sun, Jan 24, 2021 at 4:10 PM Darren Duncan <darren@darrenduncan.net
>> <mailto:darren@darrenduncan.net>> wrote:
>>
>> Where projects are actively maintained, the authors would quickly
>> setup
>> alternate bug tracking mechanisms where they haven't already, and for
>> non-maintained projects, new reports wouldn't be responded to
>> anyway, but the
>> read-only archive would ensure any past reports aren't lost.
>>
>>
>> [...] To hear statements that the statistics simply aren't compelling
>> enough is to deny my lived experience, and strikes me as incredibly
>> lacking in empathy.
>
>
> Considering I pushed back on the statistics, I imagine this might be a
> response to me. Just in case it is, I want to affirm that I am not
> doubting the toll it takes on you or other contributors. My initial
> response to Paul was careful and left a lot of room for me to understand
> better. This is also why I'm following every message on this thread and
> raising it in PSC.
>
>
> My comment on statistics referred directly to the cost/benefit analysis
> of RT as a system for the purposes of funding its continued maintenance.
> I did not intend to suggest that the burden on you or other maintenance
> authors is minimal or non-existent.

Dude, with all respect and love, you said earlier:

> This assumes on a major benefit to this expenditure. I personally doubt the benefit outweighs the cost.

In this situation you could've said something like:

"""
oh hm, i'm was not aware of how big the cost of ether migrating all her stuff would be if the time she volunteers was measured at a competitive market rate, and particularly not if that is multiplied for all yet-to-be-migrated dists, and how that just dwarfs the basic cost of hosting a vm.

i was wrong, there is a major benefit.

sorry.
"""

I personally wasn't aware of the scope on her end either until she mentioned it.

In fact, you still can, and doing so would make everyone feel a little happier. Wouldn't that on its own be worth it? :)

--
With regards,
Christian Walde

On 2021-01-24 5:45 p.m., Karen Etheridge wrote:
> On Sun, Jan 24, 2021 at 4:10 PM Darren Duncan wrote:
> Where projects are actively maintained, the authors would quickly setup
> alternate bug tracking mechanisms where they haven't already, and for
> non-maintained projects, new reports wouldn't be responded to anyway, but the
> read-only archive would ensure any past reports aren't lost.
>
> This isn't true, as you are forgetting about the vast middle ground of
> distributions whose original authors have drifted away but have handed off
> permissions to other people who are standing by able to perform maintenance work
> as needed. I am in such a position for literally hundreds of these modules where
> I have not needed to do a release *yet*, and as such the last releaser is the
> original author, but I can do a release quickly when needed. For these
> distributions I rely on RT to receive the bug reports, and the sudden loss of RT
> creates a massive burden where I need to release *all* of them in a matter of a
> month in order to ensure that bug reports are not lost.

I feel that it should be possible in a reasonably short time to deal with this
problem in an automated way so that you and others don't have to do mass
re-releases.

For example, under the possibly false assumption that people typically go to
MetaCPAN when they want to read the documentation for a module, and that filing
bug reports is largely a manual process, ...

MetaCPAN could receive fairly soon a few updates to assist people who go there
in order to look up how to submit a bug report for a particular module.

There could be a new help page which is prominently linked to at the top of each
page in the site that says rt.cpan.org is no longer receiving bug reports and
indicates how one can go about filing bug reports now, various steps to look up
the information or appropriate course of action on a per-module basis.

The page for each module could have automatically generated text on it that
indicates who the current PAUSE-registered maintainers are and that they are who
to contact if you have a bug report to file, regardless of what the actual
module POD says, unless the POD indicates something other than rt.cpan.org.

So it should be possible with reasonably low effort to mitigate this problem
without you having to re-release any of the modules you maintain for just this
purpose.

-- Darren Duncan

Hi folks,

Sorry for the lack of email updates. ether started a channel on IRC, and a
number of people have been helping out. Specifically davel has been working on
uplifting the code and getting it containerized. Once that's done, it should be
relatively straightforward to simply run the thing.

That said, Jim Brandt noted https://github.com/tpf/rt.cpan.org/issues/1 there
may be some related issues as this codebase is over 7 years old.

So: I'd expect there to be some hiccups around actually operating it, and as
rjbs said in another thread, some conversations on having it hosted by
BestPractical are also happening.

We have a couple options and they are being actively pursued.

Cheers.
--
bdha

On Mon, 1 Feb 2021 10:05:55 -0500
Bryan Horstmann-Allen <bryan@pobox.com> wrote:

> We have a couple options and they are being actively pursued.

Excellent news - thanks for taking the ball on this one :)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Mon, 01 Feb 2021 16:05:55 +0100, Bryan Horstmann-Allen <bryan@pobox.com> wrote:

> Hi folks,
>
> Sorry for the lack of email updates. ether started a channel on IRC, and a
> number of people have been helping out. Specifically davel has been working on
> uplifting the code and getting it containerized. Once that's done, it should be
> relatively straightforward to simply run the thing.
>
> That said, Jim Brandt noted https://github.com/tpf/rt.cpan.org/issues/1 there
> may be some related issues as this codebase is over 7 years old.
>
> So: I'd expect there to be some hiccups around actually operating it, and as
> rjbs said in another thread, some conversations on having it hosted by
> BestPractical are also happening.
>
> We have a couple options and they are being actively pursued.
>
> Cheers.

Thanks so much for your efforts on this, and especially thanks for tracking the work in a public repo. :)

--
With regards,
Christian Walde