Hello John,

This was discussed before, when we moved from self-hosted svn to GitHub-hosted 
git, but I'm not sure there are public archives of all discussions.

As far as I remember, the main points to tackle are:

1. Does GitHub allow "anonymous triage" i.e. labelling, closing, and reopening 
issues by non-committers? I think there was a recent announcement in this area. 
I didn't check the details. Previously, bot-powered workarounds were suggested, 
but they wouldn't provide a good user experience. You want discoverable 
buttons, not a cheat sheet of magic comments.

2. Does the GitHub UI scale to thousands of issues? In theory, any 
classification system can be reproduced with namespaced labels e.g. 
"component:ORM", "status:ready-for-checkin", etc. In practice, it's unlikely to 
be as convenient as what currently exists on Trac.

Perhaps it's just me, but I always found GitHub issues hard to use when I had 
more than on page of issues. Indeed, at that point, I need a labelling system 
to filter issues. Then I need to keep all the rules of that system in my head 
instead of having the UI guide me — and prevent me from infringing the system...

3. How do we migrate issues history from Trac to GitHub? Preserving comment 
authorship doesn't seem obvious, especially for authors who don't have the same 
username on Trac and GitHub or authors who don't have a GitHub account.

Initially an effort was made to sync usernames of core devs between Trac and 
GitHub to prevent security problems but that's a small subset of contributors.

4. Are we still able to export everything from GitHub and move on to the next 
thing? Perhaps there's an obvious answer. I didn't look. Usually Django takes a 
pragmatic position: we won't reject GitHub outright because it isn't open 
source. However, we wouldn't want to lock ourselves into a platform we don't 
control.

Who would have bet, three years ago, that GitHub would be the property of 
Microsoft today? What if Microsoft sells it to Oracle in three years? It's nice 
to keep our options open :-)

We put the code there because we were confident that we could pull the git 
history. Then everyone started using pull requests, which was likely a good 
thing, but wasn't really planned or thought through, and I don't think we can 
export PR comments meaningfully. GitHub did some good vendor lock in there.

5. How do we preserve links to SVN commits? Currently, they're redirected on 
https://code.djangoproject.com/ with this nginx rule:

    rewrite ^/changeset/(\d+)/?$ https://www.djangoproject.com/svntogit/$1/ 
permanent;

and then redirected again by this application:

    https://github.com/django/djangoproject.com/tree/master/svntogit

It would be nice to preserve these links in issues copied from Trac to GitHub, 
which probably means pre-processing comments to rewrite links.

There may be more, but that's what comes to mind!

A process DEP 
<https://github.com/django/deps/blob/master/final/0001-dep-process.rst#dep-types>
 is the way to go to propose this change.

Best regards,

-- 
Aymeric.



> On 7 Aug 2019, at 08:24, John Gooding <ja.good...@gmail.com> wrote:
> 
> I'd like to propose moving Django issues to github and make a real decision 
> on it here in this thread. If there has been a recent discussion on this I 
> apologize, but searching for issue tracking / github links to about every 
> thread ever posted here.
> 
> I believe this would lower the barrier to entry and to help promote community 
> involvement. People are already there, people already use it, and we already 
> do pull requests there. Now I could be wrong here, but I also feel that it 
> would improve and promote discussion about changes and feature additions to 
> Django, because right now they are pretty hidden away in the current system. 
> 
> I'd also like to see the inclusion of a "discussion" label or similar for 
> issues. I think many of the conversations here on this forum would be much 
> better off as github issues. I see a lot of great stuff, and it's not clear 
> at all what the status is, has it moved forward, been officially denied? etc. 
> If they are github issues they will have definitive resolutions, whatever it 
> may be, and links to relevant code, PR's etc if needed.
> 
> I think there is a huge amount to gain by consolidating the ticket system and 
> many of the discussions on this forum into github's issue tracker. I don't 
> see any reason why it wouldn't be wroth the effort, and we only have much to 
> gain as a community from it. But that's just my 2 cents. I'd love to hear 
> what others think, for or against it.
> 
> John
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/da5ca4b1-fb84-4ed4-b2cb-324b8bea9c42%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/da5ca4b1-fb84-4ed4-b2cb-324b8bea9c42%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/FAD1BB01-AB4C-4ADC-AAB2-16219CFBA43F%40polytechnique.org.
  • ... John Gooding
    • ... Aymeric Augustin
      • ... John Gooding
        • ... Josh Smeaton
          • ... Carlton Gibson
            • ... Andrew Godwin
              • ... John Gooding
    • ... John Gooding
      • ... Carlton Gibson
        • ... Tim Graham
          • ... William Vincent
            • ... '1337 Shadow Hacker' via Django developers (Contributions to Django itself)

Reply via email to