perfect! -Tom
On Thu, Nov 17, 2011 at 1:00 PM, Charles Oliver Nutter <head...@headius.com> wrote: > On Thu, Nov 17, 2011 at 8:03 AM, Thomas E Enebo <tom.en...@gmail.com> wrote: >> I completely agree bugs like 'Math spec failing' suck since they don't >> really tell you what is broken and they also are also possibly >> open-ended depending on when we update our spec tags. > > And we often have tags disappear without realizing we'd opened one of > those pointless bugs. Then we have "leaked" bugs into the tracker as a > result. > >> I would like an issue filed at least for issues which we are working >> that fixes an invidual spec/expecation. I want this so we can report >> what got fixed when we put out a release. So this is sort of like >> your #2 but it is not dependent on useful discussion happening. We >> could do this so that if you fix a spec you also open a bug to >> indicate you are fixing it and then it doubles as documentation. So >> these issues only show up when someone tried to tackle fixing an >> individual spec failure. If they cannot finish we at least capture >> some information explaining what difficulties they ran into. >> >> So I still want people creating issues for spec failures, but I want >> them more fine-grained to capture individual problems and I only want >> them created if: >> a) You are a developer trying to fix the issue >> b) You are a user who ran into a real world issue and you happen to >> think fixing a particular spec error will fix your real world issue. > > I think we're saying the same thing. So I'll try to summarize: > > DO NOT: > > * File a bug for a spec failure just because it's failing, such as > when updating specs. > > DO: > > * File a bug for a spec you're working on or will fix for a release. > Basically, give us something we can show in release notes. > > * File a bug if there's a real-world user issue caused by a spec > failure. Generally, this will involve code *outside* RubySpec, and > have a reproduction using that code. > > We can still proceed to resolve/incomplete the "dummy" bugs that serve > no actual purpose right now, especially if they've had no activity for > a long time. If you're working on a specific "dummy" spec bug, reopen > or add a comment so we don't resolve it. > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
