<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 18, 2020 at 1:54 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/17/20 10:55 AM, enh wrote:<br>
> On Sun, Aug 16, 2020 at 8:14 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br>
>><br>
>> On 8/16/20 2:31 PM, enh via Toybox wrote:<br>
>>> <a href="https://github.com/apps/repo-lockdown" rel="noreferrer" target="_blank">https://github.com/apps/repo-lockdown</a><br>
>>><br>
>>> Turns out there is a way to automate telling folks with pull requests to try the<br>
>>> mailing list instead. See link.<br>
>>><br>
>>> (This came up on the tzdata mailing list. I have no personal experience.)<br>
>><br>
>> Eh, its not a huge deal. The list is my personal preference, but wget pull<br>
>> request plus ".patch" on the end feeds straight into "git am".<br>
> <br>
> yeah, i've certainly seen you apply patches sent as pull requests. i<br>
> think the bigger problem is that checking pull requests isn't part of<br>
> your workflow in the same way that checking the list is. i'd almost<br>
> responded on <a href="https://github.com/landley/toybox/pull/234" rel="noreferrer" target="_blank">https://github.com/landley/toybox/pull/234</a> that the<br>
> submitter should try sending their patch to the mailing list instead,<br>
> for example.<br>
<br>
I get email, there's "patch links" near the bottom of the email, and the one<br>
ending in .patch is a "git am" format patch I can review and apply like any other.<br>
<br>
>> There's a generational divide between old people who grew up on mailing lists<br>
>> and younguns who grew up on web forums. People young enough that "here's a list<br>
>> of 37 websites that went away, you can't archive this and will lose your<br>
>> history" gets responded to with "I was 4 when that happened, who cares what<br>
>> happens in 10 years that's forever, we'll burn that bridge when we come to it,<br>
>> and just because it's happened like clockwork for decades doesn't mean it'll<br>
>> happen AGAIN"...<br>
>><br>
>> As I said, "wide net". The real history is the git commit log I suppose...<br>
> <br>
> i think the question is which is a worse experience for those younger<br>
> than we mailing list types --- having a pull request automatically<br>
> closed with a "try the mailing list instead" or having a pull request<br>
> accidentally missed because the person who needs to see it mainly<br>
> concentrates on the mailing list?<br>
<br>
I usually don't miss the pull request, because email. (Unless I'm not online at<br>
the time and have to remember to download it later when the mail itself is<br>
already marked as read, that isn't 100%.)<br>
<br>
But closing it, I have to navigate to the website which I'm not always logged<br>
into even when I am online. (Why github-generated .patch files don't have the<br>
"closes #xxx" magic signature you were telling me about, I couldn't tell you.<br>
They didn't anticipate this workflow, I guess? "I have assumptions about how<br>
this hammer will be used, and it breaks if you don't do that" = cheap hammer.)<br></blockquote><div><br></div><div>(the whole "you need to fork the project to send a patch" model just baffles me. i don't think i could have come up with a more alien way of contributing to a project than github's if i'd actually set out to try to do so. just the fact that it litters the internet with abandoned "forks" [that aren't usually really forks in the traditional sense] and leaves you struggling to understand which [if any] is the "real" project...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm aware capitalism loves "allow me to insert my product or service into your<br>
existing daily work flow so you can't get anything done without it", but I break<br>
everything and assume most things go away again after away, and... it's a web<br>
gui for what I do locally on the command line and then push out batch updates<br>
when I remember.<br>
<br>
The main advantage of it for _me_ (other than not having to set up a git server<br>
on dreamhost) is to be able to point other people conveniently at a commit<br>
rather than "here's a hash I hope you know how to use git". (If I'm not online<br>
going through email, I can grab the hash out of the URL and "git show" in a<br>
locally checked out tree so it's longer but not _worse_ than just the hash...)<br>
<br>
> i'm happy to be the manual nag bot though. for example:<br>
> <a href="https://github.com/landley/toybox/pull/234" rel="noreferrer" target="_blank">https://github.com/landley/toybox/pull/234</a> :-)<br>
<br>
Yay, thanks. What's a 234... Ah, I still have a tab open for that one. :)<br>
<br>
Rob<br>
</blockquote></div></div>