Transition from RT to GitHub [FAQ]

Hi everyone,


Following are a set of common questions and their answers regarding this
change. It probably will not address every question you have, but I hope
it provides more details on the expected move.


Q: What problems will this help with?

A: Several things:

* Lack of ability to file bugs via the web.

* Bug reports being delayed or lost.

* Access control issues to bugs.

* Things that break in weird ways and nobody notices for weeks (e.g.,
data integrity).

* Spam filtering.


Q: Do you still like RT (Request Tracker)

A: Yes. We still love it. The issues aren’t with RT itself but with the
complex integrations we’ve built around it.


Q: Can’t the current system be fixed/improved?

A: With sufficient time and resources anything can be fixed. But the
current system is built on code that’s 10-20 years old (some of it is
still in perl4-ish style!). The fact that it’s worked so well for so
long is amazing, but any fixes would just be band-aids and wouldn’t help
with longevity.


Q: Why not GitLab or some other application that could be self-hosted?

A: Our core competency and focus is Perl 5. A significant amount of
volunteer time has been spent by community members over the years
maintaining these systems. We would like to focus available energy on
the language, rather than on infrastructure maintenance. We investigated
several options, and came to the conclusion that GitHub was our best choice.


Q: Will I need a GitHub account?

A: Yes. Most active perl5-porters already have an account. Requiring an
account helps address a major problem over the years: spam.


The problem with anonymous ticket submission is that it inevitably
becomes a spam target. You can of course get rid of much of the bad
traffic with filtering. However you are still left with processes that
are fragile and/or overly dependent on humans.


Q: I won't sign up for a GitHub account.

A: We understand not everyone wishes to open a GitHub account.
Unfortunately, we still need to deal with the reality of not being able
to maintain the current system.


Read access to issues and the repo do not require an account, so
everything will be open to view by anonymous access.


Q: What if GitHub goes away?

A: We believe that GitHub is going to be around for a long time. It has
critical mass in the open source community, and is backed by Microsoft
which is not interested in seeing it fail. Its powerful API makes it
possible to keep a backup of all of our data, should we have to migrate.


Q: Will this change how we use Git?

A: There are no plans to do so. We’re just moving the “canonical” git
repository.


Q: What will people see when they visit links in old documentation,
commit messages, etc.? 

A: The old URLs will automatically redirect to GitHub issues. The top of
each migrated ticket will provide a link pointing to a read-only
archived copy from RT.


Q: What about closed issues and special tags in the cases? 

A: All issues (open and closed) will be moved to GitHub. Any special
tags (like operating system, Perl 5 version, etc.) will be made tags in
GitHub.


Q What will happen to tickets that continue to be reported by perlbug
via email?

A: Reviewing the rate of new reporters, we don't expect a significant
impact. The email address will auto-reply with instructions on how to
report the issue via GitHub. For an initial interim period, we will
monitor perlbug@perl.org <mailto:perlbug@perl.org>so issues are not lost.


Q: Can I continue reporting bugs using perlbug?

A: The current workflow using perlbug is fully supported at the moment.
We will communicate prior to any changes to this workflow.


Q: What will happen to perlbug in future versions of the language?

A: We propose transitioning it to a tool that collects report
information and then make it easy for people to then submit this report
to GitHub.


Q: What about security issues?

A: Reporting security issues should continue to be done by emailing
perl5-security-report@perl.org <mailto:perl5-security-report@perl.org>.
GitHub has provided us with a private repository for tracking security
issues and we will be able to make these public once resolved, as we
currently do in RT.


Q: What about smoking?

A: Our current smoking setup is unaffected by this change.


Because it is easy to do, we will be leveraging https://travis-ci.orgto
smoke our branches and pull requests. It will also be possible to add
other existing smoking systems to this interface, enabling reporting of
all smoker runs to be integrated into the central GitHub interface.


Q: What about perl5.git.perl.org?

A: It will be made a mirror of https://github.com/Perl/perl5and may be
retired at a future date based on usage.


Q: What about the metaconfig repository?

A: The metaconfig is not in scope for this change. Any such decision is
left to the current metaconfig maintainers.


Q: Will all ticket updates be sent to the list as before?

A: Only the initial ticket creation will show up on the list. This will
give you the ability to monitor only the issues you care about. You can
also monitor the whole project on GitHub to get all updates by simply
setting watch as you see fit in GitHub.


Updates will be received based on monitoring the person chooses or when
said person is explicitly mentioned. You may choose to monitor
everything (what we call the “firehose mode”), as currently on the p5p
mailing list.


Q: What about IRC notifications

A: The IRC bot can be switched to use a web hook and notify just like it
does now.


Q: How can I help with the issue migration to GitHub?

A: We can definitely use your help reviewing a test conversion for major
issues that need repair. We'll announce when the demo conversion is
ready in the next week.


Q: What else needs doing?

A: We need to know about any existing integration with RT or perl5's
existing git repo. If you know of something, please let us know so it
can be accommodated during the migration.

Thank you,

S.
0
xsawyerx
7/8/2019 10:45:28 PM
perl.perl5.porters 47815 articles. 1 followers. Follow

59 Replies
99 Views

Similar Articles

[PageSpeed] 46

On 7/8/19 6:45 PM, Sawyer X wrote:
> Hi everyone,
> 
> 
> Following are a set of common questions and their answers regarding this
> change. It probably will not address every question you have, but I hope
> it provides more details on the expected move.
> 
> 
> Q: What problems will this help with?
> 
> A: Several things:
> 
> * Lack of ability to file bugs via the web.
> 
> * Bug reports being delayed or lost.
> 
> * Access control issues to bugs.
> 
> * Things that break in weird ways and nobody notices for weeks (e.g.,
> data integrity).
> 
> * Spam filtering.
> 
> 
> Q: Do you still like RT (Request Tracker)
> 
> A: Yes. We still love it. The issues aren’t with RT itself but with the
> complex integrations we’ve built around it.
> 
> 
> Q: Can’t the current system be fixed/improved?
> 
> A: With sufficient time and resources anything can be fixed. But the
> current system is built on code that’s 10-20 years old (some of it is
> still in perl4-ish style!). The fact that it’s worked so well for so
> long is amazing, but any fixes would just be band-aids and wouldn’t help
> with longevity.
> 
> 
> Q: Why not GitLab or some other application that could be self-hosted?
> 
> A: Our core competency and focus is Perl 5. A significant amount of
> volunteer time has been spent by community members over the years
> maintaining these systems. We would like to focus available energy on
> the language, rather than on infrastructure maintenance. We investigated
> several options, and came to the conclusion that GitHub was our best choice.
> 
> 
> Q: Will I need a GitHub account?
> 
> A: Yes. Most active perl5-porters already have an account. Requiring an
> account helps address a major problem over the years: spam.
> 
> 
> The problem with anonymous ticket submission is that it inevitably
> becomes a spam target. You can of course get rid of much of the bad
> traffic with filtering. However you are still left with processes that
> are fragile and/or overly dependent on humans.
> 
> 
> Q: I won't sign up for a GitHub account.
> 
> A: We understand not everyone wishes to open a GitHub account.
> Unfortunately, we still need to deal with the reality of not being able
> to maintain the current system.
> 
> 
> Read access to issues and the repo do not require an account, so
> everything will be open to view by anonymous access.
> 
> 
> Q: What if GitHub goes away?
> 
> A: We believe that GitHub is going to be around for a long time. It has
> critical mass in the open source community, and is backed by Microsoft
> which is not interested in seeing it fail. Its powerful API makes it
> possible to keep a backup of all of our data, should we have to migrate.
> 
> 
> Q: Will this change how we use Git?
> 
> A: There are no plans to do so. We’re just moving the “canonical” git
> repository.
> 
> 
> Q: What will people see when they visit links in old documentation,
> commit messages, etc.?
> 
> A: The old URLs will automatically redirect to GitHub issues. The top of
> each migrated ticket will provide a link pointing to a read-only
> archived copy from RT.
> 
> 
> Q: What about closed issues and special tags in the cases?
> 
> A: All issues (open and closed) will be moved to GitHub. Any special
> tags (like operating system, Perl 5 version, etc.) will be made tags in
> GitHub.
> 
> 
> Q What will happen to tickets that continue to be reported by perlbug
> via email?
> 
> A: Reviewing the rate of new reporters, we don't expect a significant
> impact. The email address will auto-reply with instructions on how to
> report the issue via GitHub. For an initial interim period, we will
> monitor perlbug@perl.org <mailto:perlbug@perl.org>so issues are not lost.
> 
> 
> Q: Can I continue reporting bugs using perlbug?
> 
> A: The current workflow using perlbug is fully supported at the moment.
> We will communicate prior to any changes to this workflow.
> 
> 
> Q: What will happen to perlbug in future versions of the language?
> 
> A: We propose transitioning it to a tool that collects report
> information and then make it easy for people to then submit this report
> to GitHub.
> 
> 
> Q: What about security issues?
> 
> A: Reporting security issues should continue to be done by emailing
> perl5-security-report@perl.org <mailto:perl5-security-report@perl.org>.
> GitHub has provided us with a private repository for tracking security
> issues and we will be able to make these public once resolved, as we
> currently do in RT.
> 
> 
> Q: What about smoking?
> 
> A: Our current smoking setup is unaffected by this change.
> 
> 
> Because it is easy to do, we will be leveraging https://travis-ci.orgto
> smoke our branches and pull requests. It will also be possible to add
> other existing smoking systems to this interface, enabling reporting of
> all smoker runs to be integrated into the central GitHub interface.
> 
> 
> Q: What about perl5.git.perl.org?
> 
> A: It will be made a mirror of https://github.com/Perl/perl5and may be
> retired at a future date based on usage.
> 
> 
> Q: What about the metaconfig repository?
> 
> A: The metaconfig is not in scope for this change. Any such decision is
> left to the current metaconfig maintainers.
> 
> 
> Q: Will all ticket updates be sent to the list as before?
> 
> A: Only the initial ticket creation will show up on the list. This will
> give you the ability to monitor only the issues you care about. You can
> also monitor the whole project on GitHub to get all updates by simply
> setting watch as you see fit in GitHub.
> 

One of the features about our infrastructure that I have most 
appreciated over the years is the fact that I can use either a mail 
interface (perl5-porters@perl.org) or a news interface 
(perl.perl5.porters) to both read and write to the list.  I've always 
enjoyed the fact that I can handle my perl groups in a way completely 
outside the scope of my email accounts, i.e., via the news interface.

Up until now, this has also meant that everything posted to rt.perl.org 
(whether original postings via email to perlbug@perl.org or subsequent 
follow-ups via email or web interface) has been cross-posted to both the 
mailing list and the newsgroup.

I understand from personal experience and from many 
bug-ticket-conversations with Robert and Ask (our sysadmins) that these 
are the parts of the system that have been difficult to maintain.  For 
example, just last week there was a case where messages were being 
posted on the mailing list but not simultaneously being posted to the 
newsgroup and archived at 
https://www.nntp.perl.org/group/perl.perl5.porters/.

Even if, under the proposed new system, only the first posting in a 
GitHub issue is cross-posted to the list, I would like us to continue to 
guarantee that that first posting is cross-posted to both the mailing 
list and the newsgroup.  (I understand that subsequent postings to a 
GitHub issue will not be cross-posted to the mailing list, so I won't 
expect them to be cross-posted to the newsgroup (or archived) either.)

I would also like us to continue to guarantee that one can still read or 
write the list using either mail or news interfaces.

If making these guarantees work requires additional coding effort, I am 
willing to be part of such an effort.

Thank you very much.
Jim Keenan

> 
> Updates will be received based on monitoring the person chooses or when
> said person is explicitly mentioned. You may choose to monitor
> everything (what we call the “firehose mode”), as currently on the p5p
> mailing list.
> 
> 
> Q: What about IRC notifications
> 
> A: The IRC bot can be switched to use a web hook and notify just like it
> does now.
> 
> 
> Q: How can I help with the issue migration to GitHub?
> 
> A: We can definitely use your help reviewing a test conversion for major
> issues that need repair. We'll announce when the demo conversion is
> ready in the next week.
> 
> 
> Q: What else needs doing?
> 
> A: We need to know about any existing integration with RT or perl5's
> existing git repo. If you know of something, please let us know so it
> can be accommodated during the migration.
> 
> Thank you,
> 
> S.
> 
0
jkeenan
7/8/2019 11:12:07 PM
--00000000000005d8b0058d38c1ff
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 8, 2019 at 6:45 PM Sawyer X <xsawyerx@gmail.com> wrote:

> Q: What else needs doing?
>
> A: We need to know about any existing integration with RT or perl5's
> existing git repo. If you know of something, please let us know so it
> can be accommodated during the migration.
>

perl-build (
https://metacpan.org/release/Perl-Build/source/script/perl-build#L67) and
perlbrew (https://metacpan.org/source/App::perlbrew#L1414) both download
blead snapshots when requested from
https://perl5.git.perl.org/perl.git/snapshot/blead.tar.gz - this should be
forwarded to https://github.com/Perl/perl5/archive/blead.tar.gz . Perlbrew
calls it from HTTP, but it uses curl/wget so a redirect to HTTPS should not
cause issues.

-Dan

--00000000000005d8b0058d38c1ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 8, 2019 at 6:45 PM Sawyer X &=
lt;<a href=3D"mailto:xsawyerx@gmail.com">xsawyerx@gmail.com</a>&gt; wrote:<=
/div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
Q: What else needs doing?<br>
<br>
A: We need to know about any existing integration with RT or perl5&#39;s<br=
>
existing git repo. If you know of something, please let us know so it<br>
can be accommodated during the migration.<br></blockquote><div><br></div><d=
iv>perl-build (<a href=3D"https://metacpan.org/release/Perl-Build/source/sc=
ript/perl-build#L67">https://metacpan.org/release/Perl-Build/source/script/=
perl-build#L67</a>) and perlbrew (<a href=3D"https://metacpan.org/source/Ap=
p::perlbrew#L1414">https://metacpan.org/source/App::perlbrew#L1414</a>) bot=
h download blead snapshots when requested from <a href=3D"https://perl5.git=
..perl.org/perl.git/snapshot/blead.tar.gz">https://perl5.git.perl.org/perl.g=
it/snapshot/blead.tar.gz</a> - this should be forwarded to=C2=A0<a href=3D"=
https://github.com/Perl/perl5/archive/blead.tar.gz">https://github.com/Perl=
/perl5/archive/blead.tar.gz</a>=C2=A0. Perlbrew calls it from HTTP, but it =
uses curl/wget so a redirect to HTTPS should not cause issues.</div><div><b=
r></div><div>-Dan</div></div></div>

--00000000000005d8b0058d38c1ff--
0
grinnz
7/9/2019 5:22:30 AM
--000000000000ed268e058d3fb65b
Content-Type: text/plain; charset="UTF-8"

Bra-vo! Answers all my questions. Looking forward to my first PR.

On Tue, Jul 9, 2019 at 1:23 AM Dan Book <grinnz@gmail.com> wrote:

> On Mon, Jul 8, 2019 at 6:45 PM Sawyer X <xsawyerx@gmail.com> wrote:
>
>> Q: What else needs doing?
>>
>> A: We need to know about any existing integration with RT or perl5's
>> existing git repo. If you know of something, please let us know so it
>> can be accommodated during the migration.
>>
>
> perl-build (
> https://metacpan.org/release/Perl-Build/source/script/perl-build#L67) and
> perlbrew (https://metacpan.org/source/App::perlbrew#L1414) both download
> blead snapshots when requested from
> https://perl5.git.perl.org/perl.git/snapshot/blead.tar.gz - this should
> be forwarded to https://github.com/Perl/perl5/archive/blead.tar.gz .
> Perlbrew calls it from HTTP, but it uses curl/wget so a redirect to HTTPS
> should not cause issues.
>
> -Dan
>


-- 
Matthew O. Persico

--000000000000ed268e058d3fb65b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Bra-vo! Answers all my questions. Looking forward to my fi=
rst PR.</div><br><div class=3D"gmail_quote"><div class=3D"gmail_attr" dir=
=3D"ltr">On Tue, Jul 9, 2019 at 1:23 AM Dan Book &lt;<a href=3D"mailto:grin=
nz@gmail.com">grinnz@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-lef=
t-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><di=
v dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 8, 2019 at 6:45 PM Sawyer X &lt;=
<a href=3D"mailto:xsawyerx@gmail.com" target=3D"_blank">xsawyerx@gmail.com<=
/a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:=
rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Q: What else needs doing?<br>
<br>
A: We need to know about any existing integration with RT or perl5&#39;s<br=
>
existing git repo. If you know of something, please let us know so it<br>
can be accommodated during the migration.<br></blockquote><div><br></div><d=
iv>perl-build (<a href=3D"https://metacpan.org/release/Perl-Build/source/sc=
ript/perl-build#L67" target=3D"_blank">https://metacpan.org/release/Perl-Bu=
ild/source/script/perl-build#L67</a>) and perlbrew (<a href=3D"https://meta=
cpan.org/source/App::perlbrew#L1414" target=3D"_blank">https://metacpan.org=
/source/App::perlbrew#L1414</a>) both download blead snapshots when request=
ed from <a href=3D"https://perl5.git.perl.org/perl.git/snapshot/blead.tar.g=
z" target=3D"_blank">https://perl5.git.perl.org/perl.git/snapshot/blead.tar=
..gz</a> - this should be forwarded to=C2=A0<a href=3D"https://github.com/Pe=
rl/perl5/archive/blead.tar.gz" target=3D"_blank">https://github.com/Perl/pe=
rl5/archive/blead.tar.gz</a>=C2=A0. Perlbrew calls it from HTTP, but it use=
s curl/wget so a redirect to HTTPS should not cause issues.</div><div><br><=
/div><div>-Dan</div></div></div>
</blockquote></div><br clear=3D"all"><br>-- <br><div class=3D"gmail_signatu=
re" dir=3D"ltr">Matthew O. Persico</div>

--000000000000ed268e058d3fb65b--
0
matthew
7/9/2019 1:41:03 PM
On 7/9/19 2:12 AM, James E Keenan wrote:
> On 7/8/19 6:45 PM, Sawyer X wrote:
>> [...]
>>
>> Q: Will all ticket updates be sent to the list as before?
>>
>> A: Only the initial ticket creation will show up on the list. This will
>> give you the ability to monitor only the issues you care about. You can
>> also monitor the whole project on GitHub to get all updates by simply
>> setting watch as you see fit in GitHub.
>>
>
> One of the features about our infrastructure that I have most
> appreciated over the years is the fact that I can use either a mail
> interface (perl5-porters@perl.org) or a news interface
> (perl.perl5.porters) to both read and write to the list.  I've always
> enjoyed the fact that I can handle my perl groups in a way completely
> outside the scope of my email accounts, i.e., via the news interface.
>
> Up until now, this has also meant that everything posted to
> rt.perl.org (whether original postings via email to perlbug@perl.org
> or subsequent follow-ups via email or web interface) has been
> cross-posted to both the mailing list and the newsgroup.
>
> I understand from personal experience and from many
> bug-ticket-conversations with Robert and Ask (our sysadmins) that
> these are the parts of the system that have been difficult to
> maintain.  For example, just last week there was a case where messages
> were being posted on the mailing list but not simultaneously being
> posted to the newsgroup and archived at
> https://www.nntp.perl.org/group/perl.perl5.porters/.
>
> Even if, under the proposed new system, only the first posting in a
> GitHub issue is cross-posted to the list, I would like us to continue
> to guarantee that that first posting is cross-posted to both the
> mailing list and the newsgroup.  (I understand that subsequent
> postings to a GitHub issue will not be cross-posted to the mailing
> list, so I won't expect them to be cross-posted to the newsgroup (or
> archived) either.)


I think this is a fine intent, and the question would be: How much
effort would it be to maintain vs. how many people use it. I can think
of more than one way to implement it. We just need someone to do it.



>
> I would also like us to continue to guarantee that one can still read
> or write the list using either mail or news interfaces.


Email is available with GitHub. You can both receive updates as emails
and reply to them via email. (I don't know if they provide a news
interface.) You do not need to use the web interface.


>
> If making these guarantees work requires additional coding effort, I
> am willing to be part of such an effort.


I'm not familiar enough what newsgroup maintenance and archiving but you
could use a web hook to trigger your code on changes to tickets.


You can read more about it here: https://developer.github.com/webhooks/


>
>>
>> [...]
0
xsawyerx
7/9/2019 4:35:12 PM
On 7/9/19 2:12 AM, James E Keenan wrote:

> Even if, under the proposed new system, only the first posting in a
> GitHub issue is cross-posted to the list, I would like us to continue
> to guarantee that that first posting is cross-posted to both the
> mailing list and the newsgroup.  (I understand that subsequent
> postings to a GitHub issue will not be cross-posted to the mailing
> list, so I won't expect them to be cross-posted to the newsgroup (or
> archived) either.)

Hi James (and everyone),

I am glad you are making use of the NNTP service.

Just to set expectations I want to tell that it=E2=80=99s mostly =
surviving because it=E2=80=99s also backing the web archive, but to be =
honest it=E2=80=99s just a problem or two away from being turned off =
(fortunately it hasn=E2=80=99t had many problems for a long long while).

In the last ~24 hours only 32 unique IPs have accessed the NNTP server =
at all, and that includes 10 that only read one or two articles and a =
few IPs that mostly look like they are just scraping content or worse. =
Only 9 of them (scraping or otherwise) read something from =
perl5-porters, if I am reading the logs right.

For comparison more than 500 people will get this email and almost two =
thousand are subscribed to the beginners list.


Ask
0
ask
7/10/2019 2:31:21 AM
On Tue, 9 Jul 2019 at 07:23, Dan Book <grinnz@gmail.com> wrote:
>
> On Mon, Jul 8, 2019 at 6:45 PM Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> Q: What else needs doing?
>>
>> A: We need to know about any existing integration with RT or perl5's
>> existing git repo. If you know of something, please let us know so it
>> can be accommodated during the migration.
>
>
> perl-build (https://metacpan.org/release/Perl-Build/source/script/perl-bu=
ild#L67) and perlbrew (https://metacpan.org/source/App::perlbrew#L1414) bot=
h download blead snapshots when requested from https://perl5.git.perl.org/p=
erl.git/snapshot/blead.tar.gz - this should be forwarded to https://github.=
com/Perl/perl5/archive/blead.tar.gz . Perlbrew calls it from HTTP, but it u=
ses curl/wget so a redirect to HTTPS should not cause issues.

I think in practice *this* is going to be one of the bigger
challenges. We had to hack the git page to support producing the
correct tarball with the correct contents. (Specifically we inject a
file into the tarball that is not contained in the repository) My bet
is that out of the box github will not be able to support our use
case.

Yves

--=20
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"
0
demerphq
7/10/2019 10:34:33 AM
On Tue, Jul 9, 2019 at 7:23 AM Dan Book <grinnz@gmail.com> wrote:
>
> On Mon, Jul 8, 2019 at 6:45 PM Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> Q: What else needs doing?
>>
>> A: We need to know about any existing integration with RT or perl5's
>> existing git repo. If you know of something, please let us know so it
>> can be accommodated during the migration.
>
>
> perl-build (https://metacpan.org/release/Perl-Build/source/script/perl-bu=
ild#L67) and perlbrew (https://metacpan.org/source/App::perlbrew#L1414) bot=
h download blead snapshots when requested from https://perl5.git.perl.org/p=
erl.git/snapshot/blead.tar.gz - this should be forwarded to https://github.=
com/Perl/perl5/archive/blead.tar.gz . Perlbrew calls it from HTTP, but it u=
ses curl/wget so a redirect to HTTPS should not cause issues.

The contents of the files are subtly different.  perl5.git.perl.org
provides tarballs with a top level directory named
perl-blead-$shortsha1, where the github tarball top level directory is
just perl-blead.  perlbrew and perl-build both require the short hash
to be present, or they will ignore the directory:
https://metacpan.org/source/App::perlbrew#L1390
https://metacpan.org/source/SKAJI/Perl-Build-1.29/lib/Perl/Build.pm#L57

>
> -Dan
0
haarg
7/10/2019 3:24:37 PM
--0000000000006b1351058d557455
Content-Type: text/plain; charset="UTF-8"

I think you missed the patch file we inject.

Yves

On Wed, 10 Jul 2019, 17:25 Graham Knop, <haarg@haarg.org> wrote:

> On Tue, Jul 9, 2019 at 7:23 AM Dan Book <grinnz@gmail.com> wrote:
> >
> > On Mon, Jul 8, 2019 at 6:45 PM Sawyer X <xsawyerx@gmail.com> wrote:
> >>
> >> Q: What else needs doing?
> >>
> >> A: We need to know about any existing integration with RT or perl5's
> >> existing git repo. If you know of something, please let us know so it
> >> can be accommodated during the migration.
> >
> >
> > perl-build (
> https://metacpan.org/release/Perl-Build/source/script/perl-build#L67) and
> perlbrew (https://metacpan.org/source/App::perlbrew#L1414) both download
> blead snapshots when requested from
> https://perl5.git.perl.org/perl.git/snapshot/blead.tar.gz - this should
> be forwarded to https://github.com/Perl/perl5/archive/blead.tar.gz .
> Perlbrew calls it from HTTP, but it uses curl/wget so a redirect to HTTPS
> should not cause issues.
>
> The contents of the files are subtly different.  perl5.git.perl.org
> provides tarballs with a top level directory named
> perl-blead-$shortsha1, where the github tarball top level directory is
> just perl-blead.  perlbrew and perl-build both require the short hash
> to be present, or they will ignore the directory:
> https://metacpan.org/source/App::perlbrew#L1390
> https://metacpan.org/source/SKAJI/Perl-Build-1.29/lib/Perl/Build.pm#L57
>
> >
> > -Dan
>

--0000000000006b1351058d557455
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I think you missed the patch file we inject.<div dir=3D"a=
uto"><br></div><div dir=3D"auto">Yves</div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 10 Jul 2019, 17:25 Graha=
m Knop, &lt;<a href=3D"mailto:haarg@haarg.org">haarg@haarg.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">On Tue, Jul 9, 2019 at 7:23 AM D=
an Book &lt;<a href=3D"mailto:grinnz@gmail.com" target=3D"_blank" rel=3D"no=
referrer">grinnz@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Mon, Jul 8, 2019 at 6:45 PM Sawyer X &lt;<a href=3D"mailto:xsawyerx=
@gmail.com" target=3D"_blank" rel=3D"noreferrer">xsawyerx@gmail.com</a>&gt;=
 wrote:<br>
&gt;&gt;<br>
&gt;&gt; Q: What else needs doing?<br>
&gt;&gt;<br>
&gt;&gt; A: We need to know about any existing integration with RT or perl5=
&#39;s<br>
&gt;&gt; existing git repo. If you know of something, please let us know so=
 it<br>
&gt;&gt; can be accommodated during the migration.<br>
&gt;<br>
&gt;<br>
&gt; perl-build (<a href=3D"https://metacpan.org/release/Perl-Build/source/=
script/perl-build#L67" rel=3D"noreferrer noreferrer" target=3D"_blank">http=
s://metacpan.org/release/Perl-Build/source/script/perl-build#L67</a>) and p=
erlbrew (<a href=3D"https://metacpan.org/source/App::perlbrew#L1414" rel=3D=
"noreferrer noreferrer" target=3D"_blank">https://metacpan.org/source/App::=
perlbrew#L1414</a>) both download blead snapshots when requested from <a hr=
ef=3D"https://perl5.git.perl.org/perl.git/snapshot/blead.tar.gz" rel=3D"nor=
eferrer noreferrer" target=3D"_blank">https://perl5.git.perl.org/perl.git/s=
napshot/blead.tar.gz</a> - this should be forwarded to <a href=3D"https://g=
ithub.com/Perl/perl5/archive/blead.tar.gz" rel=3D"noreferrer noreferrer" ta=
rget=3D"_blank">https://github.com/Perl/perl5/archive/blead.tar.gz</a> . Pe=
rlbrew calls it from HTTP, but it uses curl/wget so a redirect to HTTPS sho=
uld not cause issues.<br>
<br>
The contents of the files are subtly different.=C2=A0 <a href=3D"http://per=
l5.git.perl.org" rel=3D"noreferrer noreferrer" target=3D"_blank">perl5.git.=
perl.org</a><br>
provides tarballs with a top level directory named<br>
perl-blead-$shortsha1, where the github tarball top level directory is<br>
just perl-blead.=C2=A0 perlbrew and perl-build both require the short hash<=
br>
to be present, or they will ignore the directory:<br>
<a href=3D"https://metacpan.org/source/App::perlbrew#L1390" rel=3D"noreferr=
er noreferrer" target=3D"_blank">https://metacpan.org/source/App::perlbrew#=
L1390</a><br>
<a href=3D"https://metacpan.org/source/SKAJI/Perl-Build-1.29/lib/Perl/Build=
..pm#L57" rel=3D"noreferrer noreferrer" target=3D"_blank">https://metacpan.o=
rg/source/SKAJI/Perl-Build-1.29/lib/Perl/Build.pm#L57</a><br>
<br>
&gt;<br>
&gt; -Dan<br>
</blockquote></div>

--0000000000006b1351058d557455--
0
demerphq
7/10/2019 3:37:17 PM
On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:

> The problem with anonymous ticket submission is that it inevitably
> becomes a spam target. You can of course get rid of much of the bad
> traffic with filtering. However you are still left with processes that
> are fragile and/or overly dependent on humans.

Technically you can still "anonymously" submit bug reports (or without an
account), because you can still mail them direct to the list. It just won't
get into the issue tracker that way :-/

> A: We believe that GitHub is going to be around for a long time. It has

Which, with hindsight, could not have been said last year. I had no idea
how much money it was losing until all the news about the sale.

> critical mass in the open source community, and is backed by Microsoft
> which is not interested in seeing it fail. Its powerful API makes it
> possible to keep a backup of all of our data, should we have to migrate.

And of course, Microsoft is Evil, and they know it, so they can't afford
to mess up (any more) and loose more mindshare.

Whereas various other firms (eg Google, Apple, Facebook, Amazon) who might
ave bought it are all angels, so would never do anything daft.

> Q: Will this change how we use Git?
> 
> A: There are no plans to do so. We’re just moving the “canonical” git
> repository.

Please can we take care to stick to "no plans to do so".

Specifically in another mail Hugo noted one of my main concerns -
historically github has made it easy with pull requests to make a history
graph that is complete spaghetti (although unlike spaghetti code, this will
of course always be acyclic (oh, prove me wrong with an SHA-1 collision)).

git bisect is a very valuable tool - please can we continue to rebase
(where possible) before merging in patches and changes.

(even if the merge isn't a fast-forward, the trivial merge commit isn't
going to mess up bisectability)

> A: All issues (open and closed) will be moved to GitHub. Any special
> tags (like operating system, Perl 5 version, etc.) will be made tags in
> GitHub.

I'm very glad to read that this is the plan. I have had occasional cause
to need to reference bug IDs in the pre-2002 bug tracker, and it is useful
that those tickets were migrated to RT. For some amusement value, this
now means that those tickets will migrate onwards.

> A: Reporting security issues should continue to be done by emailing
> perl5-security-report@perl.org <mailto:perl5-security-report@perl.org>.
> GitHub has provided us with a private repository for tracking security
> issues and we will be able to make these public once resolved, as we
> currently do in RT.

With sufficient permissions that third party security reporters can see
discussions/progress on their own tickets, without getting leakage from
other tickets?

Or "Sadly, no, we're going to have to relay them info back by mail" ?

> Q: What about perl5.git.perl.org?
> 
> A: It will be made a mirror of https://github.com/Perl/perl5and may be
> retired at a future date based on usage.

Note that that URL isn't controlled by booking.com.
It's the perl.org DNS that determines which host gets to serve it.
It bounced around between a couple of possibilities during the git
migration.

Whereas the future plan of making github "canonical" does mean that there
is now an uninterested/untrusted third party who now have some control
over what is perceived as the true perl.

(This might matter in the case of an acrimonious fork, where both sides are
claiming that the other is the antipope.)

> Q: Will all ticket updates be sent to the list as before?
> 
> A: Only the initial ticket creation will show up on the list. This will
> give you the ability to monitor only the issues you care about. You can
> also monitor the whole project on GitHub to get all updates by simply
> setting watch as you see fit in GitHub.
> 
> 
> Updates will be received based on monitoring the person chooses or when
> said person is explicitly mentioned. You may choose to monitor
> everything (what we call the “firehose mode”), as currently on the p5p
> mailing list.

Not that I've been active recently, but personally this change is something
that saddens me. I had always felt that it was useful that the main
development forum was not decoupled from the nitty-gritty of

1) actually fixing stuff (ie graft, not just ideas)
2) the implications of changes (ie what turned out to break, what it really
   cost)


Also, it's really useful that mail readers are threaded. (I think RT is too).
It's much easier to follow complex discussions in a threaded view, instead of
a forced-sorted-by-time flat view.

github only has the latter, doesn't it?

This is making the easy stuff easier (or shinier) but the hard stuff harder.
(But that's part of their business sales model, isn't it?)

On the other hand, at least it's not JIRA.
(Although, I hate the world for not having an obvious alternative to JIRA.
There's clearly money to be made here - why isn't anyone else able to?

Nicholas Clark
0
nick
7/11/2019 10:31:35 AM
On Thu, Jul 11, 2019 at 6:00 AM Nicholas Clark <nick@ccl4.org> wrote:
>
> On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:

> > Q: Will this change how we use Git?
> >
> > A: There are no plans to do so. We=E2=80=99re just moving the =E2=80=9C=
canonical=E2=80=9D git
> > repository.
>
> Please can we take care to stick to "no plans to do so".
>
> Specifically in another mail Hugo noted one of my main concerns -
> historically github has made it easy with pull requests to make a history
> graph that is complete spaghetti (although unlike spaghetti code, this wi=
ll
> of course always be acyclic (oh, prove me wrong with an SHA-1 collision))=
..
>
> git bisect is a very valuable tool - please can we continue to rebase
> (where possible) before merging in patches and changes.
>
> (even if the merge isn't a fast-forward, the trivial merge commit isn't
> going to mess up bisectability)

+1.  I really loathe the most common GitHub workflow where the commit
history consists almost entirely of "Merge pull request #1234 from
somebody/somebranch/about...<cut off>" which is devoid of relevant
content and I believe these merges also show up as affecting every
file in the repository, making it difficult to track history affecting
a specific file.


> > Q: Will all ticket updates be sent to the list as before?
> >
> > A: Only the initial ticket creation will show up on the list. This will
> > give you the ability to monitor only the issues you care about. You can
> > also monitor the whole project on GitHub to get all updates by simply
> > setting watch as you see fit in GitHub.
> >
> >
> > Updates will be received based on monitoring the person chooses or when
> > said person is explicitly mentioned. You may choose to monitor
> > everything (what we call the =E2=80=9Cfirehose mode=E2=80=9D), as curre=
ntly on the p5p
> > mailing list.
>
> Not that I've been active recently, but personally this change is somethi=
ng
> that saddens me. I had always felt that it was useful that the main
> development forum was not decoupled from the nitty-gritty of
>
> 1) actually fixing stuff (ie graft, not just ideas)
> 2) the implications of changes (ie what turned out to break, what it real=
ly
>    cost)
>
>
> Also, it's really useful that mail readers are threaded. (I think RT is t=
oo).
> It's much easier to follow complex discussions in a threaded view, instea=
d of
> a forced-sorted-by-time flat view.
>
> github only has the latter, doesn't it?

I believe it also means going to two places to follow what's going on,
doesn't it?  If I see a bug report on the mailing list and choose to
follow it, then I presumably have to go to GitHub every day and see if
anything I'm following has had changes.  Correct me if I'm wrong.
0
craig
7/12/2019 2:51:35 PM
On Wed, Jul 10, 2019 at 5:35 AM demerphq <demerphq@gmail.com> wrote:
>
> On Tue, 9 Jul 2019 at 07:23, Dan Book <grinnz@gmail.com> wrote:
> >
> > On Mon, Jul 8, 2019 at 6:45 PM Sawyer X <xsawyerx@gmail.com> wrote:
> >>
> >> Q: What else needs doing?
> >>
> >> A: We need to know about any existing integration with RT or perl5's
> >> existing git repo. If you know of something, please let us know so it
> >> can be accommodated during the migration.
> >
> >
> > perl-build (https://metacpan.org/release/Perl-Build/source/script/perl-=
build#L67) and perlbrew (https://metacpan.org/source/App::perlbrew#L1414) b=
oth download blead snapshots when requested from https://perl5.git.perl.org=
/perl.git/snapshot/blead.tar.gz - this should be forwarded to https://githu=
b.com/Perl/perl5/archive/blead.tar.gz . Perlbrew calls it from HTTP, but it=
 uses curl/wget so a redirect to HTTPS should not cause issues.
>
> I think in practice *this* is going to be one of the bigger
> challenges. We had to hack the git page to support producing the
> correct tarball with the correct contents. (Specifically we inject a
> file into the tarball that is not contained in the repository) My bet
> is that out of the box github will not be able to support our use
> case.

I think you are right.  I have poked around a bit to see if any
server-side scripting is available on GitHub and so far the answer
seems to be no.  So we have no way to include git_version.h in a
tarball or zipball downloaded from GitHub.
0
craig
7/12/2019 2:55:34 PM
--000000000000ee7470058d7d4618
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 12, 2019 at 10:52 AM Craig A. Berry <craig.a.berry@gmail.com>
wrote:

> On Thu, Jul 11, 2019 at 6:00 AM Nicholas Clark <nick@ccl4.org> wrote:
> >
> > On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:
>
> > > Q: Will this change how we use Git?
> > >
> > > A: There are no plans to do so. We=E2=80=99re just moving the =E2=80=
=9Ccanonical=E2=80=9D git
> > > repository.
> >
> > Please can we take care to stick to "no plans to do so".
> >
> > Specifically in another mail Hugo noted one of my main concerns -
> > historically github has made it easy with pull requests to make a histo=
ry
> > graph that is complete spaghetti (although unlike spaghetti code, this
> will
> > of course always be acyclic (oh, prove me wrong with an SHA-1
> collision)).
> >
> > git bisect is a very valuable tool - please can we continue to rebase
> > (where possible) before merging in patches and changes.
> >
> > (even if the merge isn't a fast-forward, the trivial merge commit isn't
> > going to mess up bisectability)
>
> +1.  I really loathe the most common GitHub workflow where the commit
> history consists almost entirely of "Merge pull request #1234 from
> somebody/somebranch/about...<cut off>" which is devoid of relevant
> content


As I mentioned previously, the rebase option for merging PRs is available.


> and I believe these merges also show up as affecting every
> file in the repository, making it difficult to track history affecting
> a specific file.


This is inaccurate.

-Dan

--000000000000ee7470058d7d4618
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jul 12, 2019 at 10:52 AM Craig A.=
 Berry &lt;<a href=3D"mailto:craig.a.berry@gmail.com">craig.a.berry@gmail.c=
om</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">On Thu, Jul 11, 2019 at 6:00 AM Nicholas Clark=
 &lt;<a href=3D"mailto:nick@ccl4.org" target=3D"_blank">nick@ccl4.org</a>&g=
t; wrote:<br>
&gt;<br>
&gt; On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:<br>
<br>
&gt; &gt; Q: Will this change how we use Git?<br>
&gt; &gt;<br>
&gt; &gt; A: There are no plans to do so. We=E2=80=99re just moving the =E2=
=80=9Ccanonical=E2=80=9D git<br>
&gt; &gt; repository.<br>
&gt;<br>
&gt; Please can we take care to stick to &quot;no plans to do so&quot;.<br>
&gt;<br>
&gt; Specifically in another mail Hugo noted one of my main concerns -<br>
&gt; historically github has made it easy with pull requests to make a hist=
ory<br>
&gt; graph that is complete spaghetti (although unlike spaghetti code, this=
 will<br>
&gt; of course always be acyclic (oh, prove me wrong with an SHA-1 collisio=
n)).<br>
&gt;<br>
&gt; git bisect is a very valuable tool - please can we continue to rebase<=
br>
&gt; (where possible) before merging in patches and changes.<br>
&gt;<br>
&gt; (even if the merge isn&#39;t a fast-forward, the trivial merge commit =
isn&#39;t<br>
&gt; going to mess up bisectability)<br>
<br>
+1.=C2=A0 I really loathe the most common GitHub workflow where the commit<=
br>
history consists almost entirely of &quot;Merge pull request #1234 from<br>
somebody/somebranch/about...&lt;cut off&gt;&quot; which is devoid of releva=
nt<br>
content</blockquote><div><br></div><div>As I mentioned previously, the reba=
se option for merging PRs is available.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">and I believe these merges also show u=
p as affecting every<br>
file in the repository, making it difficult to track history affecting<br>
a specific file.=C2=A0</blockquote><div><br></div><div>This is inaccurate.<=
/div><div><br></div><div>-Dan=C2=A0</div></div></div>

--000000000000ee7470058d7d4618--
0
grinnz
7/12/2019 3:07:52 PM
On Fri, Jul 12, 2019 at 10:08 AM Dan Book <grinnz@gmail.com> wrote:
>
> On Fri, Jul 12, 2019 at 10:52 AM Craig A. Berry <craig.a.berry@gmail.com> wrote:

>> +1.  I really loathe the most common GitHub workflow where the commit
>> history consists almost entirely of "Merge pull request #1234 from
>> somebody/somebranch/about...<cut off>" which is devoid of relevant
>> content
>
>
> As I mentioned previously, the rebase option for merging PRs is available.

Yes, I'm aware it's possible.  Just adding my voice to those saying
it's important to keep doing things this way.

>> and I believe these merges also show up as affecting every
>> file in the repository, making it difficult to track history affecting
>> a specific file.
>
>
> This is inaccurate.

Trivial merges do this now in gitweb.  If GitHub doesn't do that, then
that's another benefit of moving to GitHub.
0
craig
7/12/2019 5:13:49 PM
--0000000000005ab33a058d7f5413
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 11, 2019 at 7:00 AM Nicholas Clark <nick@ccl4.org> wrote:

> On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:
>
> > The problem with anonymous ticket submission is that it inevitably
> > becomes a spam target. You can of course get rid of much of the bad
> > traffic with filtering. However you are still left with processes that
> > are fragile and/or overly dependent on humans.
>
> Technically you can still "anonymously" submit bug reports (or without an
> account), because you can still mail them direct to the list. It just won't
> get into the issue tracker that way :-/
>

I can imagine a solution which primarily uses GitHub, while preserving the
ability to submit anonymous bug reports:

1. Email sent to <perlbug@perl.org> is handled by an auto-responder, as
planned.
2. The auto-responder sends a response containing GitHub instructions and a
separate section explaining how to submit the bug without using GitHub --
while encouraging everyone to use GitHub as a strong preference.
3. In this separate section, include two email addresses using plus-syntax
to incorporate a hash (e.g. SHA1) in the email address (
perlbug+hashvalue@perl.org) -- one based on a hash of the sender's email
address (envelope sender?  From?  Reply-To?  All of these?), and the other
based on a hash of the Subject line of the bug report, or perhaps a key
string generated by the "perlbug" script which is in the body of the
email.  The sender-based address could be used (and reused) by someone who
is philosophically opposed to making a GitHub account, but doesn't care
about anonymity, and the other address could be used for true anonymous
submissions.
4. The bug reporter would need to reply/resend/forward the bug report to
either of these plus-syntax addresses.
5. When the auto-responder receives an email using the plus-syntax, it can
verify the hash and send the bug report to a GitHub gateway to create the
issue automatically, or send the normal auto-response if the hash isn't
valid.
6. For convenience, the "perlbug" script could generate the hash and send
the bug report to the correct plus-syntax address, but spammers could then
abuse the script.

This process alone would probably defeat most spammers, since they usually
send spam from undeliverable or innocent addresses, so there's a good
chance spam wouldn't become a problem in the first place.  If it does,
there are a number of hurdles that could be added to discourage spammers --
some of which would discourage the bug reporter as well:

Possible additional hurdles that come to mind offhand:

* Manual moderation is an option, of course, but not an appealing one.  It
might be okay if the automated system catches 99.99% of spam attempts.  It
would probably help if senders who pass manual moderation once are
automatically added to a whitelist by default.
* Rather than including the plus-syntax email addresses in the reply
directly, provide only the hash values with English prose describing how to
create the plus-syntax email address from those hash values.
* Require an authentication key of some sort generated by the "perlbug"
script, which could be required in the Subject line and/or body of the
email.  This could involve a hash like the plus-syntax addresses, using
some "secret" key as a salt.  Obviously, this could be reverse-engineered
from the script, but how many spammers would even try?
* Don't mention the plus-syntax addresses in the auto-response at all, and
have it documented elsewhere, with instructions for generating the correct
hash using Perl.  However, this would tend to discourage bug reporters as
well as spammers.
* Require PGP/GPG-signed messages for bug reports via email.  This would
again discourage bug reporters as well as spammers.

I'm not sure how much need there is for anonymous submissions though.
Personally, I'll be happy to use my GitHub account to submit issues, but
obviously there are some people who are opposed to using GitHub.

Deven

--0000000000005ab33a058d7f5413
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jul 11, 2019 at 7:00 AM Nicholas =
Clark &lt;<a href=3D"mailto:nick@ccl4.org">nick@ccl4.org</a>&gt; wrote:<br>=
</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:<br>
<br>
&gt; The problem with anonymous ticket submission is that it inevitably<br>
&gt; becomes a spam target. You can of course get rid of much of the bad<br=
>
&gt; traffic with filtering. However you are still left with processes that=
<br>
&gt; are fragile and/or overly dependent on humans.<br>
<br>
Technically you can still &quot;anonymously&quot; submit bug reports (or wi=
thout an<br>
account), because you can still mail them direct to the list. It just won&#=
39;t<br>
get into the issue tracker that way :-/<br></blockquote><div><br></div><div=
>I can imagine a solution which primarily uses GitHub, while preserving the=
 ability to submit anonymous bug reports:</div><div><br></div><div>1. Email=
 sent to &lt;<a href=3D"mailto:perlbug@perl.org">perlbug@perl.org</a>&gt; i=
s handled by an auto-responder, as planned.</div><div>2. The auto-responder=
 sends a response containing GitHub instructions and a separate section exp=
laining how to submit the bug without using GitHub -- while encouraging eve=
ryone to use GitHub as a strong preference.</div><div>3. In this separate s=
ection, include two email addresses using plus-syntax to incorporate a hash=
 (e.g. SHA1) in the email address (<a href=3D"mailto:perlbug%2Bhashvalue@pe=
rl.org">perlbug+hashvalue@perl.org</a>) -- one based on a hash of the sende=
r&#39;s email address (envelope sender?=C2=A0 From?=C2=A0 Reply-To?=C2=A0 A=
ll of these?), and the other based on a hash of the Subject line of the bug=
 report, or perhaps a key string generated by the &quot;perlbug&quot; scrip=
t which is in the body of the email.=C2=A0 The sender-based address could b=
e used (and reused) by someone who is philosophically opposed to making a G=
itHub account, but doesn&#39;t care about anonymity, and the other address =
could be used for true anonymous submissions.</div><div>4. The bug reporter=
 would need to reply/resend/forward the bug report to either of these plus-=
syntax addresses.</div><div>5. When the auto-responder receives an email us=
ing the plus-syntax, it can verify the hash and send the bug report to a Gi=
tHub gateway to create the issue automatically, or send the normal auto-res=
ponse if the hash isn&#39;t valid.</div><div>6. For convenience, the &quot;=
perlbug&quot; script could generate the hash and send the bug report to the=
 correct plus-syntax address, but spammers could then abuse the script.</di=
v><div><br></div><div>This process alone would probably defeat most spammer=
s, since they usually send spam from undeliverable or innocent addresses, s=
o there&#39;s a good chance spam wouldn&#39;t become a problem in the first=
 place.=C2=A0 If it does, there are a number of hurdles that could be added=
 to discourage spammers -- some of which would discourage the bug reporter =
as well:</div><div><br></div><div>Possible additional hurdles that come to =
mind offhand:</div><div><br></div><div>* Manual moderation is an option, of=
 course, but not an appealing one.=C2=A0 It might be okay if the automated =
system catches 99.99% of spam attempts.=C2=A0 It would probably help if sen=
ders who pass manual moderation once are automatically added to a whitelist=
 by default.<br></div><div>* Rather than including the plus-syntax email ad=
dresses in the reply directly, provide only the hash values with English pr=
ose describing how to create the plus-syntax email address from those hash =
values.</div><div>* Require an authentication key of some sort generated by=
 the &quot;perlbug&quot; script, which could be required in the Subject lin=
e and/or body of the email.=C2=A0 This could involve a hash like the plus-s=
yntax addresses, using some &quot;secret&quot; key as a salt.=C2=A0 Obvious=
ly, this could be reverse-engineered from the script, but how many spammers=
 would even try?</div><div>* Don&#39;t mention the plus-syntax addresses in=
 the auto-response at all, and have it documented elsewhere, with instructi=
ons for generating the correct hash using Perl.=C2=A0 However, this would t=
end to discourage bug reporters as well as spammers.</div><div>* Require PG=
P/GPG-signed messages for bug reports via email.=C2=A0 This would again dis=
courage bug reporters as well as spammers.</div><div><br></div><div>I&#39;m=
 not sure how much need there is for anonymous submissions though.=C2=A0 Pe=
rsonally, I&#39;ll be happy to use my GitHub account to submit issues, but =
obviously there are some people who are opposed to using GitHub.</div><div>=
<br></div><div>Deven</div><div><br></div></div></div>

--0000000000005ab33a058d7f5413--
0
deven
7/12/2019 5:34:22 PM
--000000000000bfe8a5058d7f7af0
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 11, 2019 at 7:00 AM Nicholas Clark <nick@ccl4.org> wrote:

> On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:
>
> > A: We believe that GitHub is going to be around for a long time. It has
>
> Which, with hindsight, could not have been said last year. I had no idea
> how much money it was losing until all the news about the sale.


[...]

> Q: What about perl5.git.perl.org?
> >
> > A: It will be made a mirror of https://github.com/Perl/perl5and may be
> > retired at a future date based on usage.
>

In my opinion, there should *always* be a "canonical" mirror of the main
GitHub repository which is kept as current as possible, regardless of how
little it might be used.  This would serve as an "insurance policy" against
catastrophic loss, whether that's an unfathomable failure of GitHub's
systems (highly unlikely), a total and complete unexpected shutdown as a
result of a business decision (more plausible, if it's losing money, but
hopefully unlikely) or GitHub suddenly "turning evil" in some fashion
(seems unlikely at the moment, but very possible if Microsoft were to do
another 180 on Open Source/Linux/etc.) -- none of these things seem (at
least to me) to be particularly likely to happen, but it's still better not
to have all our eggs in one basket...

Of course, even without a canonical mirror, there would still be many
developers with copies of the full repository simply due to git's design,
so that's good.

Deven

--000000000000bfe8a5058d7f7af0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jul 11, 2019 at 7:00 AM Nicholas =
Clark &lt;<a href=3D"mailto:nick@ccl4.org">nick@ccl4.org</a>&gt; wrote:<br>=
</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:<br><br>
&gt; A: We believe that GitHub is going to be around for a long time. It ha=
s<br>
<br>
Which, with hindsight, could not have been said last year. I had no idea<br=
>
how much money it was losing until all the news about the sale.</blockquote=
><div><br></div><div>[...]</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">&gt; Q: What about <a href=3D"http://perl5.git.perl.o=
rg" rel=3D"noreferrer" target=3D"_blank">perl5.git.perl.org</a>?<br>
&gt; <br>
&gt; A: It will be made a mirror of <a href=3D"https://github.com/Perl/perl=
5and" rel=3D"noreferrer" target=3D"_blank">https://github.com/Perl/perl5and=
</a> may be<br>
&gt; retired at a future date based on usage.<br></blockquote><div><br></di=
v><div>In my=C2=A0opinion, there should *always* be a &quot;canonical&quot;=
 mirror of the main GitHub repository which is kept as current as possible,=
 regardless of how little it might be used.=C2=A0 This would serve as an &q=
uot;insurance policy&quot; against catastrophic loss, whether that&#39;s an=
 unfathomable failure of GitHub&#39;s systems (highly unlikely), a total an=
d complete unexpected shutdown as a result of a business decision (more pla=
usible, if it&#39;s losing money, but hopefully unlikely) or GitHub suddenl=
y &quot;turning evil&quot; in some fashion (seems unlikely at the moment, b=
ut very possible if Microsoft were to do another 180 on Open Source/Linux/e=
tc.) -- none of these things seem (at least to me) to be particularly likel=
y to happen, but it&#39;s still better not to have all our eggs in one bask=
et...</div><div><br></div><div>Of course, even without a canonical mirror, =
there would still be many developers with copies of the full repository sim=
ply due to git&#39;s design, so that&#39;s good.</div><div><br></div><div>D=
even</div><div><br></div></div></div>

--000000000000bfe8a5058d7f7af0--
0
deven
7/12/2019 5:45:07 PM
--0000000000009c6644058d7f8e01
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 12, 2019 at 1:14 PM Craig A. Berry <craig.a.berry@gmail.com>
wrote:

> On Fri, Jul 12, 2019 at 10:08 AM Dan Book <grinnz@gmail.com> wrote:
> >
> > On Fri, Jul 12, 2019 at 10:52 AM Craig A. Berry <craig.a.berry@gmail.com>
> wrote:
>
> >> +1.  I really loathe the most common GitHub workflow where the commit
> >> history consists almost entirely of "Merge pull request #1234 from
> >> somebody/somebranch/about...<cut off>" which is devoid of relevant
> >> content
> >
> >
> > As I mentioned previously, the rebase option for merging PRs is
> available.
>
> Yes, I'm aware it's possible.  Just adding my voice to those saying
> it's important to keep doing things this way.
>

GitHub allows the repository to be configured to lock down the choices.  It
can be configured to disallow merge commits entirely, and I would highly
recommend doing this.  (Especially since many developers probably hate
and/or fear rebase and would *always* use merge commits if given the
option.)

Administrators could override the block and merge a PR instead of rebasing,
but hopefully this would only be done for a compelling reason.

Deven

--0000000000009c6644058d7f8e01
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jul 12, 2019 at 1:14 PM Craig A. =
Berry &lt;<a href=3D"mailto:craig.a.berry@gmail.com">craig.a.berry@gmail.co=
m</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">On Fri, Jul 12, 2019 at 10:08 AM Dan Book &lt;<=
a href=3D"mailto:grinnz@gmail.com" target=3D"_blank">grinnz@gmail.com</a>&g=
t; wrote:<br>
&gt;<br>
&gt; On Fri, Jul 12, 2019 at 10:52 AM Craig A. Berry &lt;<a href=3D"mailto:=
craig.a.berry@gmail.com" target=3D"_blank">craig.a.berry@gmail.com</a>&gt; =
wrote:<br>
<br>
&gt;&gt; +1.=C2=A0 I really loathe the most common GitHub workflow where th=
e commit<br>
&gt;&gt; history consists almost entirely of &quot;Merge pull request #1234=
 from<br>
&gt;&gt; somebody/somebranch/about...&lt;cut off&gt;&quot; which is devoid =
of relevant<br>
&gt;&gt; content<br>
&gt;<br>
&gt;<br>
&gt; As I mentioned previously, the rebase option for merging PRs is availa=
ble.<br>
<br>
Yes, I&#39;m aware it&#39;s possible.=C2=A0 Just adding my voice to those s=
aying<br>
it&#39;s important to keep doing things this way.<br></blockquote><div><br>=
</div><div>GitHub allows the repository to be configured to lock down the c=
hoices.=C2=A0 It can be configured to disallow merge commits entirely, and =
I would highly recommend doing this.=C2=A0 (Especially since many developer=
s probably hate and/or fear rebase and would *always* use merge commits if =
given the option.)</div><div><br></div><div>Administrators could override t=
he block and merge a PR instead of rebasing, but hopefully this would only =
be done for a compelling reason.</div><div><br></div><div>Deven</div><div><=
br></div></div></div>

--0000000000009c6644058d7f8e01--
0
deven
7/12/2019 5:50:40 PM
--00000000000001110d058d7fa364
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 11, 2019 at 7:00 AM Nicholas Clark <nick@ccl4.org> wrote:

> On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:
>
> > Q: Will all ticket updates be sent to the list as before?
> >
> > A: Only the initial ticket creation will show up on the list. This will
> > give you the ability to monitor only the issues you care about. You can
> > also monitor the whole project on GitHub to get all updates by simply
> > setting watch as you see fit in GitHub.
> >
> >
> > Updates will be received based on monitoring the person chooses or when
> > said person is explicitly mentioned. You may choose to monitor
> > everything (what we call the =E2=80=9Cfirehose mode=E2=80=9D), as curre=
ntly on the p5p
> > mailing list.
>
> Not that I've been active recently, but personally this change is somethi=
ng
> that saddens me. I had always felt that it was useful that the main
> development forum was not decoupled from the nitty-gritty of
>
> 1) actually fixing stuff (ie graft, not just ideas)
> 2) the implications of changes (ie what turned out to break, what it real=
ly
>    cost)
>
>
> Also, it's really useful that mail readers are threaded. (I think RT is
> too).
> It's much easier to follow complex discussions in a threaded view, instea=
d
> of
> a forced-sorted-by-time flat view.
>

Between this and Jim Keenan's observations about NNTP, it seems there's
value in the "firehose" mode -- could it be kept, perhaps in a new mailing
list/NNTP group?

Also, doesn't "watching" an issue require a GitHub account?  Some people
are philisophically opposed to creating an account -- they would likely
value the firehose too...

Deven

--00000000000001110d058d7fa364
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jul 11, 2019 at 7:00 AM Nicholas =
Clark &lt;<a href=3D"mailto:nick@ccl4.org">nick@ccl4.org</a>&gt; wrote:<br>=
</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:<br>
<br>&gt; Q: Will all ticket updates be sent to the list as before?<br>
&gt; <br>
&gt; A: Only the initial ticket creation will show up on the list. This wil=
l<br>
&gt; give you the ability to monitor only the issues you care about. You ca=
n<br>
&gt; also monitor the whole project on GitHub to get all updates by simply<=
br>
&gt; setting watch as you see fit in GitHub.<br>
&gt; <br>
&gt; <br>
&gt; Updates will be received based on monitoring the person chooses or whe=
n<br>
&gt; said person is explicitly mentioned. You may choose to monitor<br>
&gt; everything (what we call the =E2=80=9Cfirehose mode=E2=80=9D), as curr=
ently on the p5p<br>
&gt; mailing list.<br>
<br>
Not that I&#39;ve been active recently, but personally this change is somet=
hing<br>
that saddens me. I had always felt that it was useful that the main<br>
development forum was not decoupled from the nitty-gritty of<br>
<br>
1) actually fixing stuff (ie graft, not just ideas)<br>
2) the implications of changes (ie what turned out to break, what it really=
<br>
=C2=A0 =C2=A0cost)<br>
<br>
<br>
Also, it&#39;s really useful that mail readers are threaded. (I think RT is=
 too).<br>
It&#39;s much easier to follow complex discussions in a threaded view, inst=
ead of<br>
a forced-sorted-by-time flat view.<br></blockquote><div><br></div><div>Betw=
een this and Jim Keenan&#39;s observations about NNTP, it seems there&#39;s=
 value in the &quot;firehose&quot; mode -- could it be kept, perhaps in a n=
ew mailing list/NNTP group?</div><div><br></div><div>Also, doesn&#39;t &quo=
t;watching&quot; an issue require a GitHub account?=C2=A0 Some people are p=
hilisophically opposed to creating an account -- they would likely value th=
e firehose too...</div><div><br></div><div>Deven</div><div><br></div></div>=
</div>

--00000000000001110d058d7fa364--
0
deven
7/12/2019 5:56:21 PM
--000000000000d96b5c058d7fc52a
Content-Type: text/plain; charset="UTF-8"

I realize that "blead" has been used for many years and is traditional for
Perl development.  At the same time, it's also out of step with typical Git
conventions and potentially confusing to new developers who might want to
contribute to Perl.

With this move to GitHub, should we consider retiring "blead" as a
historical anachronism and rename the default branch to "master" as most
Git users expect, or continue with "blead" to honor tradition?

Personally, I do like sticking with tradition -- yet I still tend to lean
towards renaming to "master" anyhow, to be more consistent with
expectations of those who aren't steeped in years of Perl tradition.  (We
want to be inviting and accessible for new people, don't we?)

Deven

--000000000000d96b5c058d7fc52a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I realize that &quot;blead&quot; has been used for many=C2=
=A0years and is traditional for Perl development.=C2=A0 At the same time, i=
t&#39;s also out of step with typical Git conventions and potentially confu=
sing to new developers who might want to contribute to Perl.<div><br></div>=
<div>With this move to GitHub, should we consider retiring &quot;blead&quot=
; as a historical anachronism and rename the default branch to &quot;master=
&quot; as most Git users expect, or continue with &quot;blead&quot; to hono=
r tradition?</div><div><br></div><div>Personally, I do like sticking with t=
radition -- yet I still tend to lean towards renaming to &quot;master&quot;=
 anyhow, to be more consistent with expectations of those who aren&#39;t st=
eeped in years of Perl tradition.=C2=A0 (We want to be inviting and accessi=
ble for new people, don&#39;t we?)</div><div><br></div><div>Deven</div><div=
><br></div></div>

--000000000000d96b5c058d7fc52a--
0
deven
7/12/2019 6:06:07 PM
On Fri, 12 Jul 2019, at 20:07, Deven T. Corzine wrote:
> I realize that "blead" has been used for many years and is traditional for Perl development. At the same time, it's also out of step with typical Git conventions and potentially confusing to new developers who might want to contribute to Perl.
> 
> With this move to GitHub, should we consider retiring "blead" as a historical anachronism and rename the default branch to "master" as most Git users expect, or continue with "blead" to honor tradition?
> 
> Personally, I do like sticking with tradition -- yet I still tend to lean towards renaming to "master" anyhow, to be more consistent with expectations of those who aren't steeped in years of Perl tradition. (We want to be inviting and accessible for new people, don't we?)
> 
> Deven
> 

I don't think we would gain anything from that.

Github's UI fully supports having a different main branch name, so most
newcommers will probably not even notice that its name is different.
The name doesn't change anything in the typical pull request workflow.
0
me
7/12/2019 8:33:15 PM
--000000000000209a50058d81f95b
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 12, 2019 at 4:33 PM Tomasz Konojacki <me@xenu.pl> wrote:

> On Fri, 12 Jul 2019, at 20:07, Deven T. Corzine wrote:
> > I realize that "blead" has been used for many years and is traditional
> for Perl development. At the same time, it's also out of step with typical
> Git conventions and potentially confusing to new developers who might want
> to contribute to Perl.
> >
> > With this move to GitHub, should we consider retiring "blead" as a
> historical anachronism and rename the default branch to "master" as most
> Git users expect, or continue with "blead" to honor tradition?
> >
> > Personally, I do like sticking with tradition -- yet I still tend to
> lean towards renaming to "master" anyhow, to be more consistent with
> expectations of those who aren't steeped in years of Perl tradition. (We
> want to be inviting and accessible for new people, don't we?)
> >
> > Deven
> >
>
> I don't think we would gain anything from that.
>

There's no gain for current Perl developers, and for them, changing it
would be a minor nuisance in the short term.  The gain would be to
eliminate a potential source of confusion for new developers interested in
contributing.  They have to *learn* that "blead" means to Perl what
"master" means to Git.  It's the default branch, but people can still get
confused as to what "blead" means and why "master" doesn't exist in the
repo.


> Github's UI fully supports having a different main branch name, so most
> newcommers will probably not even notice that its name is different.
> The name doesn't change anything in the typical pull request workflow.
>

Of course there's no barriers to continuing to use "blead".  That wasn't
the point.  The question is whether it might be worthwhile to endure the
nuisance of making a change to a more "normal" Git repository with "master"
as the default branch, or do we just keep using "blead" because we're been
using it forever.  That's the path of least resistance, but if we ever want
to change it, now would be an opportune time... or we can just agree to
continue using "blead" for the foreseeable future and let the newbies just
deal with it as they've always had to.

Deven

--000000000000209a50058d81f95b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jul 12, 2019 at 4:33 PM Tomasz Ko=
nojacki &lt;<a href=3D"mailto:me@xenu.pl">me@xenu.pl</a>&gt; wrote:<br></di=
v><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">On Fri, 12 Jul 2019, at 20:07, Deven T. Corzine wrote:<br>
&gt; I realize that &quot;blead&quot; has been used for many years and is t=
raditional for Perl development. At the same time, it&#39;s also out of ste=
p with typical Git conventions and potentially confusing to new developers =
who might want to contribute to Perl.<br>
&gt; <br>
&gt; With this move to GitHub, should we consider retiring &quot;blead&quot=
; as a historical anachronism and rename the default branch to &quot;master=
&quot; as most Git users expect, or continue with &quot;blead&quot; to hono=
r tradition?<br>
&gt; <br>
&gt; Personally, I do like sticking with tradition -- yet I still tend to l=
ean towards renaming to &quot;master&quot; anyhow, to be more consistent wi=
th expectations of those who aren&#39;t steeped in years of Perl tradition.=
 (We want to be inviting and accessible for new people, don&#39;t we?)<br>
&gt; <br>
&gt; Deven<br>
&gt; <br>
<br>
I don&#39;t think we would gain anything from that.<br></blockquote><div><b=
r></div><div>There&#39;s no gain for current Perl developers, and for them,=
 changing it would be a minor nuisance in the short term.=C2=A0 The gain wo=
uld be to eliminate a potential source of confusion for new developers inte=
rested in contributing.=C2=A0 They have to *learn* that &quot;blead&quot; m=
eans to Perl what &quot;master&quot; means to Git.=C2=A0 It&#39;s the defau=
lt branch, but people can still get confused as to what &quot;blead&quot; m=
eans and why &quot;master&quot; doesn&#39;t exist in the repo.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Github&#39;s UI fully supports having a different main branch name, so most=
<br>
newcommers will probably not even notice that its name is different.<br>
The name doesn&#39;t change anything in the typical pull request workflow.<=
br></blockquote><div><br></div><div>Of course there&#39;s no barriers to co=
ntinuing to use &quot;blead&quot;.=C2=A0 That wasn&#39;t the point.=C2=A0 T=
he question is whether it might be worthwhile to endure the nuisance of mak=
ing a change to a more &quot;normal&quot; Git repository with &quot;master&=
quot; as the default branch, or do we just keep using &quot;blead&quot; bec=
ause we&#39;re been using it forever.=C2=A0 That&#39;s the path of least re=
sistance, but if we ever want to change it, now would be an opportune time.=
... or we can just agree to continue using &quot;blead&quot; for the foresee=
able future and let the newbies just deal with it as they&#39;ve always had=
 to.</div><div><br></div><div>Deven</div><div><br></div></div></div>

--000000000000209a50058d81f95b--
0
deven
7/12/2019 8:43:37 PM
On Fri, Jul 12, 2019 at 8:06 PM Deven T. Corzine <deven@ties.org> wrote:
>
> I realize that "blead" has been used for many years and is traditional fo=
r Perl development.  At the same time, it's also out of step with typical G=
it conventions and potentially confusing to new developers who might want t=
o contribute to Perl.
>
> With this move to GitHub, should we consider retiring "blead" as a histor=
ical anachronism and rename the default branch to "master" as most Git user=
s expect, or continue with "blead" to honor tradition?
>
> Personally, I do like sticking with tradition -- yet I still tend to lean=
 towards renaming to "master" anyhow, to be more consistent with expectatio=
ns of those who aren't steeped in years of Perl tradition.  (We want to be =
inviting and accessible for new people, don't we?)

Almost all git repository have a master branch, but that doesn't mean
it always means the same. Most importantly: does master mean
"production branch" or "development branch". In my head it means the
former, but given that we have a maintenance branch for every stable
release the former doesn't seem like a good fit. You are suggesting
the latter, which I have seen before but always felt wrong to me.

I would argue for keeping it as it is. It's fine for the name to be
different from most git projects, because our whole setup is different
from most git projects


Leon
0
fawaka
7/12/2019 9:27:46 PM
--000000000000c8caed058d82b893
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 12, 2019 at 2:06 PM Deven T. Corzine <deven@ties.org> wrote:

> I realize that "blead" has been used for many years and is traditional for
> Perl development.  At the same time, it's also out of step with typical Git
> conventions and potentially confusing to new developers who might want to
> contribute to Perl.
>
> With this move to GitHub, should we consider retiring "blead" as a
> historical anachronism and rename the default branch to "master" as most
> Git users expect, or continue with "blead" to honor tradition?
>
> Personally, I do like sticking with tradition -- yet I still tend to lean
> towards renaming to "master" anyhow, to be more consistent with
> expectations of those who aren't steeped in years of Perl tradition.  (We
> want to be inviting and accessible for new people, don't we?)
>
>
While I respect the intent of cleanliness and consistency, in this case I
think there is realistically no benefit and lots of difficult parts. As one
example the perl-build and perlbrew tools mentioned in the other thread
rely on the branch being called blead to start with. As long as you set the
default branch of a repository to the one you want people to work against,
and you don't have a random 'master' branch that isn't default, there are
no practical issues for contributors, in my experience.

-Dan

--000000000000c8caed058d82b893
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jul 12, 2019 at 2:06 PM Deven T. =
Corzine &lt;<a href=3D"mailto:deven@ties.org">deven@ties.org</a>&gt; wrote:=
<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr">I realize that &quot;blead&quot; has been used=
 for many=C2=A0years and is traditional for Perl development.=C2=A0 At the =
same time, it&#39;s also out of step with typical Git conventions and poten=
tially confusing to new developers who might want to contribute to Perl.<di=
v><br></div><div>With this move to GitHub, should we consider retiring &quo=
t;blead&quot; as a historical anachronism and rename the default branch to =
&quot;master&quot; as most Git users expect, or continue with &quot;blead&q=
uot; to honor tradition?</div><div><br></div><div>Personally, I do like sti=
cking with tradition -- yet I still tend to lean towards renaming to &quot;=
master&quot; anyhow, to be more consistent with expectations of those who a=
ren&#39;t steeped in years of Perl tradition.=C2=A0 (We want to be inviting=
 and accessible for new people, don&#39;t we?)</div><div><br></div></div></=
blockquote><div><br></div><div>While I respect the intent of cleanliness an=
d consistency, in this case I think there is realistically no benefit and l=
ots of difficult parts. As one example the perl-build and perlbrew tools me=
ntioned in the other thread rely on the branch being called blead to start =
with. As long as you set the default branch of a repository to the one you =
want people to work against, and you don&#39;t have a random &#39;master&#3=
9; branch that isn&#39;t default, there are no practical issues for contrib=
utors, in my experience.</div><div><br></div><div>-Dan=C2=A0</div></div></d=
iv>

--000000000000c8caed058d82b893--
0
grinnz
7/12/2019 9:37:37 PM
--00000000000082b452058d82c812
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 12, 2019 at 5:37 PM Dan Book <grinnz@gmail.com> wrote:

> While I respect the intent of cleanliness and consistency, in this case I
> think there is realistically no benefit and lots of difficult parts. As one
> example the perl-build and perlbrew tools mentioned in the other thread
> rely on the branch being called blead to start with. As long as you set the
> default branch of a repository to the one you want people to work against,
> and you don't have a random 'master' branch that isn't default, there are
> no practical issues for contributors, in my experience.
>

Fair enough.  I'm not lobbying for it, just bought it up in case it was
worth considering.

Deven

--00000000000082b452058d82c812
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jul 12, 2019 at 5:37 PM Dan Book =
&lt;<a href=3D"mailto:grinnz@gmail.com">grinnz@gmail.com</a>&gt; wrote:<br>=
</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div dir=3D"ltr">While I respect the intent of cle=
anliness and consistency, in this case I think there is realistically no be=
nefit and lots of difficult parts. As one example the perl-build and perlbr=
ew tools mentioned in the other thread rely on the branch being called blea=
d to start with. As long as you set the default branch of a repository to t=
he one you want people to work against, and you don&#39;t have a random &#3=
9;master&#39; branch that isn&#39;t default, there are no practical issues =
for contributors, in my experience.</div></div></blockquote><div><br></div>=
<div>Fair enough.=C2=A0 I&#39;m not lobbying for it, just bought it up in c=
ase it was worth considering.</div><div><br></div><div>Deven</div><div>=C2=
=A0</div></div></div>

--00000000000082b452058d82c812--
0
deven
7/12/2019 9:41:37 PM
--00000000000008f12d058d8dda13
Content-Type: text/plain; charset="UTF-8"

On Fri, 12 Jul 2019, 16:55 Craig A. Berry, <craig.a.berry@gmail.com> wrote:

> On Wed, Jul 10, 2019 at 5:35 AM demerphq <demerphq@gmail.com> wrote:
> >
> > On Tue, 9 Jul 2019 at 07:23, Dan Book <grinnz@gmail.com> wrote:
> > >
> > > On Mon, Jul 8, 2019 at 6:45 PM Sawyer X <xsawyerx@gmail.com> wrote:
> > >>
> > >> Q: What else needs doing?
> > >>
> > >> A: We need to know about any existing integration with RT or perl5's
> > >> existing git repo. If you know of something, please let us know so it
> > >> can be accommodated during the migration.
> > >
> > >
> > > perl-build (
> https://metacpan.org/release/Perl-Build/source/script/perl-build#L67) and
> perlbrew (https://metacpan.org/source/App::perlbrew#L1414) both download
> blead snapshots when requested from
> https://perl5.git.perl.org/perl.git/snapshot/blead.tar.gz - this should
> be forwarded to https://github.com/Perl/perl5/archive/blead.tar.gz .
> Perlbrew calls it from HTTP, but it uses curl/wget so a redirect to HTTPS
> should not cause issues.
> >
> > I think in practice *this* is going to be one of the bigger
> > challenges. We had to hack the git page to support producing the
> > correct tarball with the correct contents. (Specifically we inject a
> > file into the tarball that is not contained in the repository) My bet
> > is that out of the box github will not be able to support our use
> > case.
>
> I think you are right.  I have poked around a bit to see if any
> server-side scripting is available on GitHub and so far the answer
> seems to be no.  So we have no way to include git_version.h in a
> tarball or zipball downloaded from GitHub.
>

I am concerned there isn't more reaction to this, it seems to me to be a
showstopper.

Yves

--00000000000008f12d058d8dda13
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Fri, 12 Jul 2019, 16:55 Craig A. Berry, &lt;<a href=3D"mail=
to:craig.a.berry@gmail.com">craig.a.berry@gmail.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">On Wed, Jul 10, 2019 at 5:35 AM demerphq &l=
t;<a href=3D"mailto:demerphq@gmail.com" target=3D"_blank" rel=3D"noreferrer=
">demerphq@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Tue, 9 Jul 2019 at 07:23, Dan Book &lt;<a href=3D"mailto:grinnz@gma=
il.com" target=3D"_blank" rel=3D"noreferrer">grinnz@gmail.com</a>&gt; wrote=
:<br>
&gt; &gt;<br>
&gt; &gt; On Mon, Jul 8, 2019 at 6:45 PM Sawyer X &lt;<a href=3D"mailto:xsa=
wyerx@gmail.com" target=3D"_blank" rel=3D"noreferrer">xsawyerx@gmail.com</a=
>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Q: What else needs doing?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; A: We need to know about any existing integration with RT or =
perl5&#39;s<br>
&gt; &gt;&gt; existing git repo. If you know of something, please let us kn=
ow so it<br>
&gt; &gt;&gt; can be accommodated during the migration.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; perl-build (<a href=3D"https://metacpan.org/release/Perl-Build/so=
urce/script/perl-build#L67" rel=3D"noreferrer noreferrer" target=3D"_blank"=
>https://metacpan.org/release/Perl-Build/source/script/perl-build#L67</a>) =
and perlbrew (<a href=3D"https://metacpan.org/source/App::perlbrew#L1414" r=
el=3D"noreferrer noreferrer" target=3D"_blank">https://metacpan.org/source/=
App::perlbrew#L1414</a>) both download blead snapshots when requested from =
<a href=3D"https://perl5.git.perl.org/perl.git/snapshot/blead.tar.gz" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://perl5.git.perl.org/per=
l.git/snapshot/blead.tar.gz</a> - this should be forwarded to <a href=3D"ht=
tps://github.com/Perl/perl5/archive/blead.tar.gz" rel=3D"noreferrer norefer=
rer" target=3D"_blank">https://github.com/Perl/perl5/archive/blead.tar.gz</=
a> . Perlbrew calls it from HTTP, but it uses curl/wget so a redirect to HT=
TPS should not cause issues.<br>
&gt;<br>
&gt; I think in practice *this* is going to be one of the bigger<br>
&gt; challenges. We had to hack the git page to support producing the<br>
&gt; correct tarball with the correct contents. (Specifically we inject a<b=
r>
&gt; file into the tarball that is not contained in the repository) My bet<=
br>
&gt; is that out of the box github will not be able to support our use<br>
&gt; case.<br>
<br>
I think you are right.=C2=A0 I have poked around a bit to see if any<br>
server-side scripting is available on GitHub and so far the answer<br>
seems to be no.=C2=A0 So we have no way to include git_version.h in a<br>
tarball or zipball downloaded from GitHub.<br></blockquote></div></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">I am concerned there isn&#39;t mo=
re reaction to this, it seems to me to be a showstopper.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Yves</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
</blockquote></div></div></div>

--00000000000008f12d058d8dda13--
0
demerphq
7/13/2019 10:54:19 AM
On Wed, 10 Jul 2019, demerphq wrote:

> I think in practice *this* is going to be one of the bigger
> challenges. We had to hack the git page to support producing the
> correct tarball with the correct contents. (Specifically we inject a
> file into the tarball that is not contained in the repository) My bet
> is that out of the box github will not be able to support our use
> case.

FWIW, for libyaml we also had to find a way to let people download
distribution tarballs.
If you build from git, you need to bootstrap. If you download the
distribution tarball, you don't.

For that, we create the tarball and put the contents into the 'dist'
branch and tag it.
So people can download the tarballs prefixed with 'dist-' here:
https://github.com/yaml/libyaml/releases

cheers,
tina
0
post
7/13/2019 12:33:21 PM
On Sat, Jul 13, 2019 at 8:07 AM Tina M=C3=BCller <post@tinita.de> wrote:
>
> On Wed, 10 Jul 2019, demerphq wrote:
>
> > I think in practice *this* is going to be one of the bigger
> > challenges. We had to hack the git page to support producing the
> > correct tarball with the correct contents. (Specifically we inject a
> > file into the tarball that is not contained in the repository) My bet
> > is that out of the box github will not be able to support our use
> > case.
>
> FWIW, for libyaml we also had to find a way to let people download
> distribution tarballs.
> If you build from git, you need to bootstrap. If you download the
> distribution tarball, you don't.
>
> For that, we create the tarball and put the contents into the 'dist'
> branch and tag it.
> So people can download the tarballs prefixed with 'dist-' here:
> https://github.com/yaml/libyaml/releases

That's a good solution for a release tarball.  What Yves is talking
about is the tarball that has the git describe output embedded for any
random commit, i.e., what you get when you click the "snapshot" link
next to any commit in our current gitweb interface.  This is based on
running:

$ perl Porting/make_dot_patch.pl > .patch

in a git checkout *before* generating the tarball.  This allows the
downloader to build without having git installed.  I think some
Test::Smoke configurations depend on that.
0
craig
7/13/2019 1:38:39 PM
--000000000000da758b058d91097c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 13 Jul 2019, 15:38 Craig A. Berry, <craig.a.berry@gmail.com> wrote:

> On Sat, Jul 13, 2019 at 8:07 AM Tina M=C3=BCller <post@tinita.de> wrote:
> >
> > On Wed, 10 Jul 2019, demerphq wrote:
> >
> > > I think in practice *this* is going to be one of the bigger
> > > challenges. We had to hack the git page to support producing the
> > > correct tarball with the correct contents. (Specifically we inject a
> > > file into the tarball that is not contained in the repository) My bet
> > > is that out of the box github will not be able to support our use
> > > case.
> >
> > FWIW, for libyaml we also had to find a way to let people download
> > distribution tarballs.
> > If you build from git, you need to bootstrap. If you download the
> > distribution tarball, you don't.
> >
> > For that, we create the tarball and put the contents into the 'dist'
> > branch and tag it.
> > So people can download the tarballs prefixed with 'dist-' here:
> > https://github.com/yaml/libyaml/releases
>
> That's a good solution for a release tarball.  What Yves is talking
> about is the tarball that has the git describe output embedded for any
> random commit, i.e., what you get when you click the "snapshot" link
> next to any commit in our current gitweb interface.  This is based on
> running:
>
> $ perl Porting/make_dot_patch.pl > .patch
>
> in a git checkout *before* generating the tarball.  This allows the
> downloader to build without having git installed.  I think some
> Test::Smoke configurations depend on that.
>

Well, actually we add it to the tarball after git has created it but that
is just an implementation detail, the end result is the same.

Yves

>

--000000000000da758b058d91097c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Sat, 13 Jul 2019, 15:38 Craig A. Berry, &lt;<a href=
=3D"mailto:craig.a.berry@gmail.com">craig.a.berry@gmail.com</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">On Sat, Jul 13, 2019 at 8:07 AM Tin=
a M=C3=BCller &lt;<a href=3D"mailto:post@tinita.de" target=3D"_blank" rel=
=3D"noreferrer">post@tinita.de</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wed, 10 Jul 2019, demerphq wrote:<br>
&gt;<br>
&gt; &gt; I think in practice *this* is going to be one of the bigger<br>
&gt; &gt; challenges. We had to hack the git page to support producing the<=
br>
&gt; &gt; correct tarball with the correct contents. (Specifically we injec=
t a<br>
&gt; &gt; file into the tarball that is not contained in the repository) My=
 bet<br>
&gt; &gt; is that out of the box github will not be able to support our use=
<br>
&gt; &gt; case.<br>
&gt;<br>
&gt; FWIW, for libyaml we also had to find a way to let people download<br>
&gt; distribution tarballs.<br>
&gt; If you build from git, you need to bootstrap. If you download the<br>
&gt; distribution tarball, you don&#39;t.<br>
&gt;<br>
&gt; For that, we create the tarball and put the contents into the &#39;dis=
t&#39;<br>
&gt; branch and tag it.<br>
&gt; So people can download the tarballs prefixed with &#39;dist-&#39; here=
:<br>
&gt; <a href=3D"https://github.com/yaml/libyaml/releases" rel=3D"noreferrer=
 noreferrer" target=3D"_blank">https://github.com/yaml/libyaml/releases</a>=
<br>
<br>
That&#39;s a good solution for a release tarball.=C2=A0 What Yves is talkin=
g<br>
about is the tarball that has the git describe output embedded for any<br>
random commit, i.e., what you get when you click the &quot;snapshot&quot; l=
ink<br>
next to any commit in our current gitweb interface.=C2=A0 This is based on<=
br>
running:<br>
<br>
$ perl Porting/<a href=3D"http://make_dot_patch.pl" rel=3D"noreferrer noref=
errer" target=3D"_blank">make_dot_patch.pl</a> &gt; .patch<br>
<br>
in a git checkout *before* generating the tarball.=C2=A0 This allows the<br=
>
downloader to build without having git installed.=C2=A0 I think some<br>
Test::Smoke configurations depend on that.<br></blockquote></div></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Well, actually we add it to the t=
arball after git has created it but that is just an implementation detail, =
the end result is the same.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Yves</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
</blockquote></div></div></div>

--000000000000da758b058d91097c--
0
demerphq
7/13/2019 2:42:26 PM
--000000000000bf0b71058d912145
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 13 Jul 2019, 16:42 demerphq, <demerphq@gmail.com> wrote:

>
>
> On Sat, 13 Jul 2019, 15:38 Craig A. Berry, <craig.a.berry@gmail.com>
> wrote:
>
>> On Sat, Jul 13, 2019 at 8:07 AM Tina M=C3=BCller <post@tinita.de> wrote:
>> >
>> > On Wed, 10 Jul 2019, demerphq wrote:
>> >
>> > > I think in practice *this* is going to be one of the bigger
>> > > challenges. We had to hack the git page to support producing the
>> > > correct tarball with the correct contents. (Specifically we inject a
>> > > file into the tarball that is not contained in the repository) My be=
t
>> > > is that out of the box github will not be able to support our use
>> > > case.
>> >
>> > FWIW, for libyaml we also had to find a way to let people download
>> > distribution tarballs.
>> > If you build from git, you need to bootstrap. If you download the
>> > distribution tarball, you don't.
>> >
>> > For that, we create the tarball and put the contents into the 'dist'
>> > branch and tag it.
>> > So people can download the tarballs prefixed with 'dist-' here:
>> > https://github.com/yaml/libyaml/releases
>>
>> That's a good solution for a release tarball.  What Yves is talking
>> about is the tarball that has the git describe output embedded for any
>> random commit, i.e., what you get when you click the "snapshot" link
>> next to any commit in our current gitweb interface.  This is based on
>> running:
>>
>> $ perl Porting/make_dot_patch.pl > .patch
>>
>> in a git checkout *before* generating the tarball.  This allows the
>> downloader to build without having git installed.  I think some
>> Test::Smoke configurations depend on that.
>>
>
> Well, actually we add it to the tarball after git has created it but that
> is just an implementation detail, the end result is the same.
>

I'll see if I can find the hack I did to support this.

Yves

>

--000000000000bf0b71058d912145
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" =
class=3D"gmail_attr">On Sat, 13 Jul 2019, 16:42 demerphq, &lt;<a href=3D"ma=
ilto:demerphq@gmail.com">demerphq@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"auto"><div><br><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 13 Jul 2019, 15:38 Cra=
ig A. Berry, &lt;<a href=3D"mailto:craig.a.berry@gmail.com" target=3D"_blan=
k" rel=3D"noreferrer">craig.a.berry@gmail.com</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">On Sat, Jul 13, 2019 at 8:07 AM Tina M=C3=BCller =
&lt;<a href=3D"mailto:post@tinita.de" rel=3D"noreferrer noreferrer" target=
=3D"_blank">post@tinita.de</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wed, 10 Jul 2019, demerphq wrote:<br>
&gt;<br>
&gt; &gt; I think in practice *this* is going to be one of the bigger<br>
&gt; &gt; challenges. We had to hack the git page to support producing the<=
br>
&gt; &gt; correct tarball with the correct contents. (Specifically we injec=
t a<br>
&gt; &gt; file into the tarball that is not contained in the repository) My=
 bet<br>
&gt; &gt; is that out of the box github will not be able to support our use=
<br>
&gt; &gt; case.<br>
&gt;<br>
&gt; FWIW, for libyaml we also had to find a way to let people download<br>
&gt; distribution tarballs.<br>
&gt; If you build from git, you need to bootstrap. If you download the<br>
&gt; distribution tarball, you don&#39;t.<br>
&gt;<br>
&gt; For that, we create the tarball and put the contents into the &#39;dis=
t&#39;<br>
&gt; branch and tag it.<br>
&gt; So people can download the tarballs prefixed with &#39;dist-&#39; here=
:<br>
&gt; <a href=3D"https://github.com/yaml/libyaml/releases" rel=3D"noreferrer=
 noreferrer noreferrer" target=3D"_blank">https://github.com/yaml/libyaml/r=
eleases</a><br>
<br>
That&#39;s a good solution for a release tarball.=C2=A0 What Yves is talkin=
g<br>
about is the tarball that has the git describe output embedded for any<br>
random commit, i.e., what you get when you click the &quot;snapshot&quot; l=
ink<br>
next to any commit in our current gitweb interface.=C2=A0 This is based on<=
br>
running:<br>
<br>
$ perl Porting/<a href=3D"http://make_dot_patch.pl" rel=3D"noreferrer noref=
errer noreferrer" target=3D"_blank">make_dot_patch.pl</a> &gt; .patch<br>
<br>
in a git checkout *before* generating the tarball.=C2=A0 This allows the<br=
>
downloader to build without having git installed.=C2=A0 I think some<br>
Test::Smoke configurations depend on that.<br></blockquote></div></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Well, actually we add it to the t=
arball after git has created it but that is just an implementation detail, =
the end result is the same.</div></div></blockquote></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">I&#39;ll see if I can find the hack I did to s=
upport this.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Yves</div><=
div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"auto"><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
</blockquote></div></div></div>
</blockquote></div></div>

--000000000000bf0b71058d912145--
0
demerphq
7/13/2019 2:49:08 PM

> On Jul 12, 2019, at 7:55, Craig A. Berry <craig.a.berry@gmail.com> =
wrote:
>=20
> I think you are right.  I have poked around a bit to see if any
> server-side scripting is available on GitHub and so far the answer
> seems to be no.  So we have no way to include git_version.h in a
> tarball or zipball downloaded from GitHub.

Surely writing (or moving) the small server application to build =
appropriate tar balls is doable though. :-)

Is the existing code available somewhere?


Ask=
0
ask
7/13/2019 11:15:45 PM
On Sat, Jul 13, 2019 at 6:16 PM Ask Bj=C3=B8rn Hansen <ask@perl.org> wrote:

> > On Jul 12, 2019, at 7:55, Craig A. Berry <craig.a.berry@gmail.com> wrot=
e:
> >
> > I think you are right.  I have poked around a bit to see if any
> > server-side scripting is available on GitHub and so far the answer
> > seems to be no.  So we have no way to include git_version.h in a
> > tarball or zipball downloaded from GitHub.
>
> Surely writing (or moving) the small server application to build appropri=
ate tar balls is doable though. :-)

I guess we could go back to snapshots as a separate service like in
the days before git.  In fact, as long as perl5.git.perl.org is
maintained as a mirror, that service will still be available as it is
now.  But someone who goes to the authoritative repository on GitHub
and clicks "Clone or Download" and chooses "Download ZIP" will get a
zipball that looks like it will build (try it at
<https://github.com/Perl/perl5>) but it will build without anything in
the perl -V output that would indicate what commit of what branch was
built.  That's going to be a problem if we ever get a bug report from
that build.

Building from the zip archive also fails these tests:

Failed 2 tests out of 2442, 99.92% okay.
.../ext/Pod-Html/t/cache.t
porting/exec-bit.t

probably because git archive --format=3Dzip has never preserved
permission bits correctly (last time I looked it used an ancient DOS
version of the Info-Zip format that doesn't record those bits).  There
is a tarball option, but apparently you have to know the magic URL and
there is nothing user-visible in the web interface.

So someone new who does the obvious thing and downloads Perl will get
something that doesn't work, for various definitions of work.  I hope
we can do better, but so far haven't  thought of how.

> Is the existing code available somewhere?

The code is in the core and is run every time you click "snapshot"
from the gitweb interface or use rsync to pull a copy of the source
tree or build from a local git repository:

<https://perl5.git.perl.org/perl.git/blob/HEAD:/Porting/make_dot_patch.pl>

<https://perl5.git.perl.org/perl.git/blob/HEAD:/Porting/GitUtils.pm>
0
craig
7/14/2019 2:49:33 AM
On Fri, 12 Jul 2019, at 16:56, Craig A. Berry wrote:
> I think you are right.  I have poked around a bit to see if any
> server-side scripting is available on GitHub and so far the answer
> seems to be no.  So we have no way to include git_version.h in a
> tarball or zipball downloaded from GitHub.
>

export-subst in .gitattributes[1] allows to use $Format:foo$
placeholders in specified files. Github does expand them in generated
tarballs.

While this feature isn't able to fully recreate the output of 'git
describe', it can write the id and timestamp of the current commit to
a file.

[1] - https://git-scm.com/docs/gitattributes#_creating_an_archive
0
me
7/14/2019 4:52:41 AM
On Sat, Jul 13, 2019 at 11:53 PM Tomasz Konojacki <me@xenu.pl> wrote:
>
> On Fri, 12 Jul 2019, at 16:56, Craig A. Berry wrote:
> > I think you are right.  I have poked around a bit to see if any
> > server-side scripting is available on GitHub and so far the answer
> > seems to be no.  So we have no way to include git_version.h in a
> > tarball or zipball downloaded from GitHub.
> >
>
> export-subst in .gitattributes[1] allows to use $Format:foo$
> placeholders in specified files. Github does expand them in generated
> tarballs.
>
> While this feature isn't able to fully recreate the output of 'git
> describe', it can write the id and timestamp of the current commit to
> a file.
>
> [1] - https://git-scm.com/docs/gitattributes#_creating_an_archive

Excellent!  That actually gets us most of the way there.  First I did this:

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000000..25cb6862f6
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+.patchfile export-subst
diff --git a/.patchfile b/.patchfile
new file mode 100644
index 0000000000..857a0a976e
--- /dev/null
+++ b/.patchfile
@@ -0,0 +1 @@
+$Format:%D$ $Format:%cI$ $Format:%H$
\ No newline at end of file
--

(N.B.  For testing, I made a .patchfile that can sit alongside a
..patch, but an alternative would be to remove .patch from .gitignore
and check in one that has the format templates here shown in
..patchfile.)

Then I generated an archive and extracted the .patchfile to observe
the substitutions:

$ git archive --format=zip --prefix="bleadtest/"
--output="../bleadtest.zip" HEAD
$ cd ..
$ unzip bleadtest.zip bleadtest/.patchfile
Archive:  bleadtest.zip
f74569cca2268c4643aaedd3b6f31c9bbb49d141
  inflating: bleadtest/.patchfile
$ cat bleadtest/.patchfile
HEAD -> blead 2019-07-14T08:09:14-05:00 f74569cca2268c4643aaedd3b6f31c9bbb49d141

Then I compared that to the file we currently generate in a git repository:

$ perl Porting/make_dot_patch.pl > .patch
$ cat .patch
blead 2019-07-14.13:09:14 f74569cca2268c4643aaedd3b6f31c9bbb49d141
v5.31.1-148-gf74569cca2

So the new file generated at archive time has the branch name, the
timestamp of the last commit, and the sha1 of the last commit just
like the existing file.  We might have to fiddle with the time format
to match exactly, and we are missing the git describe output that is
the 4th item in the existing .patch file.  Maybe someone deeply versed
in the --pretty formats knows a way to get that, or maybe we can live
without it.
0
craig
7/14/2019 1:35:29 PM
On Mon, Jul 8, 2019 at 5:45 PM Sawyer X <xsawyerx@gmail.com> wrote:

> Q: What else needs doing?
>
> A: We need to know about any existing integration with RT or perl5's
> existing git repo. If you know of something, please let us know so it
> can be accommodated during the migration.

The "Perl 5 Commit Summary" messages that come to p5p will need
modification.  I don't know where it runs or how it works, but I
believe Nicholas wrote it, and it appears to come from his e-mail
address.  If it's absolutely necessary, we could probably get by
without the avatar picture of Nicholas wearing a bright yellow shirt
and standing in front of a field of bright yellow flowers :-).
0
craig
7/14/2019 11:01:15 PM
On Sat, Jul 13, 2019 at 08:38:39AM -0500, Craig A. Berry wrote:
> 
> That's a good solution for a release tarball.  What Yves is talking
> about is the tarball that has the git describe output embedded for any
> random commit, i.e., what you get when you click the "snapshot" link
> next to any commit in our current gitweb interface.  This is based on
> running:
> 
> $ perl Porting/make_dot_patch.pl > .patch
> 
> in a git checkout *before* generating the tarball.  This allows the
> downloader to build without having git installed.  I think some
> Test::Smoke configurations depend on that.


I'm not very familiar with git hooks, so perhaps I'm just suggesting 
nonsense, but could this .patch file be generated with an appropriate
git hook?



Abigail
0
abigail
7/15/2019 5:12:14 PM
On Mon, Jul 15, 2019 at 12:10 PM Abigail <abigail@abigail.be> wrote:
>
> On Sat, Jul 13, 2019 at 08:38:39AM -0500, Craig A. Berry wrote:
> >
> > That's a good solution for a release tarball.  What Yves is talking
> > about is the tarball that has the git describe output embedded for any
> > random commit, i.e., what you get when you click the "snapshot" link
> > next to any commit in our current gitweb interface.  This is based on
> > running:
> >
> > $ perl Porting/make_dot_patch.pl > .patch
> >
> > in a git checkout *before* generating the tarball.  This allows the
> > downloader to build without having git installed.  I think some
> > Test::Smoke configurations depend on that.
>
>
> I'm not very familiar with git hooks, so perhaps I'm just suggesting
> nonsense, but could this .patch file be generated with an appropriate
> git hook?

It's a good thought, but there don't appear to be any hooks on an
archive operation and as far as I can tell, GitHub does not allow
server-side hooks anyway.
0
craig
7/15/2019 5:33:34 PM
--000000000000059578058e0ca5bb
Content-Type: text/plain; charset="UTF-8"

I think having a "master" branch is a good idea, as an alias for the latest
released production version.


On Fri, Jul 12, 2019 at 4:28 PM Leon Timmermans <fawaka@gmail.com> wrote:

>
> Almost all git repository have a master branch, but that doesn't mean
> it always means the same. Most importantly: does master mean
> "production branch" or "development branch". In my head it means the
> former, but given that we have a maintenance branch for every stable
> release the former doesn't seem like a good fit. You are suggesting
> the latter, which I have seen before but always felt wrong to me.
>
> I would argue for keeping it as it is. It's fine for the name to be
> different from most git projects, because our whole setup is different
> from most git projects
>
>
> Leon
>


-- 
"Plant yourself like a tree beside the river of truth and tell the whole
world: No, you move."

--000000000000059578058e0ca5bb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div>I think having a &quot;mas=
ter&quot; branch is a good idea, as an alias for the latest released produc=
tion version.</div><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 12, 2019 at 4:28 PM Leo=
n Timmermans &lt;<a href=3D"mailto:fawaka@gmail.com">fawaka@gmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Almost all git repository have a master branch, but that doesn&#39;t mean<b=
r>
it always means the same. Most importantly: does master mean<br>
&quot;production branch&quot; or &quot;development branch&quot;. In my head=
 it means the<br>
former, but given that we have a maintenance branch for every stable<br>
release the former doesn&#39;t seem like a good fit. You are suggesting<br>
the latter, which I have seen before but always felt wrong to me.<br>
<br>
I would argue for keeping it as it is. It&#39;s fine for the name to be<br>
different from most git projects, because our whole setup is different<br>
from most git projects<br>
<br>
<br>
Leon<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div>&quot;Plant yourself =
like a tree beside the river of truth and tell the whole world: No, you mov=
e.&quot;</div></div></div></div></div>

--000000000000059578058e0ca5bb--
0
davidnicol
7/19/2019 6:10:07 PM
--000000000000080a99058e0cfa12
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 19, 2019 at 2:10 PM David Nicol <davidnicol@gmail.com> wrote:

>
> I think having a "master" branch is a good idea, as an alias for the
> latest released production version.
>

 As I alluded earlier, I think that would be worse than no change at all.
Master branch has a specific meaning which is quite similar to how blead is
currently used, and a "master" that did something else would only confuse
things. Tags already serve as aliases for the production versions.

-Dan

--000000000000080a99058e0cfa12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Jul 19, 2019 at 2:10 PM David Nicol &=
lt;<a href=3D"mailto:davidnicol@gmail.com">davidnicol@gmail.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div dir=3D"ltr"><br></div><div>I think having a &quot;master&quot; br=
anch is a good idea, as an alias for the latest released production version=
..</div></div></blockquote><div><br></div><div>=C2=A0As I alluded earlier, I=
 think that would be worse than no change at all. Master branch has a speci=
fic meaning which is quite similar to how blead is currently used, and a &q=
uot;master&quot; that did something else would only confuse things. Tags al=
ready serve as aliases for the production versions.</div><div><br></div><di=
v>-Dan</div></div></div>

--000000000000080a99058e0cfa12--
0
grinnz
7/19/2019 6:34:17 PM
[top-posted]


I'll follow this up with Github people, to see if they have any
suggestions or thoughts about it.


On 7/14/19 4:35 PM, Craig A. Berry wrote:
> On Sat, Jul 13, 2019 at 11:53 PM Tomasz Konojacki <me@xenu.pl> wrote:
>> On Fri, 12 Jul 2019, at 16:56, Craig A. Berry wrote:
>>> I think you are right.  I have poked around a bit to see if any
>>> server-side scripting is available on GitHub and so far the answer
>>> seems to be no.  So we have no way to include git_version.h in a
>>> tarball or zipball downloaded from GitHub.
>>>
>> export-subst in .gitattributes[1] allows to use $Format:foo$
>> placeholders in specified files. Github does expand them in generated
>> tarballs.
>>
>> While this feature isn't able to fully recreate the output of 'git
>> describe', it can write the id and timestamp of the current commit to
>> a file.
>>
>> [1] - https://git-scm.com/docs/gitattributes#_creating_an_archive
> Excellent!  That actually gets us most of the way there.  First I did this:
>
> diff --git a/.gitattributes b/.gitattributes
> new file mode 100644
> index 0000000000..25cb6862f6
> --- /dev/null
> +++ b/.gitattributes
> @@ -0,0 +1 @@
> +.patchfile export-subst
> diff --git a/.patchfile b/.patchfile
> new file mode 100644
> index 0000000000..857a0a976e
> --- /dev/null
> +++ b/.patchfile
> @@ -0,0 +1 @@
> +$Format:%D$ $Format:%cI$ $Format:%H$
> \ No newline at end of file
> --
>
> (N.B.  For testing, I made a .patchfile that can sit alongside a
> .patch, but an alternative would be to remove .patch from .gitignore
> and check in one that has the format templates here shown in
> .patchfile.)
>
> Then I generated an archive and extracted the .patchfile to observe
> the substitutions:
>
> $ git archive --format=zip --prefix="bleadtest/"
> --output="../bleadtest.zip" HEAD
> $ cd ..
> $ unzip bleadtest.zip bleadtest/.patchfile
> Archive:  bleadtest.zip
> f74569cca2268c4643aaedd3b6f31c9bbb49d141
>   inflating: bleadtest/.patchfile
> $ cat bleadtest/.patchfile
> HEAD -> blead 2019-07-14T08:09:14-05:00 f74569cca2268c4643aaedd3b6f31c9bbb49d141
>
> Then I compared that to the file we currently generate in a git repository:
>
> $ perl Porting/make_dot_patch.pl > .patch
> $ cat .patch
> blead 2019-07-14.13:09:14 f74569cca2268c4643aaedd3b6f31c9bbb49d141
> v5.31.1-148-gf74569cca2
>
> So the new file generated at archive time has the branch name, the
> timestamp of the last commit, and the sha1 of the last commit just
> like the existing file.  We might have to fiddle with the time format
> to match exactly, and we are missing the git describe output that is
> the 4th item in the existing .patch file.  Maybe someone deeply versed
> in the --pretty formats knows a way to get that, or maybe we can live
> without it.
0
xsawyerx
7/27/2019 8:53:38 PM
On 7/12/19 8:13 PM, Craig A. Berry wrote:
> On Fri, Jul 12, 2019 at 10:08 AM Dan Book <grinnz@gmail.com> wrote:
>> On Fri, Jul 12, 2019 at 10:52 AM Craig A. Berry <craig.a.berry@gmail.com> wrote:
>>> +1.  I really loathe the most common GitHub workflow where the commit
>>> history consists almost entirely of "Merge pull request #1234 from
>>> somebody/somebranch/about...<cut off>" which is devoid of relevant
>>> content
>>
>> As I mentioned previously, the rebase option for merging PRs is available.
> Yes, I'm aware it's possible.  Just adding my voice to those saying
> it's important to keep doing things this way.


I agree with you here.


Considering it's only the core team that merges, this should be our
internal requirements. However, I'm also in favor of making this not
only a rule, but configured in the Github settings so it's the right
thing by default.


(Some people object to rebase because it changes the history to a
history that didn't actually exist. That's a fair argument.)


> [...]
0
xsawyerx
7/27/2019 9:00:31 PM
On 7/11/19 1:31 PM, Nicholas Clark wrote:
> On Tue, Jul 09, 2019 at 01:45:28AM +0300, Sawyer X wrote:
>
>> The problem with anonymous ticket submission is that it inevitably
>> becomes a spam target. You can of course get rid of much of the bad
>> traffic with filtering. However you are still left with processes that
>> are fragile and/or overly dependent on humans.
> Technically you can still "anonymously" submit bug reports (or without an
> account), because you can still mail them direct to the list. It just won't
> get into the issue tracker that way :-/


.... but shouldn't.


>
>> A: We believe that GitHub is going to be around for a long time. It has
> Which, with hindsight, could not have been said last year. I had no idea
> how much money it was losing until all the news about the sale.
>
>> critical mass in the open source community, and is backed by Microsoft
>> which is not interested in seeing it fail. Its powerful API makes it
>> possible to keep a backup of all of our data, should we have to migrate.
> And of course, Microsoft is Evil, and they know it, so they can't afford
> to mess up (any more) and loose more mindshare.
>
> Whereas various other firms (eg Google, Apple, Facebook, Amazon) who might
> ave bought it are all angels, so would never do anything daft.
>
>> Q: Will this change how we use Git?
>>
>> A: There are no plans to do so. We’re just moving the “canonical” git
>> repository.
> Please can we take care to stick to "no plans to do so".
>
> Specifically in another mail Hugo noted one of my main concerns -
> historically github has made it easy with pull requests to make a history
> graph that is complete spaghetti (although unlike spaghetti code, this will
> of course always be acyclic (oh, prove me wrong with an SHA-1 collision)).
>
> git bisect is a very valuable tool - please can we continue to rebase
> (where possible) before merging in patches and changes.
>
> (even if the merge isn't a fast-forward, the trivial merge commit isn't
> going to mess up bisectability)


I think we should make "rebasing" a requirement for merging. That isn't
always the case at the moment anyway, but with Github we have more tools
to make it happen.


>
>> A: All issues (open and closed) will be moved to GitHub. Any special
>> tags (like operating system, Perl 5 version, etc.) will be made tags in
>> GitHub.
> I'm very glad to read that this is the plan. I have had occasional cause
> to need to reference bug IDs in the pre-2002 bug tracker, and it is useful
> that those tickets were migrated to RT. For some amusement value, this
> now means that those tickets will migrate onwards.
>
>> A: Reporting security issues should continue to be done by emailing
>> perl5-security-report@perl.org <mailto:perl5-security-report@perl.org>.
>> GitHub has provided us with a private repository for tracking security
>> issues and we will be able to make these public once resolved, as we
>> currently do in RT.
> With sufficient permissions that third party security reporters can see
> discussions/progress on their own tickets, without getting leakage from
> other tickets?
>
> Or "Sadly, no, we're going to have to relay them info back by mail" ?


At the moment it seems like the latter. We cannot control which tickets
reports have access to. What we do with RT at the moment is very
similar: You have the tickets and there are specific addresses that are
CC'ed by RT. RT definitely makes this easier, but it still includes the
concept of a loop-in for those people.


>
>> Q: What about perl5.git.perl.org?
>>
>> A: It will be made a mirror of https://github.com/Perl/perl5and may be
>> retired at a future date based on usage.
> Note that that URL isn't controlled by booking.com.
> It's the perl.org DNS that determines which host gets to serve it.
> It bounced around between a couple of possibilities during the git
> migration.
>
> Whereas the future plan of making github "canonical" does mean that there
> is now an uninterested/untrusted third party who now have some control
> over what is perceived as the true perl.
>
> (This might matter in the case of an acrimonious fork, where both sides are
> claiming that the other is the antipope.)


Since we control perl.org within the NOC, I'm sure certain it won't be
left to a split brain disagreement.


>> Q: Will all ticket updates be sent to the list as before?
>>
>> A: Only the initial ticket creation will show up on the list. This will
>> give you the ability to monitor only the issues you care about. You can
>> also monitor the whole project on GitHub to get all updates by simply
>> setting watch as you see fit in GitHub.
>>
>>
>> Updates will be received based on monitoring the person chooses or when
>> said person is explicitly mentioned. You may choose to monitor
>> everything (what we call the “firehose mode”), as currently on the p5p
>> mailing list.
> Not that I've been active recently, but personally this change is something
> that saddens me. I had always felt that it was useful that the main
> development forum was not decoupled from the nitty-gritty of
>
> 1) actually fixing stuff (ie graft, not just ideas)
> 2) the implications of changes (ie what turned out to break, what it really
>    cost)


I disagree with this. My first comments to p5p were "these are several
lists rolled into one!" and I was informed that "this is what works for
us." I was convinced of it until I really could not keep up with the
list and everything in it. The fact that many create filters to manage
this complexity is one canary.


Another one we've noticed recently is that several core members stopped
reading the list because of it. That, to me, is a much bigger, brighter,
red sign.


There seems to be this understanding that *everyone* must receive *all*
communications. Why? You should be *able to* but not forced. If it's
critical, you could loop people in by tagging them, or you can literally
tag *everyone* if you want, too. But this isn't necessary for everyone
on every thread. It's why many of us (me included) have a hard time
keeping up.



> Also, it's really useful that mail readers are threaded. (I think RT is too).
> It's much easier to follow complex discussions in a threaded view, instead of
> a forced-sorted-by-time flat view.
>
> github only has the latter, doesn't it?


Mostly correct. It doesn't have threaded view, but you can quote and
reply to particular people, the latter of which is not possible in RT or
emails. You can explicitly ping people per message, which is very
valuable in long conversations. (Quoting is the other valuable method,
but already available in email and RT.)


> This is making the easy stuff easier (or shinier) but the hard stuff harder.
> (But that's part of their business sales model, isn't it?)


I imagine it's because it's difficult to present in a web UI, which is
the primary communication channel in Github. (Facebook also has
limitation to number of threads in comments - a very low number IIRC.)


> On the other hand, at least it's not JIRA.
> (Although, I hate the world for not having an obvious alternative to JIRA.
> There's clearly money to be made here - why isn't anyone else able to?


Complicated stuff be complicated?
0
xsawyerx
7/28/2019 12:35:41 PM
On Sun, Jul 28, 2019 at 03:35:41PM +0300, Sawyer X wrote:
> 
> I think we should make "rebasing" a requirement for merging. That isn't
> always the case at the moment anyway, but with Github we have more tools
> to make it happen.


As someone who does releases every now and then, I'm very much in favour
of keeping the merge commits. The most time consuming part of making a
release is creating the perldelta. And one of the more time consuming
parts of that is to determine which commits belong together so they
can get a single entry in perldelta. If commits have been rebased,
and the merge commit disappears it becomes harder to determine this;
with the merge commit, it's easier.

At $WORK, I use

    [pull]  
        rebase = merges
        edit = false
    [merge]
        ff = false

which creates a linear history (to aid bisecting), but keeps the branches
and merges visible.



Abigail
0
abigail
7/29/2019 9:37:29 AM
On 7/29/19 12:37 PM, Abigail wrote:
> On Sun, Jul 28, 2019 at 03:35:41PM +0300, Sawyer X wrote:
>> I think we should make "rebasing" a requirement for merging. That isn't
>> always the case at the moment anyway, but with Github we have more tools
>> to make it happen.
>
> As someone who does releases every now and then, I'm very much in favour
> of keeping the merge commits. The most time consuming part of making a
> release is creating the perldelta. And one of the more time consuming
> parts of that is to determine which commits belong together so they
> can get a single entry in perldelta. If commits have been rebased,
> and the merge commit disappears it becomes harder to determine this;
> with the merge commit, it's easier.
>
> At $WORK, I use
>
>     [pull]  
>         rebase = merges
>         edit = false
>     [merge]
>         ff = false


I use the same configuration for the same reason.


Big +1 on this.
0
xsawyerx
7/29/2019 7:59:56 PM
--000000000000546b25059011f706
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi. I=E2=80=99ve been out of loop a few weeks. Has the github repo been lau=
nched?

On Mon, Jul 29, 2019 at 4:00 PM Sawyer X <xsawyerx@gmail.com> wrote:

>
> On 7/29/19 12:37 PM, Abigail wrote:
> > On Sun, Jul 28, 2019 at 03:35:41PM +0300, Sawyer X wrote:
> >> I think we should make "rebasing" a requirement for merging. That isn'=
t
> >> always the case at the moment anyway, but with Github we have more too=
ls
> >> to make it happen.
> >
> > As someone who does releases every now and then, I'm very much in favou=
r
> > of keeping the merge commits. The most time consuming part of making a
> > release is creating the perldelta. And one of the more time consuming
> > parts of that is to determine which commits belong together so they
> > can get a single entry in perldelta. If commits have been rebased,
> > and the merge commit disappears it becomes harder to determine this;
> > with the merge commit, it's easier.
> >
> > At $WORK, I use
> >
> >     [pull]
> >         rebase =3D merges
> >         edit =3D false
> >     [merge]
> >         ff =3D false
>
>
> I use the same configuration for the same reason.
>
>
> Big +1 on this.
>
--=20
Matthew O. Persico

--000000000000546b25059011f706
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Hi. I=E2=80=99ve been out of loop a few weeks. Has t=
he github repo been launched?</div></div><div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 29, 2019 at 4:00 PM Saw=
yer X &lt;<a href=3D"mailto:xsawyerx@gmail.com">xsawyerx@gmail.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><br>
On 7/29/19 12:37 PM, Abigail wrote:<br>
&gt; On Sun, Jul 28, 2019 at 03:35:41PM +0300, Sawyer X wrote:<br>
&gt;&gt; I think we should make &quot;rebasing&quot; a requirement for merg=
ing. That isn&#39;t<br>
&gt;&gt; always the case at the moment anyway, but with Github we have more=
 tools<br>
&gt;&gt; to make it happen.<br>
&gt;<br>
&gt; As someone who does releases every now and then, I&#39;m very much in =
favour<br>
&gt; of keeping the merge commits. The most time consuming part of making a=
<br>
&gt; release is creating the perldelta. And one of the more time consuming<=
br>
&gt; parts of that is to determine which commits belong together so they<br=
>
&gt; can get a single entry in perldelta. If commits have been rebased,<br>
&gt; and the merge commit disappears it becomes harder to determine this;<b=
r>
&gt; with the merge commit, it&#39;s easier.<br>
&gt;<br>
&gt; At $WORK, I use<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0[pull]=C2=A0 <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rebase =3D merges<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0edit =3D false<br>
&gt;=C2=A0 =C2=A0 =C2=A0[merge]<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ff =3D false<br>
<br>
<br>
I use the same configuration for the same reason.<br>
<br>
<br>
Big +1 on this.<br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature">Matthew O. Persico</div>

--000000000000546b25059011f706--
0
matthew
8/14/2019 11:21:50 AM
On 8/14/19 2:21 PM, Matthew Persico wrote:
> Hi. I’ve been out of loop a few weeks. Has the github repo been launched?


Not yet.
0
xsawyerx
8/20/2019 11:06:48 AM
On Wed, Aug 14, 2019 at 6:23 AM Matthew Persico
<matthew.persico@gmail.com> wrote:
>
> Hi. I=E2=80=99ve been out of loop a few weeks. Has the github repo been l=
aunched?
>

Matthew,

Thanks for asking. I volunteered to do a test migration of RT so we
could see what it looks like.

The data I'm migrating has a creative amount of encodings and
formattings spanning back 20 years. Think Outlook Express.

I am migrating the data and in the process:
1. Providing a backlink to an archive of the previous system.
2. Backslashing the heck out of github markdown.
3. Identifying the system information from perlbug and wrapping it in
a collapsable section.
4. Identifying inline patches and wrapping them into a collapsable diff blo=
ck.
5. Tagging (labeling) any cases with inline patches.
6. Split the content into chunks < 65536 so it will fit in github entries.
7. Where possible, converting email addresses to github identities.
(this list still needs some love as it's rather small. I'm trying to
fix it by identifying the most frequent email addresses and poulating
the list from them.)

When the final migration is done, we also need to:
1. Close all the issues in github which were closed in RT.
2. Update all RT issues with a link to where it was migrated.
3. Setup redirects from the old RT system to take you to the github issue.
4. Assure github's backlink to the old system points to the read only archi=
ve.

I am at the point where I have a full conversion to github issues and
need a small group to go through the tickets looking for conversion
flaws and spam which can be removed prior to the final conversion. I
found that searching for strings like "money" or "ca$h" helps a ton
here.

My thought would be to get a group to tag the issues they find and
then we can fix the conversion code and do a second pass. I have to do
all of this in a private repo because it will otherwise spam the world
as part of the conversion.

If anyone has some time to help, I would greatly appreciate it. Please
email me directly with your github ID and I'll give you a bit to look
at the repo. I'm thinking we can set up a few labels so you can easily
tag the issues you find.

Thanks,
Todd Rinaldo
0
todd
8/20/2019 3:53:10 PM
--000000000000086c26059260f311
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You see, THIS is what happens when I filter my gmail into labels and set
'Skip the Inbox' to True: I don't see a reply to my offer for help for over
a freakin month. GRRR. My **really** bad.

My GitHub id is matthewpersico.

Thanks.

On Tue, Aug 20, 2019 at 11:53 AM Todd Rinaldo <todd@rinaldo.us> wrote:

> On Wed, Aug 14, 2019 at 6:23 AM Matthew Persico
> <matthew.persico@gmail.com> wrote:
> >
> > Hi. I=E2=80=99ve been out of loop a few weeks. Has the github repo been=
 launched?
> >
>
> Matthew,
>
> Thanks for asking. I volunteered to do a test migration of RT so we
> could see what it looks like.
>
> The data I'm migrating has a creative amount of encodings and
> formattings spanning back 20 years. Think Outlook Express.
>
> I am migrating the data and in the process:
> 1. Providing a backlink to an archive of the previous system.
> 2. Backslashing the heck out of github markdown.
> 3. Identifying the system information from perlbug and wrapping it in
> a collapsable section.
> 4. Identifying inline patches and wrapping them into a collapsable diff
> block.
> 5. Tagging (labeling) any cases with inline patches.
> 6. Split the content into chunks < 65536 so it will fit in github entries=
..
> 7. Where possible, converting email addresses to github identities.
> (this list still needs some love as it's rather small. I'm trying to
> fix it by identifying the most frequent email addresses and poulating
> the list from them.)
>
> When the final migration is done, we also need to:
> 1. Close all the issues in github which were closed in RT.
> 2. Update all RT issues with a link to where it was migrated.
> 3. Setup redirects from the old RT system to take you to the github issue=
..
> 4. Assure github's backlink to the old system points to the read only
> archive.
>
> I am at the point where I have a full conversion to github issues and
> need a small group to go through the tickets looking for conversion
> flaws and spam which can be removed prior to the final conversion. I
> found that searching for strings like "money" or "ca$h" helps a ton
> here.
>
> My thought would be to get a group to tag the issues they find and
> then we can fix the conversion code and do a second pass. I have to do
> all of this in a private repo because it will otherwise spam the world
> as part of the conversion.
>
> If anyone has some time to help, I would greatly appreciate it. Please
> email me directly with your github ID and I'll give you a bit to look
> at the repo. I'm thinking we can set up a few labels so you can easily
> tag the issues you find.
>
> Thanks,
> Todd Rinaldo
>


--=20
Matthew O. Persico

--000000000000086c26059260f311
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You see, THIS is what happens when I filter my gmail into =
labels and set &#39;Skip the Inbox&#39; to True: I don&#39;t see a reply to=
 my offer for help for over a freakin month. GRRR. My **really** bad.<br><b=
r>My GitHub id is matthewpersico.<br><br>Thanks.<br></div><br><div class=3D=
"gmail_quote"><div class=3D"gmail_attr" dir=3D"ltr">On Tue, Aug 20, 2019 at=
 11:53 AM Todd Rinaldo &lt;<a href=3D"mailto:todd@rinaldo.us">todd@rinaldo.=
us</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bor=
der-left-width:1px;border-left-style:solid">On Wed, Aug 14, 2019 at 6:23 AM=
 Matthew Persico<br>
&lt;<a href=3D"mailto:matthew.persico@gmail.com" target=3D"_blank">matthew.=
persico@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi. I=E2=80=99ve been out of loop a few weeks. Has the github repo bee=
n launched?<br>
&gt;<br>
<br>
Matthew,<br>
<br>
Thanks for asking. I volunteered to do a test migration of RT so we<br>
could see what it looks like.<br>
<br>
The data I&#39;m migrating has a creative amount of encodings and<br>
formattings spanning back 20 years. Think Outlook Express.<br>
<br>
I am migrating the data and in the process:<br>
1. Providing a backlink to an archive of the previous system.<br>
2. Backslashing the heck out of github markdown.<br>
3. Identifying the system information from perlbug and wrapping it in<br>
a collapsable section.<br>
4. Identifying inline patches and wrapping them into a collapsable diff blo=
ck.<br>
5. Tagging (labeling) any cases with inline patches.<br>
6. Split the content into chunks &lt; 65536 so it will fit in github entrie=
s.<br>
7. Where possible, converting email addresses to github identities.<br>
(this list still needs some love as it&#39;s rather small. I&#39;m trying t=
o<br>
fix it by identifying the most frequent email addresses and poulating<br>
the list from them.)<br>
<br>
When the final migration is done, we also need to:<br>
1. Close all the issues in github which were closed in RT.<br>
2. Update all RT issues with a link to where it was migrated.<br>
3. Setup redirects from the old RT system to take you to the github issue.<=
br>
4. Assure github&#39;s backlink to the old system points to the read only a=
rchive.<br>
<br>
I am at the point where I have a full conversion to github issues and<br>
need a small group to go through the tickets looking for conversion<br>
flaws and spam which can be removed prior to the final conversion. I<br>
found that searching for strings like &quot;money&quot; or &quot;ca$h&quot;=
 helps a ton<br>
here.<br>
<br>
My thought would be to get a group to tag the issues they find and<br>
then we can fix the conversion code and do a second pass. I have to do<br>
all of this in a private repo because it will otherwise spam the world<br>
as part of the conversion.<br>
<br>
If anyone has some time to help, I would greatly appreciate it. Please<br>
email me directly with your github ID and I&#39;ll give you a bit to look<b=
r>
at the repo. I&#39;m thinking we can set up a few labels so you can easily<=
br>
tag the issues you find.<br>
<br>
Thanks,<br>
Todd Rinaldo<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div class=3D"gmail_signatu=
re" dir=3D"ltr">Matthew O. Persico</div>

--000000000000086c26059260f311--
0
matthew
9/12/2019 8:26:03 PM
--000000000000281de905938a6668
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Soooo, in the paraphrase of a great New York City mayor:

How we doin'?

On Thu, Sep 12, 2019 at 4:26 PM Matthew Persico <matthew.persico@gmail.com>
wrote:

> You see, THIS is what happens when I filter my gmail into labels and set
> 'Skip the Inbox' to True: I don't see a reply to my offer for help for ov=
er
> a freakin month. GRRR. My **really** bad.
>
> My GitHub id is matthewpersico.
>
> Thanks.
>
> On Tue, Aug 20, 2019 at 11:53 AM Todd Rinaldo <todd@rinaldo.us> wrote:
>
>> On Wed, Aug 14, 2019 at 6:23 AM Matthew Persico
>> <matthew.persico@gmail.com> wrote:
>> >
>> > Hi. I=E2=80=99ve been out of loop a few weeks. Has the github repo bee=
n
>> launched?
>> >
>>
>> Matthew,
>>
>> Thanks for asking. I volunteered to do a test migration of RT so we
>> could see what it looks like.
>>
>> The data I'm migrating has a creative amount of encodings and
>> formattings spanning back 20 years. Think Outlook Express.
>>
>> I am migrating the data and in the process:
>> 1. Providing a backlink to an archive of the previous system.
>> 2. Backslashing the heck out of github markdown.
>> 3. Identifying the system information from perlbug and wrapping it in
>> a collapsable section.
>> 4. Identifying inline patches and wrapping them into a collapsable diff
>> block.
>> 5. Tagging (labeling) any cases with inline patches.
>> 6. Split the content into chunks < 65536 so it will fit in github entrie=
s.
>> 7. Where possible, converting email addresses to github identities.
>> (this list still needs some love as it's rather small. I'm trying to
>> fix it by identifying the most frequent email addresses and poulating
>> the list from them.)
>>
>> When the final migration is done, we also need to:
>> 1. Close all the issues in github which were closed in RT.
>> 2. Update all RT issues with a link to where it was migrated.
>> 3. Setup redirects from the old RT system to take you to the github issu=
e.
>> 4. Assure github's backlink to the old system points to the read only
>> archive.
>>
>> I am at the point where I have a full conversion to github issues and
>> need a small group to go through the tickets looking for conversion
>> flaws and spam which can be removed prior to the final conversion. I
>> found that searching for strings like "money" or "ca$h" helps a ton
>> here.
>>
>> My thought would be to get a group to tag the issues they find and
>> then we can fix the conversion code and do a second pass. I have to do
>> all of this in a private repo because it will otherwise spam the world
>> as part of the conversion.
>>
>> If anyone has some time to help, I would greatly appreciate it. Please
>> email me directly with your github ID and I'll give you a bit to look
>> at the repo. I'm thinking we can set up a few labels so you can easily
>> tag the issues you find.
>>
>> Thanks,
>> Todd Rinaldo
>>
>
>
> --
> Matthew O. Persico
>


--=20
Matthew O. Persico

--000000000000281de905938a6668
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Soooo, in the paraphrase of a great New York City mayor:<b=
r><br>How we doin&#39;?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, Sep 12, 2019 at 4:26 PM Matthew Persico &lt;=
<a href=3D"mailto:matthew.persico@gmail.com">matthew.persico@gmail.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">You see, THIS is what happens when I filter my gmail into label=
s and set &#39;Skip the Inbox&#39; to True: I don&#39;t see a reply to my o=
ffer for help for over a freakin month. GRRR. My **really** bad.<br><br>My =
GitHub id is matthewpersico.<br><br>Thanks.<br></div><br><div class=3D"gmai=
l_quote"><div class=3D"gmail_attr" dir=3D"ltr">On Tue, Aug 20, 2019 at 11:5=
3 AM Todd Rinaldo &lt;<a href=3D"mailto:todd@rinaldo.us" target=3D"_blank">=
todd@rinaldo.us</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb=
(204,204,204)">On Wed, Aug 14, 2019 at 6:23 AM Matthew Persico<br>
&lt;<a href=3D"mailto:matthew.persico@gmail.com" target=3D"_blank">matthew.=
persico@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi. I=E2=80=99ve been out of loop a few weeks. Has the github repo bee=
n launched?<br>
&gt;<br>
<br>
Matthew,<br>
<br>
Thanks for asking. I volunteered to do a test migration of RT so we<br>
could see what it looks like.<br>
<br>
The data I&#39;m migrating has a creative amount of encodings and<br>
formattings spanning back 20 years. Think Outlook Express.<br>
<br>
I am migrating the data and in the process:<br>
1. Providing a backlink to an archive of the previous system.<br>
2. Backslashing the heck out of github markdown.<br>
3. Identifying the system information from perlbug and wrapping it in<br>
a collapsable section.<br>
4. Identifying inline patches and wrapping them into a collapsable diff blo=
ck.<br>
5. Tagging (labeling) any cases with inline patches.<br>
6. Split the content into chunks &lt; 65536 so it will fit in github entrie=
s.<br>
7. Where possible, converting email addresses to github identities.<br>
(this list still needs some love as it&#39;s rather small. I&#39;m trying t=
o<br>
fix it by identifying the most frequent email addresses and poulating<br>
the list from them.)<br>
<br>
When the final migration is done, we also need to:<br>
1. Close all the issues in github which were closed in RT.<br>
2. Update all RT issues with a link to where it was migrated.<br>
3. Setup redirects from the old RT system to take you to the github issue.<=
br>
4. Assure github&#39;s backlink to the old system points to the read only a=
rchive.<br>
<br>
I am at the point where I have a full conversion to github issues and<br>
need a small group to go through the tickets looking for conversion<br>
flaws and spam which can be removed prior to the final conversion. I<br>
found that searching for strings like &quot;money&quot; or &quot;ca$h&quot;=
 helps a ton<br>
here.<br>
<br>
My thought would be to get a group to tag the issues they find and<br>
then we can fix the conversion code and do a second pass. I have to do<br>
all of this in a private repo because it will otherwise spam the world<br>
as part of the conversion.<br>
<br>
If anyone has some time to help, I would greatly appreciate it. Please<br>
email me directly with your github ID and I&#39;ll give you a bit to look<b=
r>
at the repo. I&#39;m thinking we can set up a few labels so you can easily<=
br>
tag the issues you find.<br>
<br>
Thanks,<br>
Todd Rinaldo<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr">Matthew O.=
 Persico</div>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature">Matthew O. Persico</div>

--000000000000281de905938a6668--
0
matthew
9/27/2019 3:18:20 PM
Hi all,

Thank you for all the patience and all of the feedback on these
threads. I tried to pick up all of the issues raised from the various
emails and respond to them in one place below. If I have missed
something important, please let me know.

The driving reasons for this change are that we spend a great deal of
time managing infrastructure on volunteer time, and it does not get
the attention that it deserves, which creates risk for us all. Our
goal is to focus on our core competency, which is maintaining Perl 5.
Right now, we do not have spare capacity to continue supporting RT.

On October 18, we will begin the conversion of all RT cases to GitHub
issues. Existing issues in RT will be unavailable until the conversion
completes. (Expected duration 2-3 days).

The move of the primary git repo to GitHub will probably happen that
weekend too. The mirroring will be reversed, and
https://perl5.git.perl.org/ will become a read-only mirror. We need to
work out some details, which is why this change is tentative.

Sincerely,
Sawyer X

**Issue:** I won't create an account on a major service with a complex
EULA. I think we shouldn't support that.
**Response:** Each person has their limitations, but we cannot
accommodate all of them with our restricted resources and capacity. If
you are unwilling to join GitHub, you may submit a patch or work with
another person who has an account. However, our ability to support you
would be limited.

**Issue:** Will there be a persistent migration from RT to GitHub?
**Response:** No. After the migration, old RT links will respond with
a 301, redirecting you to the new GitHub ticket. The header of the
migrated ticket will point you to a read-only copy of the original
case frozen at the time of migration. The system of record will be on
our GitHub repo.

**Issue:** Why didn't you use a self-hosted alternative to RT?
**Response:** While the self-hosted tool might meet our needs now, it
has the risk of aging, and a requirement of ongoing maintenance just
like RT did. Additionally, the setup and hosting costs remain.

**Issue:** Why didn't you use an alternative service instead of GitHub?
**Response:** We feel GitHub already has a strong following in the
Perl community. Over 95% of the repositories referred to in CPAN are
on GitHub. Having both repositories on the same service may also
provide additional benefits from cross-linking, etc.

**Issue:** What about rt.cpan.org?
**Response:** CPAN RT is out of scope for this project.

**Issue:** What about perlbug on legacy versions of perl?
**Response:** When you remove known contributors from
perlbug@perl.org, there are very few non-spam emails. We plan to do a
one-time autoresponder to each new email address and redirect incoming
emails to a monitored mailbox. In the future, we may stop monitoring
the mailbox.

**Issue:** What about perlbug on new versions of perl?
**Response:** The current proposal is to change perlbug to provide a
template for you to enter your information in and then direct you to
GitHub to copy/paste your submission.

**Issue:** How will we ensure new tickets provide sufficient information?
**Response:** GitHub provides the ability to specify one or more
ticketing templates for people who want to submit a new issue.

**Issue:** GitHub uses JS for logins! I don't trust JS.
**Response:** GitHub also provides an API that can be accessed once
you set up a token. Take a look at Net::GitHub::V3.

**Issue:** You should add an anonymous service to which people can
submit issues.
**Response:** One of our most significant maintenance issues is spam.
We prefer authenticated submissions (whether they include a name or
not) because they reduce the spam we will receive considerably.

**Issue:** Where will security issues go?
**Response:** p5p has been granted a non-profit status by GitHub,
which allows us to have multiple private repositories with several
accounts attached to it. We will have a private repository/issues
system in the same org. It will be possible to move issues between the
public and private repository as needed.

**Issue:** How will security issues be reported?
**Response:** Security issues will continue to be reported at
perl5-security-report@perl.org.

**Issue:** When pull requests are enabled, what will the merge policy be?
**Response:** A rebase and push policy can be enforced just like we
already do with our existing repository.
0
xsawyerx
10/11/2019 1:33:49 AM
--Sig_/2Q42Xelet4zYpPh_JB5Ha1O
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Thanks for this update!

On Fri, 11 Oct 2019 04:33:49 +0300, Sawyer X <xsawyerx@gmail.com> wrote:

> **Issue:** Will there be a persistent migration from RT to GitHub?
> **Response:** No. After the migration, old RT links will respond with
> a 301, redirecting you to the new GitHub ticket. The header of the
> migrated ticket will point you to a read-only copy of the original
> case frozen at the time of migration. The system of record will be on
> our GitHub repo.
>=20
> **Issue:** What about rt.cpan.org?
> **Response:** CPAN RT is out of scope for this project.

Will the conversion tools/scripts be available to CPAN authors, so they
could follow in the move from RT to github for the projects that are
already hosted on github?

--=20
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.31      porting perl5 on HP-UX, AIX, and Linux
https://useplaintext.email  https://tux.nl  http://www.test-smoke.org
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

--Sig_/2Q42Xelet4zYpPh_JB5Ha1O
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEGolmczWuFi3lJEbAA6FHoT5dwJgFAl2gG80ACgkQA6FHoT5d
wJitJwgAoL7A4qaEfBLDOtnygaGSg1Jw4u655qylmY7I6xuljVg68V4bQoBa1Mw3
I8PwAIa/9zjMwhwxYiu2ldNZIUjTaoU+3/Lnd0kN7OIAygN7JTey/DLVkRngOr85
QjCUeX278CbcAv2XjteN4VWfGPaD/DauZ94LInmJ4l2LRqkL7/savPjQ6evNEpuC
aY36kEFgvqR6LRqZ3+rGZzVeOkthnmMDj/bHWxTEmbmR0WhlBP/hkSDG2MD25kOI
NiSW5g84BAtYTh+/+ItaF53F9QmrLJvfwiu9ex1w1c3dDnDgkUp+Rig2u9yHsLqN
QeO9lHmRyTKyttEIojwSsBXsqii48Q==
=X9mM
-----END PGP SIGNATURE-----

--Sig_/2Q42Xelet4zYpPh_JB5Ha1O--
0
h
10/11/2019 6:06:05 AM
On Thu, Oct 10, 2019 at 8:35 PM Sawyer X <xsawyerx@gmail.com> wrote:
>
> On October 18, we will begin the conversion of all RT cases to GitHub
> issues. Existing issues in RT will be unavailable until the conversion
> completes. (Expected duration 2-3 days).
>

Hi all.

I've been tasked with coding and testing the RT conversion next week.
Thanks to some help from github using an undocumented API, I've been
able to cut down the conversion time to less than 24 hours.

I have created a demo repo which will show everyone what the
conversion will look like. Not every ticket was able to be converted
perfectly because of the myriad encodings and formatting of the
original issues. If you find major problems with the converted issues
you think should be addressed before conversion, please feel free to
give me feedback by email or by opening a new ticket in that repo. You
can find the public repo here:
https://github.com/Perl/perl5-test/issues

I have done my best to identify and place diffs and system info into
collapsible blocks so they do not pollute the issues. Because the
source format is email, formatting issues sometimes lead to minor
formatting issues of the converted ticket. All of the text has been
copiously backslashed under the hood to be legible in github markdown.
At the top of every issue is the original ticket which you can review
to understand if it was broken to begin with.

We're still looking for some RT ticket authors' github IDs. Being able
to use their github ID instead of their legacy email will enhance the
search functionality of the converted issues (mentions) as well as
keep email addresses out of the converted tickets. If you see any
issues with the currently planned map or know of the github ID of some
of the missing people, please update this ticket or email me:
https://github.com/Perl/perl5-test/issues/10135

The demo repo and the related cases will be deleted after the conversion.

Thanks,
Todd Rinaldo
0
todd
10/11/2019 6:04:01 PM
On Fri, Oct 11, 2019 at 1:07 AM H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
>
> Will the conversion tools/scripts be available to CPAN authors, so they
> could follow in the move from RT to github for the projects that are
> already hosted on github?
>

The API method I used to import the cases cannot be shared at this
time. There is an alternate (slightly slower and doesn't support
timestamp migration) API we could use which would work almost as good.
I'd be up for collaborating with you to clean up the code to make it
more generally useful. to people.

I will also inquire with github on when the other API might be available.

Thanks,
Todd Rinaldo
todd@rinaldo.us
0
todd
10/11/2019 6:08:23 PM
Hi,

Thanks for taking this on! I skimmed my issues and found at least two 
differences, first:

   https://rt.perl.org/Public/Bug/Display.html?id=133695

has way more comments and is in fact "pending release", while the 
comments at

   https://github.com/Perl/perl5-test/issues/16931

cut off earlier than that and is still open. Second, the following comment:

   https://rt.perl.org/Public/Bug/Display.html?id=132475#txn-1652856

is missing from

   https://github.com/Perl/perl5-test/issues/16422


Also, several "Status changed from 'pending release' to 'resolved'" 
messages are not showing up in the comments, which may cause confusion 
because "Status changed from 'open' to 'pending release'" are showing 
up. Examples:

   https://rt.perl.org/Public/Bug/Display.html?id=129967#txn-1461432

the comment was copied over to:

   https://github.com/Perl/perl5-test/issues/15846#issuecomment-540766610

but

   https://rt.perl.org/Public/Bug/Display.html?id=133721#txn-1634948

vs missing here:

   https://github.com/Perl/perl5-test/issues/16947#issuecomment-540801173

and

   https://rt.perl.org/Public/Bug/Display.html?id=133782#txn-1634996

vs missing here:

   https://github.com/Perl/perl5-test/issues/16981#issuecomment-540802161


Thanks,
-- Hauke D

On 11.10.19 20:04, Todd Rinaldo wrote:
> On Thu, Oct 10, 2019 at 8:35 PM Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> On October 18, we will begin the conversion of all RT cases to GitHub
>> issues. Existing issues in RT will be unavailable until the conversion
>> completes. (Expected duration 2-3 days).
>>
> 
> Hi all.
> 
> I've been tasked with coding and testing the RT conversion next week.
> Thanks to some help from github using an undocumented API, I've been
> able to cut down the conversion time to less than 24 hours.
> 
> I have created a demo repo which will show everyone what the
> conversion will look like. Not every ticket was able to be converted
> perfectly because of the myriad encodings and formatting of the
> original issues. If you find major problems with the converted issues
> you think should be addressed before conversion, please feel free to
> give me feedback by email or by opening a new ticket in that repo. You
> can find the public repo here:
> https://github.com/Perl/perl5-test/issues
> 
> I have done my best to identify and place diffs and system info into
> collapsible blocks so they do not pollute the issues. Because the
> source format is email, formatting issues sometimes lead to minor
> formatting issues of the converted ticket. All of the text has been
> copiously backslashed under the hood to be legible in github markdown.
> At the top of every issue is the original ticket which you can review
> to understand if it was broken to begin with.
> 
> We're still looking for some RT ticket authors' github IDs. Being able
> to use their github ID instead of their legacy email will enhance the
> search functionality of the converted issues (mentions) as well as
> keep email addresses out of the converted tickets. If you see any
> issues with the currently planned map or know of the github ID of some
> of the missing people, please update this ticket or email me:
> https://github.com/Perl/perl5-test/issues/10135
> 
> The demo repo and the related cases will be deleted after the conversion.
> 
> Thanks,
> Todd Rinaldo
> 
0
haukex
10/12/2019 7:00:38 AM
>>>>> On Fri, 11 Oct 2019 13:04:01 -0500, Todd Rinaldo <todd@rinaldo.us> sa=
id:

  > please feel free to
  > give me feedback by email or by opening a new ticket in that repo. You
  > can find the public repo here:
  > https://github.com/Perl/perl5-test/issues

I picked a random one of mine and it is cut off after 2018-12-27:

https://rt.perl.org/Public/Bug/Display.html?id=3D133347 ends at the moment
at 2019-05-22, the transit version ends at the moment at
https://github.com/Perl/perl5-test/issues/16775#issuecomment-540796516
which is labeled "p5pRT commented Dec 27, 2018".

I fear I cannot find the exact timestamp of the postings in the
transit version.

I also find this string displaying with weird black noise:

  Please include the string=E2=80=8B: [perl #133347]

Here is the HTML that is on the github page:

  # Please include the string=E2=80=8B:  [perl <code>#133347<span style=3D"=
background-color: #133347; height: 0.8em; width: 0.8em;" class=3D"ml-1 d-in=
line-block v-align-middle Box border-black-fade"></span></code>]<br>
  # in the subject line of all future correspondence about this issue.<br>

Note that the background-color style corresponds to the number of the
issue in RT?

Thanks && Regards,
--=20
andreas
0
andreas
10/13/2019 2:45:21 AM
--683426677-311220912-1570970463=:13570
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Sun, 13 Oct 2019, Andreas Koenig wrote:

> I also find this string displaying with weird black noise:
>
>  Please include the string​: [perl #133347]
>
> Here is the HTML that is on the github page:
>
>  # Please include the string​:  [perl <code>#133347<span style="background-color: #133347; height: 0.8em; width: 0.8em;" class="ml-1 d-inline-block v-align-middle Box border-black-fade"></span></code>]<br>
>  # in the subject line of all future correspondence about this issue.<br>
>
> Note that the background-color style corresponds to the number of the
> issue in RT?

Oh that's funny, that seems to be a github "feature".
Code like `#ff0000` will get a little box with that HTML color appended.

By the way, to get the source code of a posting, you can click on "Quote reply".
You can even select a part of a posting, and then only this will be quoted.
--683426677-311220912-1570970463=:13570--
0
post
10/13/2019 12:41:03 PM
Thank you for checking. It looks like my source data is incomplete.
We're investigating the problem.

Todd

On Sat, Oct 12, 2019 at 9:46 PM Andreas Koenig
<andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
>
> >>>>> On Fri, 11 Oct 2019 13:04:01 -0500, Todd Rinaldo <todd@rinaldo.us> said:
>
>   > please feel free to
>   > give me feedback by email or by opening a new ticket in that repo. You
>   > can find the public repo here:
>   > https://github.com/Perl/perl5-test/issues
>
> I picked a random one of mine and it is cut off after 2018-12-27:
>
> https://rt.perl.org/Public/Bug/Display.html?id=133347 ends at the moment
> at 2019-05-22, the transit version ends at the moment at
> https://github.com/Perl/perl5-test/issues/16775#issuecomment-540796516
> which is labeled "p5pRT commented Dec 27, 2018".
>
> I fear I cannot find the exact timestamp of the postings in the
> transit version.
>
> I also find this string displaying with weird black noise:
>
>   Please include the string: [perl #133347]
>
> Here is the HTML that is on the github page:
>
>   # Please include the string:  [perl <code>#133347<span style="background-color: #133347; height: 0.8em; width: 0.8em;" class="ml-1 d-inline-block v-align-middle Box border-black-fade"></span></code>]<br>
>   # in the subject line of all future correspondence about this issue.<br>
>
> Note that the background-color style corresponds to the number of the
> issue in RT?
>
> Thanks && Regards,
> --
> andreas



-- 
Todd Rinaldo
todd@rinaldo.us
0
todd
10/14/2019 2:33:29 AM
Andreas,

There was a problem with my source data. I have deleted and
re-imported the repo https://github.com/Perl/perl5-test/issues .
Please search for your issues again (the numbers will have changed).
Your issue should be resolved now.

Thanks,
Todd

On Sun, Oct 13, 2019 at 9:33 PM Todd Rinaldo <todd@rinaldo.us> wrote:
>
> Thank you for checking. It looks like my source data is incomplete.
> We're investigating the problem.
>
> Todd
>
> On Sat, Oct 12, 2019 at 9:46 PM Andreas Koenig
> <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
> >
> > >>>>> On Fri, 11 Oct 2019 13:04:01 -0500, Todd Rinaldo <todd@rinaldo.us> said:
> >
> >   > please feel free to
> >   > give me feedback by email or by opening a new ticket in that repo. You
> >   > can find the public repo here:
> >   > https://github.com/Perl/perl5-test/issues
> >
> > I picked a random one of mine and it is cut off after 2018-12-27:
> >
> > https://rt.perl.org/Public/Bug/Display.html?id=133347 ends at the moment
> > at 2019-05-22, the transit version ends at the moment at
> > https://github.com/Perl/perl5-test/issues/16775#issuecomment-540796516
> > which is labeled "p5pRT commented Dec 27, 2018".
> >
> > I fear I cannot find the exact timestamp of the postings in the
> > transit version.
> >
> > I also find this string displaying with weird black noise:
> >
> >   Please include the string: [perl #133347]
> >
> > Here is the HTML that is on the github page:
> >
> >   # Please include the string:  [perl <code>#133347<span style="background-color: #133347; height: 0.8em; width: 0.8em;" class="ml-1 d-inline-block v-align-middle Box border-black-fade"></span></code>]<br>
> >   # in the subject line of all future correspondence about this issue.<br>
> >
> > Note that the background-color style corresponds to the number of the
> > issue in RT?
> >
> > Thanks && Regards,
> > --
> > andreas
>
>
>
> --
> Todd Rinaldo
> todd@rinaldo.us



-- 
Todd Rinaldo
todd@rinaldo.us
0
todd
10/14/2019 11:22:47 PM
>>>>> On Mon, 14 Oct 2019 18:22:00 -0500, Todd Rinaldo <todd@rinaldo.us> sa=
id:

  > Andreas,
  > There was a problem with my source data. I have deleted and
  > re-imported this repo. https://github.com/Perl/perl5-test/issues
  > Please search for your issues again (the numbers will have changed).
  > Your issue should be resolved now.

Thanks, very nice. I'm still finding "things", sorry.

- UTF8 error here:
  https://rt.perl.org/Public/Bug/Display.html?id=3D132760#txn-1527345
  https://github.com/Perl/perl5-test/issues/16387#issuecomment-541939820
  https://rt.perl.org/Public/Bug/Display.html?id=3D133943#txn-1619771
  https://github.com/Perl/perl5-test/issues/16906
  https://rt.perl.org/Public/Bug/Display.html?id=3D132760#txn-1527631
  https://github.com/Perl/perl5-test/issues/16387#issuecomment-541939829

- Dependency by ticket lost:
  https://rt.perl.org/Public/Bug/Display.html?id=3D132760#txn-1526629
  https://github.com/Perl/perl5-test/issues/16387

- github misfeature with the html color square for each issue number
  seen again (e.g. "[perl #134023]" displayed as "[perl #134023 =E2=96=85]":
  https://github.com/Perl/perl5-test/issues/303#issuecomment-541540778
  https://github.com/Perl/perl5-test/issues/16960#issuecomment-541954649

- pseudo messages by the RT system missing, e.g. "Mon, 17 Apr 2017
  19:27:29 -0700 The RT System itself - Type core added"
  https://rt.perl.org/Public/Bug/Display.html?id=3D131169#txn-1457090
  https://github.com/Perl/perl5-test/issues/15964
  https://rt.perl.org/Public/Bug/Display.html?id=3D134023#txn-1625493
  https://github.com/Perl/perl5-test/issues/16960

- attachment locale_t_crash.PNG not accessible
  https://github.com/Perl/perl5-test/issues/15449#issuecomment-541913055
  when I click on it I get a 401

- attachment shows as separate message
  https://github.com/Perl/perl5-test/issues/14168#issuecomment-541875612
  https://rt.perl.org/Public/Bug/Display.html?id=3D122974

Greetings,
--=20
andreas
0
andreas
10/15/2019 2:39:19 AM
On Mon, Oct 14, 2019 at 9:40 PM Andreas Koenig
<andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
>
> >>>>> On Mon, 14 Oct 2019 18:22:00 -0500, Todd Rinaldo <todd@rinaldo.us> =
said:
>
>   > Andreas,
>   > There was a problem with my source data. I have deleted and
>   > re-imported this repo. https://github.com/Perl/perl5-test/issues
>   > Please search for your issues again (the numbers will have changed).
>   > Your issue should be resolved now.
>
> - UTF8 error here:
>   https://rt.perl.org/Public/Bug/Display.html?id=3D132760#txn-1527345
>   https://github.com/Perl/perl5-test/issues/16387#issuecomment-541939820
>   https://rt.perl.org/Public/Bug/Display.html?id=3D133943#txn-1619771
>   https://github.com/Perl/perl5-test/issues/16906
>   https://rt.perl.org/Public/Bug/Display.html?id=3D132760#txn-1527631
>   https://github.com/Perl/perl5-test/issues/16387#issuecomment-541939829

Thanks. This is a side effect of the different RT attachments being
sent stored as inconsistent encodings. I've tried to work with them
but I continue to run into these. I'll take a look.

> - Dependency by ticket lost:
>   https://rt.perl.org/Public/Bug/Display.html?id=3D132760#txn-1526629
>   https://github.com/Perl/perl5-test/issues/16387

Once we migrate all tickets, we should be able to add the deps between
the tickets simply by referring to each other. This is not something I
can do at migration time because the tickets don't exist to do the
referring.

> - github misfeature with the html color square for each issue number
>   seen again (e.g. "[perl #134023]" displayed as "[perl #134023 =E2=96=85=
]":
>   https://github.com/Perl/perl5-test/issues/303#issuecomment-541540778
>   https://github.com/Perl/perl5-test/issues/16960#issuecomment-541954649

These are good examples to fix my anti-emoji-markdown logic. Thanks.
I'll take a look.

> - pseudo messages by the RT system missing, e.g. "Mon, 17 Apr 2017
>   19:27:29 -0700 The RT System itself - Type core added"
>   https://rt.perl.org/Public/Bug/Display.html?id=3D131169#txn-1457090
>   https://github.com/Perl/perl5-test/issues/15964
>   https://rt.perl.org/Public/Bug/Display.html?id=3D134023#txn-1625493
>   https://github.com/Perl/perl5-test/issues/16960

Each github ticket now has labels on the top right which correspond to thos=
e.

> - attachment locale_t_crash.PNG not accessible
>   https://github.com/Perl/perl5-test/issues/15449#issuecomment-541913055
>   when I click on it I get a 401

The rt-archive system is being poked at right now. When I clicked on
it, I got a PNG. Try again?

> - attachment shows as separate message
>   https://github.com/Perl/perl5-test/issues/14168#issuecomment-541875612
>   https://rt.perl.org/Public/Bug/Display.html?id=3D122974

Do you mean the inline diffs I added? That's by design. github doesn't
do attachments via the import API. I instead embedded the diffs if
they are under 64K bytes. Believe it or not we've got patches larger
than that.

Thanks,
Todd
0
todd
10/15/2019 5:07:13 AM
>>>>> On Tue, 15 Oct 2019 00:07:13 -0500, Todd Rinaldo <todd@rinaldo.us> said:

 >> - pseudo messages by the RT system missing, e.g. "Mon, 17 Apr 2017
 >> 19:27:29 -0700 The RT System itself - Type core added"
 >> https://rt.perl.org/Public/Bug/Display.html?id=131169#txn-1457090
 >> https://github.com/Perl/perl5-test/issues/15964
 >> https://rt.perl.org/Public/Bug/Display.html?id=134023#txn-1625493
 >> https://github.com/Perl/perl5-test/issues/16960

  > Each github ticket now has labels on the top right which correspond
  > to those.

These are only the results of the label assignements. The process of who
changed what when is lost that way.

 >> - attachment locale_t_crash.PNG not accessible
 >> https://github.com/Perl/perl5-test/issues/15449#issuecomment-541913055
 >> when I click on it I get a 401

  > The rt-archive system is being poked at right now. When I clicked on
  > it, I got a PNG. Try again?

The link on github points to
https://rt-archive.perl.org/perl5/Ticket/Attachment/1409975/761462/locale_t_crash.PNG
and this still gives me a 401.

 >> - attachment shows as separate message
 >> https://github.com/Perl/perl5-test/issues/14168#issuecomment-541875612
 >> https://rt.perl.org/Public/Bug/Display.html?id=122974

  > Do you mean the inline diffs I added? That's by design. github doesn't
  > do attachments via the import API. I instead embedded the diffs if
  > they are under 64K bytes. Believe it or not we've got patches larger
  > than that.

No, I mean that the above github link points to an attachment, not a
posting. The posting itself is above the attachment as a separate
posting. Both have the same timestamp and same "From", but they are
presented as separate postings. The attachment itself is just a few
lines, so is much smaller that 64k.


-- 
andreas
0
andreas
10/15/2019 5:48:07 AM
Reply: