develooper Front page | perl.perl5.porters | Postings from July 2019

Re: Transition from RT to GitHub [FAQ]

Thread Previous | Thread Next
Nicholas Clark
July 11, 2019 11:00
Re: Transition from RT to GitHub [FAQ]
Message ID:
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
> <>.
> 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
> A: It will be made a mirror of may be
> retired at a future date based on usage.

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

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

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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About