Mailing List Archive

On Wed, 22 Mar 2023 18:21:16 +0000
Zefram via perl5-porters <perl5-porters@perl.org> wrote:

> I have another bug report to send. In what form should I supply it?
> I asked previously on the "Markdown in emailed bug reports" thread,
> but that hasn't had a reply yet. Since the format I used most
> recently turned out to be inconvenient for Paul to process, and
> annoying to at least one other person, I don't intend to repeat that.
> To reiterate my earlier comment, I'm willing to author in either
> plain text or Markdown, and the email headers are another variable.
>
> I'm not at this stage seeking a definitive decision on the correct
> format for emailed bug reports. That's clearly something that we're
> still developing. At this stage I just want to know what format to
> try next.

The current procedure is that people report bugs directly on github.
Aside from you, I'm not aware of anyone or any technical infrastructure
which doesn't use that.

I don't believe there currently exists any automated process to take bug
reports from some other source and turn them into github issues. If we
wish there to be one, I suspect whoever goes about creating it would be
best placed to answer questions on what format your bug reports should
arrive in.

--
Paul "LeoNerd" Evans

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

Paul "LeoNerd" Evans wrote:
>The current procedure is that people report bugs directly on github.

That doesn't answer my question. I'm aware that that's the preferred
procedure, but it's a procedure that's not open to me.

>I don't believe there currently exists any automated process to take bug
>reports from some other source and turn them into github issues. If we
>wish there to be one, I suspect whoever goes about creating it would be
>best placed to answer questions on what format your bug reports should
>arrive in.

That's a hypothetical situation that might arise in the future.
We probably don't want to hold up all my bug reports until that happens
(especially for things that can be fixed for 5.38), and I'm not willing
to save up bug reports for a future that might never arrive. I'm asking
about the actual present: I have a bug report today, what should I do
with it?

-zefram

On Wed, 22 Mar 2023 at 19:40, Zefram via perl5-porters
<perl5-porters@perl.org> wrote:
>
> Paul "LeoNerd" Evans wrote:
> >The current procedure is that people report bugs directly on github.
>
> That doesn't answer my question. I'm aware that that's the preferred
> procedure, but it's a procedure that's not open to me.
>
> >I don't believe there currently exists any automated process to take bug
> >reports from some other source and turn them into github issues. If we
> >wish there to be one, I suspect whoever goes about creating it would be
> >best placed to answer questions on what format your bug reports should
> >arrive in.
>
> That's a hypothetical situation that might arise in the future.
> We probably don't want to hold up all my bug reports until that happens
> (especially for things that can be fixed for 5.38), and I'm not willing
> to save up bug reports for a future that might never arrive. I'm asking
> about the actual present: I have a bug report today, what should I do
> with it?

Ideally you send it to us as a plain text email, with the markdown in
it such that when we copy the email text in gmail (for instance) and
paste it into the textbox on github it Just Works. Maybe you could
find someone who does have a github account and work out the details
required there. For instance if I go to

https://github.com/Perl/perl5/issues/new/choose

and then hit "Get Started" in the "Report a Perl 5 Bug" row of the
table it presents, I end up seeing the text following the
"--8<--8<--8<--" line. You could email us something like that. The
HTML comment are mean to be helper text for the person filling out the
report. The text is formatted in markdown.

--8<--8<--8<--
<!--
Note: you can also replace the whole content with a file generated by
the perlbug utility;
perlbug reports by email are no longer supported.
Be sure to enclose your perl configuration in a fenced code block to
preserve formatting:
https://help.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks
-->

<!--
If your bug is about a Perl core module rather than a core language
feature, please enter its name after.
-->
Module:

**Description**
<!-- A clear and concise description of what the bug is. -->

**Steps to Reproduce**
<!-- A one-liner or script to reproduce the issue. -->

**Expected behavior**
<!-- A clear and concise description of what you expected to happen. -->

**Perl configuration**
<!-- Please paste `perl -V` output just below. -->
```
# perl -V output goes here
```

demerphq wrote:
>Ideally you send it to us as a plain text email, with the markdown in
>it

OK, I'll try that next: a Markdown document sent as text/plain.

> Maybe you could
>find someone who does have a github account and work out the details
>required there.

Presumably the current perlbug template is appropriate for that.
I believe that, if the user-edited part is written in Markdown, that
would make the whole body of the perlbug output a Markdown document.
Whoever processes the upcoming bug report, please let me know how you
get on with it.

-zefram

I wrote:
>OK, I'll try that next: a Markdown document sent as text/plain.

There's been no complaint. Am I to take it that this went well?

If that was satisfactory, I have a refinement of it that I'd like to
try next time. (I don't have another bug already lined up to report,
but it's a good bet that I'll find another sometime in the next month.)
I'd like to put in MIME headers explicitly stating text/plain, but with a
comment in the header about the mislabelling. That's perfectly standards
conforming, and should be handled correctly as text/plain by all MUAs,
but it's very unusual to have a comment in that particular header,
so it's something to try out before considering the process finalised.
The motivation for the comment is that the header (or, as it happened,
the lack of header) was a place I looked for clue about the expected
format of emailed bug reports.

Once we're settled on a procedure, I'll provide a patch for perlbug.

-zefram

On Wed, Mar 22, 2023, at 14:39, Zefram via perl5-porters wrote:
> Paul "LeoNerd" Evans wrote:
> >The current procedure is that people report bugs directly on github.
>
> That doesn't answer my question. I'm aware that that's the preferred
> procedure, but it's a procedure that's not open to me.

On that topic, I tried to remember what your objections to using GitHub were, and went diving. I found this old thread from 2011 <http://markmail.org/message/pjfcgn6nrwxluhpr>. Which included the following:

> Preamble: "GitHub reserves the right to update and change the Terms of
> Service from time to time without notice.". You're allegedly bound by
> whatever terms they decided to add this week. For example, they might
> change the terms in section F to claim copyright on whatever you upload.
> You have no opportunity to reject future changes of terms as unacceptable.
> This is an absolute dealbreaker for me.

This is no longer quite the case. Section Q <https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#q-changes-to-these-terms> reads: "We will notify our Users of material changes to this Agreement, such as price increases, at least 30 days prior to the change taking effect by posting a notice on our Website or sending email to the primary email address specified in your GitHub account. Customer's continued use of the Service after those 30 days constitutes agreement to those revisions of this Agreement."

> D4 and G6: GitHub can delete your account at will, without notice, and
> without giving you access to the data that was in your account. So it's
> not fit to be the only persistent repo for any project. Fortunately git
> makes replicating the data very easy, so you're not so likely to end
> up relying on GitHub. Which is good, because, per this term, GitHub
> is unreliable.

This no longer appears exactly as such, but I don't know that this should preclude you from using GitHub to submit patches to others' repositories. (Note, for what it's worth, "[if you cancel], We will not delete Content that you have contributed to other Users' repositories or that other Users have forked".)

> F3: you're liable for GitHub's legal costs where it's alleged that you've
> done something wrong. Not where you *have* done something wrong, but
> merely where it's *alleged*. You therefore have no practical control
> over whether such costs are incurred.

I no longer believe this language or claim exists. Section P <https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#p-release-and-indemnification> says that GitHub won't take a legal bullet for you, but not that you pay their legal fees.

In the years since the passing of the GDPR, I believe we've seen a very broad set of improvements on the language and claims of documents like these, and it looks to me like GitHub in particular has improved.

I am curious as to whether you find the current GitHub terms of service unacceptable for use as a contributor of patches or bug reports. (That is: I can also imagine that you have not reviewed them lately, after their many previous years of unchanging crappiness.)

--
rjbs

Ricardo Signes wrote:
>I am curious as to whether you find the current GitHub terms of
>service unacceptable for use as a contributor of patches or bug reports.

I looked fairly recently, and they still are unacceptable to me for
any purpose. The advance notice they'll give of some changes to terms
isn't nearly enough. They're still clear that one is in general bound to
changes without notice. I don't know what kind of changes would count
as "material", but it's obviously not every change that would have some
legal effect.

The form of notice is also (still) poor: "notice on our Website" isn't
even giving a defined location that one could automatically check.
To make use of that 30 days notice one would largely be dependent on
there being someone in the community who notices and makes a public fuss
about anything troublesome. I'm not confident that such a fuss would
arise about any proposed change to which I would object.

I find the current indemnity clause difficult to interpret. I'm not
clear on how much exposure one would face from it. It might be better
than the one I reviewed in 2011, but it also might not. If this were
the only issue preventing me joining GitHub then I might commission a
lawyer's opinion on it, but as things stand that's moot.

-zefram

On Fri, Mar 24, 2023, at 14:42, Zefram via perl5-porters wrote:
> Ricardo Signes wrote:
> >I am curious as to whether you find the current GitHub terms of
> >service unacceptable for use as a contributor of patches or bug reports.
>
> I looked fairly recently, and they still are unacceptable to me for
> any purpose. The advance notice they'll give of some changes to terms
> isn't nearly enough. They're still clear that one is in general bound to
> changes without notice. I don't know what kind of changes would count
> as "material", but it's obviously not every change that would have some
> legal effect.

I would argue that your reading is not only *not* obvious, but that the meaning of the language is *exactly* that:

*In the context of contract law, material refers to an event that significantly impacts the parties’ expectations under the contract. For example, the term “material adverse effect” is used to describe events which alter the parties’ expectations so significantly that the event extinguishes the parties’ obligations under the contract. As another example, a material breach of contract refers to a court finding that a party failed to satisfy their obligations significantly enough to where the aggrieved party is entitled to a remedy. *

(Source: Cornell Law's Legal Information Institute entry on "material" <https://www.law.cornell.edu/wex/material>)

At any rate, you must do you what you feel is right, of course.
> In the context of contract law, material refers to an event that significantly impacts the parties’ expectations under the contract. For example, the term “material adverse effect” is used to describe events which alter the parties’ expectations so significantly that the event extinguishes the parties’ obligations under the contract. As another example, a material breach of contract refers to a court finding that a party failed to satisfy their obligations significantly enough to where the aggrieved party is entitled to a remedy.


--
rjbs

Ricardo Signes wrote:
>> changes without notice. I don't know what kind of changes would count
>> as "material", but it's obviously not every change that would have some
>> legal effect.
>
>I would argue that your reading is not only *not* obvious, but that the meaning of the language is *exactly* that:

The thing you quote doesn't support interpreting "material" as meaning
any change that has legal effect. There's some "significance" criterion,
apparently with quite a high threshold. Furthermore, the terms have
some detail about "agreement to" changes that don't qualify as material.
If non-material changes were only ones with no legal effect then there
would be nothing needing such purported agreement.

I also wonder why these non-material changes are so urgent as to need
to take effect immediately. Where does the urgency come from to make
a non-change?

This would all be very easy for GitHub to resolve, if they wanted.
They could have a system of explicit agreement to each version of the
terms, with technological enforcement by refusing service to anyone who
hasn't agreed to a sufficiently recent version of the terms. This would
avoid all questions about notice periods, materiality, and form of notice,
even for changes that they want to apply immediately, and would give them
a much better legal claim that users have actually agreed to new terms.
The fact that they don't do anything in this direction tells me that
having users act according to the ToS, or even be aware of them, isn't
their priority.

-zefram