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 <e...@barzilay.org> wrote: > 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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
