GitHub PR status within Trac
101 views
Skip to first unread message
Tobias McNulty
Jul 22, 2016, 6:54:45 PM7/22/16
to django-developers
I spent some time during the DjangoCon sprint today looking into dashboard.djangoproject.com and how it calculates metrics. I was hoping to add some new metrics that mash up data from GitHub and Trac together. While technically possible, this breaks down when you want to link out to a list of the related tickets in Trac. For example:
- A list of Accepted tickets with no open PR or an open PR that hasn't t been touched in X months
- A list of Accepted tickets with no PR and no attached patch that haven't been touched in months
This got me wondering: Is checking for GitHub PRs via JavaScript the Right Way to do it? What if we had a cronjob update Trac periodically with PR status from GitHub?
I think it would be valuable to be able to query on PR status from within Trac, e.g., to help find in progress but stale/abandoned tickets. Cleaning up the work of someone else who's lost interest in a patch is often a good way to get into Django development.
I'm sure there are some holes in this idea, so I'm putting it out there for comment. Was something like this considered before, and if so, why wasn't it pursued?
If it hasn't been considered before, what are the obvious problems I might encounter?
Rather than sync the data periodically, another approach might be to extend the existing trac-github plugin, though that would still require sync'ing existing data up front and substantial testing to make sure all the right events (e.g., renames and closures) are caught appropriately. It's not as simple as adding a commit hash to a ticket's history, esp. if we ever wanted to change the fields that were brought over from GitHub.
Tobias
--
Tobias McNulty
Chief Executive Officer
Carl Meyer
Jul 22, 2016, 7:13:52 PM7/22/16
to django-d...@googlegroups.com
Hi Tobias,
On 07/22/2016 04:53 PM, Tobias McNulty wrote:
> I spent some time during the DjangoCon sprint today looking into
> dashboard.djangoproject.com <http://dashboard.djangoproject.com> and how
1) While being able to query Trac by PR status would be useful, losing
the immediate feedback of "I just created my PR and reloaded the Trac
ticket, and there it is!" would be a significant loss, I think. Delays,
even of just a few minutes, in that sort of UI tend to introduce an "is
this actually working" uncertainty that leads to extra support queries.
So maybe even if you implemented something on the backend, we shouldn't
get rid of the JS code? Or maybe github push hooks could be used to keep
update latency low?
2) I think it was done this way originally because whoever did it was
scared of touching Trac's Python code (with reason), and it was simpler
to just do it in JS, not for any deeper reason.
Carl
On 07/22/2016 04:53 PM, Tobias McNulty wrote:
> I spent some time during the DjangoCon sprint today looking into
> it calculates metrics. I was hoping to add some new metrics that mash up
> data from GitHub and Trac together. While technically possible, this
> breaks down when you want to link out to a list of the related tickets
> in Trac. For example:
>
> * A list of Accepted tickets with no open PR or an open PR that hasn't
> data from GitHub and Trac together. While technically possible, this
> breaks down when you want to link out to a list of the related tickets
> in Trac. For example:
>
> t been touched in X months
> * A list of Accepted tickets with no PR and no attached patch that
> haven't been touched in months
>
> This got me wondering: Is checking for GitHub PRs via JavaScript the
> Right Way to do it? What if we had a cronjob update Trac periodically
> with PR status from GitHub?
>
> I think it would be valuable to be able to query on PR status from
> within Trac, e.g., to help find in progress but stale/abandoned tickets.
> Cleaning up the work of someone else who's lost interest in a patch is
> often a good way to get into Django development.
>
> I'm sure there are some holes in this idea, so I'm putting it out there
> for comment. Was something like this considered before, and if so, why
> wasn't it pursued?
>
> If it hasn't been considered before, what are the obvious problems I
> might encounter?
Others know these systems better than I do, but just a couple thoughts:
>
> This got me wondering: Is checking for GitHub PRs via JavaScript the
> Right Way to do it? What if we had a cronjob update Trac periodically
> with PR status from GitHub?
>
> I think it would be valuable to be able to query on PR status from
> within Trac, e.g., to help find in progress but stale/abandoned tickets.
> Cleaning up the work of someone else who's lost interest in a patch is
> often a good way to get into Django development.
>
> I'm sure there are some holes in this idea, so I'm putting it out there
> for comment. Was something like this considered before, and if so, why
> wasn't it pursued?
>
> If it hasn't been considered before, what are the obvious problems I
> might encounter?
1) While being able to query Trac by PR status would be useful, losing
the immediate feedback of "I just created my PR and reloaded the Trac
ticket, and there it is!" would be a significant loss, I think. Delays,
even of just a few minutes, in that sort of UI tend to introduce an "is
this actually working" uncertainty that leads to extra support queries.
So maybe even if you implemented something on the backend, we shouldn't
get rid of the JS code? Or maybe github push hooks could be used to keep
update latency low?
2) I think it was done this way originally because whoever did it was
scared of touching Trac's Python code (with reason), and it was simpler
to just do it in JS, not for any deeper reason.
Carl
Tim Graham
Jul 25, 2016, 10:05:11 AM7/25/16
to Django developers (Contributions to Django itself)
If the goal is to provide a list of issues suitable for new contributors, I think a curated list of tickets is likely more useful than trying to automate something. Looking over the list of "Has patch" + "Needs improvement" tickets, it seems to me that most of those PRs fizzled out for non-trivial reasons. Going forward, I'll check "Easy pickings" on tickets where I close the PR due to inactivity and where only straightforward updates remain.
Reply all
Reply to author
Forward
0 new messages