[racket-dev] Migrating the bug database to GitHub
I don't know if it is worth going this route, but SirMail can pull out
attachments already, so the libraries are there.
Robby
On Mon, Mar 19, 2012 at 12:41 AM, Eli Barzilay <eli at barzilay.org> wrote:
> Three hours ago, Sam Tobin-Hochstadt wrote:
>> On Sat, Mar 17, 2012 at 10:55 AM, Eli Barzilay <eli at barzilay.org> wrote:
>> > The real issue is whether it's really alright with you...
>> > Currently, something that I do and I'm sure others do it to, is
>> > keep the bug in my mailbox with any followup discussions. In some
>> > cases the followups contain enough information so I'll keep only
>> > that and not the original. With the github thing, if you get to
>> > deal with a bug several days after it was posted, it will be a
>> > good idea to check the bug since there could have been
>> > clarifications that you're unaware of.
>>
>> This is regularly the case with bugs in Gnats currently, although
>> probably less often than on GitHub. If you don't cc
>> bug-notification, then only the assignee and the reporter see the
>> email, which is *fewer* people than on GitHub.
>
> Right -- and "less often" is the key point here, since the convention
> is to use reply-all.
>
>
>> This is also more significant for contributors not among the people
>> who are on the bug-notification list. Right now, they won't be
>> notified at all about changes to gnats bugs unless they're the
>> submitter. With GitHub, all commenters are treated the same.
>
> That part is very easy to fix: change `bug-notification' to a public
> mailing list that anyone can subscribe to. (But that's obviously too
> much since you'd get everything from it, obviously making the github
> workflow better for such people.)
>
>
>> > And since attachments were mentioned: a possible situation is that
>> > someone posts a bug, the bug czar asks for some clarification, and
>> > the email reply has a screenshot which GH ignores. In that case
>> > you will need to get that attachment directly from one of the
>> > people. The outcome of this is that it's better to leave stepper
>> > bugs for you to deal with instead, and the "bug czar" role is
>> > minimized to just assigning bugs or maybe not even that and it
>> > gets eliminated.
>>
>> This is not how I envision the process working. Instead, I hope
>> that people use services like `gist.github.com' and `imgur.com' to
>> post large documents and images, and embed links in bug emails.
>> This makes the online record much more useful -- gnats storage of
>> email attachments is very difficult to work with. I hope to provide
>> command line tools and/or DrRacket tools to make this easy.
>
> Yeah, I considered some of these: gist and imgur have easy APIs,
> alternatively, we can setup a simple server for uploading random files
> (also easy to avoid spam: make sure that contents have links from bug
> messages).
>
> The main flaw in all of this, which is how the above scenario plays
> out, is a submitter that just replies to an email with an attachment,
> since going through such tools is inherently an added hassle.
>
> This could be resolved by making the notification emails reply-able,
> and have a script that identifies attachments and saves them on
> whatever. Parsing emails is a bunch of work though.
>
>
>> As to the "bug czar" role (which I currently have), I think of my
>> role as to facilitate people working on software, including fixing
>> bugs. I've planned this move to GitHub because I think it will help
>> both me and other people developing Racket with doing this. As part
>> of that, I still plan to triage every bug to someone, and to be
>> responsible for contacting bug reporters. I don't think this is a
>> role that will go away -- bugs need human supervision, and I'm
>> planning to continue providing it.
>
> (If you plan to interact with submitters, then you should really be
> clear on how to avoid such problems.)
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://barzilay.org/ Maze is Life!
>
> _________________________
> Racket Developers list:
> http://lists.racket-lang.org/dev