Perl 5 development has moved to Github
I didn't notice much public discussion, but in the last month, Perl 5 development has moved to Github. The logistics of the move were mostly handled by Todd Rinaldo although I'm sure there were other people helping.
The change involved moving the main development repository from perl5.git.perl.org to https://github.com/Perl/perl5, moving the issues from rt.perl.org to Github issues, renaming them in the process, and fixing the code that used the hostnames or URLs for decisions.
The good
On the upside, the move motivated me to go through the open tickets and convert some into pull requests. The integration of various Continous Integration tools with Github means that each pull request can now automatically get a smoke test to see if and what tests get broken when applying a change. This certainly improves the feedback loop for contributors.
The tight integration with Github means that we can also use the code review features of Github to provide detailed and better feedback on specific parts of code in a change than before. Using the mailing list did not allow for convenient feedback and keeping track of the issues.
The bad
In my perception, discussion or communication of the move was non-existent. I think that the current discussion of Perl development is fragmented more by the move. Public discussion now happens across the p5p mailing list, irc and Github issues. This is somewhat worse than having a central archive of discussion on the mailing list. Github issue comments can be made available via RSS, but they are not archived like the nntp mails are.
The ugly
There is very little discussion of how Github should be used and/or what would be a good workflow. For example, there is only a vague consensus on whether to apply your own patches, or when you should ask others to review code. This is left to personal judgement of each comitter. Personally, I think some guidelines or general approach of how Perl should make use of the Github features would be good, but I'm unaware of any public discussion what should be done or avoided.
The future
After today, Perl and pull requests to Perl get automatically smoke tested on Ubuntu, MacOS, Windows and Cygwin using Travis CI and Github Actions. This certainly makes feedback quicker and less reliant. Ideally, there will be a vision of how Github can improve the development of Perl, and that vision will become public knowledge.
I'm the Treasurer for the Frankfurt Perlmongers e.V. . I have organized Perl events including 9 German Perl Workshops and one YAPC::Europe.
Do you have the assumption that the discussion way of Python, Ruby, PHP and node are good?
If the result is successful, then the discussion way of Perl Porters is a good?
It certainly seems wise to ensure that discussions had on p5p and irc, are at least summarized in a pull request / gh issue, or even in the commit message.
In terms of workflows, from memory, projects have had issues with githubs lack of workflow customization. Possibly that's something that paying for Github may get you, but also is an answer to why a project would run their own git(lab).
> ...the current discussion of Perl development is fragmented more by the move.
* Create a separate github user ( the same type various Moose factions use for sync of non-github repos and gh mirrors )
* Make them a watcher of the repo(s) in question
* Subscribe them to the p5p mailing list
* Profit by having each conversation in github reflected in the usual interface, and moreover allowing other subscribers to the list to reply to github issues WITHOUT A GITHUB account
Proof: http://lists.scsys.co.uk/pipermail/dbix-class-devel/2019-November/thread.html
Downsides:
- Someone attempting to password-recover on the sync-account will spam the mailing list
- Technically violates GitHub TOS