Good points all. Looking more closely at Trac, the combinations of "has patch" "patch needs improvement" and "ready for checkin" fields should cover the status of PRs.
I'll try to set some time aside to go through the PRs and check that the status in Trac matches. Though thinking about it, going through 100-odd PRs and checking if they apply cleanly seems like a daunting task. Is there anyway of indicating that a patch needs a review? Or is simply setting "ready for checkin" a good enough signal? Cheers On Sunday, 2 March 2014 19:15:43 UTC+11, Aymeric Augustin wrote: > > On 2 mars 2014, at 02:40, Josh Smeaton <josh.s...@gmail.com <javascript:>> > wrote: > > > At the very least it might be a good middle ground to tag PRs with > "Requires Work" or "Not Ready", so they can be easily filtered out from > "active" PRs. On the other hand, there could be a strange mix of Trac and > the PR queue containing conflicting information. > > > In short, Django uses PRs for code review, and nothing else. The status of > a PR is defined by the status of the Trac ticket that contains a link to > that PR. The ticket lifecycle is explained in the contributing guide. > > GitHub's issues / PR system is designed for small projects. It's > improductive and impractical to look at the list of pull requests and work > from there. So we don’t do that. If you need to filter tickets, do it in > Trac. > > In detail, we cannot make a better use of PRs because GitHub’s UX is > pathetic as soon as you have more than two dozen PRs. Having brought the > number of issues on the Django Debug Toolbar down from 150 to 20, I have > first hand experience of banging my head against GitHub Issues on a projet > much smaller than Django, but already too large for GitHub. It’s simply > impossible to navigate issues efficiently when all you have is binary open > / close (and contributors can’t reopen when you close), tags (if you > emulate state with tags, some tickets end up with multiple states and > others with no state), pagination hardcoded at 30 per page, and that’s it. > Also, if I remember correctly, we cannot receive notifications on the > django-updates mailing list when someone makes a pull request, which > doesn’t help. > > I wish I could say “sure, we’ll give you access, show us how it would > work” but that would mean giving you commit access to Django. At that > point, we’re hitting the other big limitation of GitHub: if you aren’t a > committer, you cannot do anything for a projet. But Django relies a lot on > its broader community. So, once again, if you’d like to clarify the status > of issues, the place to do it is Trac. (Triagers get a few extra > permissions, just ask if you want them.) > > I hope this helps you understand our choices better. I wish we could do > everything on GitHub, but our body of knowledge is in Trac and its features > simply blow GitHub out of the water. > > -- > Aymeric. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2842db27-a723-4f33-a4ec-8cfe70bccc3d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
