[racket-dev] Migrating the bug database to GitHub

For what it's worth, github-flavored markdown (used in issues and
pull requests) does let you embed inline images and
syntax-highlighted source code, written like this:

![Alt text](http://imgur.com/.....jpg)

````scheme
(lambda (foo)
  ;; scheme source here
  ...)
````

You can see an example in this really old pull request:
https://github.com/plt/racket/pull/68

So yes, there's no attachments, but we don't lose the ability to
add inline images and source code at least.

See also: http://github.github.com/github-flavored-markdown/

19 minutes ago, Sam Tobin-Hochstadt wrote:
> Summary: I'm preparing to switch the Racket bug database to GitHub.
> At the end of this email, there's a long list of reasons why (and a
> few limitations).
> 
> Action: Please visit http://samth2.ccs.neu.edu:8080/github-auth/ to make
> it possible to associate your existing bugs with your GitHub account.
> 
> =======
> 
> Going forward: we're going to switch from maintaining our own bug system
> to using the Issues database provided by GitHub.  All existing bugs
> (except "bogus" bugs) will be migrated, with all of their data.  We will
> keep most of the features we currently have, as well.
> 
> Here's how it will work in the new system:
> 
> 1. You'll be able to enter a GitHub username and password in DrRacket to
>    post bugs as your GitHub user.  For people who don't do this (mostly
>    for people who don't have a GitHub account), the bug will be
>    submitted using a GitHub account that is specifically set up for this
>    purpose.  In the latter case, the bug will show up on the GitHub
>    system as coming from that account, but the bug text will have the
>    original email for notifications.
> 
> 2. If you use a GitHub account to create a bug, notifications for
>    changes to the bug will be sent to you as usual from GitHub.  For
>    non-GitHub bugs, a script that gets bug change notifications will
>    send out emails to the original email that was used to submit the
>    bug.
> 
> 3. If you currently have an account that lets you edit the Racket bug
>    database (you should already know if this applies to you), you will
>    need to setup a GitHub account if you don't already have one.  You
>    will be able to edit bugs from the GitHub web interface, just as you
>    could from the Gnats web interface.  You will automatically be
>    notified of new bugs, and you can control this via GitHub.
> 
> Action: get a GitHub account if you don't have one already, and send the
> account name to me.
> 
> That's it!  It's really pretty simple.
> 
> =======
> 
> Migration:  The hard part in all of this is migrating the existing
> bugs.  Fortunately, with a bunch of help from Eli, I've managed to
> parse the entire existing Gnats database, and use it convert the
> existing bugs to the data formats that the GitHub API expects.
> 
> You can see samples of the results at the following bugs:
> 
> https://github.com/samth/test-bugs/issues/170
> https://github.com/samth/test-bugs/issues/171
> https://github.com/samth/test-bugs/issues/172
> https://github.com/samth/test-bugs/issues/173
> https://github.com/samth/test-bugs/issues/174
> https://github.com/samth/test-bugs/issues/175
> https://github.com/samth/test-bugs/issues/176
> https://github.com/samth/test-bugs/issues/177
> https://github.com/samth/test-bugs/issues/178
> https://github.com/samth/test-bugs/issues/179
> https://github.com/samth/test-bugs/issues/180
> 
> As you can see, some of the parts of the bugs are formatted in
> fixed-width font, as for code, and some not.  In general, for open
> bugs I made all these decisions manually, and for closed bugs I used
> heuristics.  I may be able to improve these heuristics before I do the
> final migration.
> 
> However, as you can see, all of these bugs as submitted by the same
> GitHub user.  To fix this, I need to be able to link your email
> address and your GitHub username, and to be able to post bugs as under
> your name.
> 
> Action:  If you want bugs you have submitted or commented on to be
> associated on GitHub with your account there, then please visit:
> 
>   http://samth2.ccs.neu.edu:8080/github-auth/
> 
> and follow the directions there.  Please include *all* the email
> addresses you've used to submit bugs, including really old ones.
> Don't worry if you miss some, though -- I'll do my best to figure out
> the missing ones, and you can visit the site as many times as you
> want.
> 
> ======
> 
> I'd like to thank Eli for his invaluable assistance with all of this.
> 
> Feedback and suggestions on any aspect of this is encouraged.
> 
> =======
> 
> What do we get from using GitHub issues?
> 
>   * Enabling community interaction.  GitHub is where the developer
>     community is, and switching to GitHub makes it much easier for
>     other people to contribute.
> 
>   * A working, maintained system.
> 
>   * Simple, modern web interface.
> 
>   * Simple label-based interaction with bugs.
> 
>   * Various GitHub-related tools that exist now, and will be made in the
>     future.
> 
>   * Commit-based bug closing, similar to what we have with Gnats.  See
>     https://github.com/blog/831-issues-2-0-the-next-generation for
>     details.
> 
>   * References to bug numbers are highlighted in commit messages when
>     viewed via the github interface.
> 
> What do we lose from the switch?
> 
>   * Complete control over the aspect of the bug system.  (But losing
>     this makes the first advantage above.)
> 
>   * The bug notification-turned-mailing-list interaction aspect of Gnats
>     is mostly lost.  GitHub sends out notifications when a bug is
>     created, but it will *not* send out further comments unless you're
>     participating in the discussion (i.e., you sent a comment on the
>     issue).
> 
>     - This makes for the most major workflow change: instead of relying
>       on your mailbox for all bug-related activity, you *will* need to
>       use the GitHub (web) interface.
> 
>     - Note: it is possible to set up the listening script to send out
>       notifications for all updates.  However, doing this means that you
>       will get these notifications in addition to the GitHub emails,
>       making it impractical.
> 
>     - GitHub notifications are reply-able: such replies are properly
>       recorded as comments on the bug.  However, attachments are
>       currently *discarded* from these replies.
> 
>   * Notifications sent out by the changes-listening script will send
>     their reply to a special email address, which I will have to
>     monitor and copy manually to the bug site.
> 
>   * As of yet, there is still *no* support for attachments.  Screenshots
>     etc will need to happen off-line.  Gnats had bad support for
>     attachments which was practically never used, but we have used
>     emails for such cases.  This is therefore a lost feature.  (Note
>     that there is no rejection of attachments on the GitHub side, it
>     might be added, eventually.)
> 

-- 
Take care,
    _mike