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 47704 articles. 1 followers. Follow

35 Replies
38 Views

Similar Articles

[PageSpeed] 57

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
Reply: