Three hours ago, Sam Tobin-Hochstadt wrote:
> On Sat, Mar 17, 2012 at 10:55 AM, Eli Barzilay <e...@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
