Mailing List Archive

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