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

Re: Transition from RT to GitHub [FAQ]

Thread Previous | Thread Next
Sawyer X
July 28, 2019 12:35
Re: Transition from RT to GitHub [FAQ]
Message ID:

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

... but shouldn't.

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

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

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

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

>> Q: What about
>> 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
> migration.
> Whereas the future plan of making github "canonical" does mean that there
> is now an uninterested/untrusted third party who now have some control
> over what is perceived as the true perl.
> (This might matter in the case of an acrimonious fork, where both sides are
> claiming that the other is the antipope.)

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

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

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

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

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

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

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

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

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

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

Complicated stuff be complicated?

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