Known issues area on main wiki page

[Tom Spear]

On 3/21/06, Vitaliy Margolen <wine-devel at kievinfo.com> wrote:
>
> Tuesday, March 21, 2006, 8:38:48 AM, Tom Spear wrote:
> > On 3/21/06, Robert Reif <reif at earthlink.net> wrote:Tom Spear (Dustin
> Booker, Dustin Navea) wrote:
>
> >> Jesse Allen wrote:
> >>
> >>> On 3/20/06, Mike McCormack <mike at codeweavers.com> wrote:
> >>>
> >>>
> >>>> Dimi Paun wrote:
> >>>>
> >>>>
> >>>>> On Mon, 2006-03-20 at 22:28 -0600, Tom Spear (Dustin Booker, Dustin
> >>>>> Navea) wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> clicking on the audio tab to check out bug 4051 first? Please!
> >>>>>>
> >>>>>
> >>>>> How about we fix the problem instead? :)
> >>>>>
> >>>>
> >>>> The best way to fix it is probably to rearrange the code so that the
> >>>> Audio tab shows, then there's a [Detect] button that the user can
> click
> >>>> to run the autodetect code that might crash.At least then the user
> >>>> can
> >>>> set their Wine Audio settings manually.
> >>>>
> >>>> Mike
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> This is not enough, as when I click the audio tab, it will lock up in
> >>> the kernel.I already identified where it happens and patch the
> >>> kernel myself.I told the ALSA devs, but they haven't looked at why
> >>> certain register usage causes a lockup.So it remains in the stable
> >>> kernel who knows who else hits it.
> >>>
> >>> Jesse
> >>>
> >>>
> >>
> >> Which is why I agree with the ideas from Mike and Dimi AND Segin..
> >> Why not put an autodetect button, have the exception handler catch the
> >> crash if arts decides to die, and then still have a popup dialog for
> >> when arts is manually selected that tells users it is buggy and not
> >> recommended to use?That doesn't fix your specific problem Jesse, I
> >> know, but at least it keeps winecfg open when you click on the audio
> tab.
> >>
> >> Tom
> >>
> >>
> >>
> > The reason I added the probe of all drivers in winecfg was so that the
> > broken and marginal drivers would get used and hopefully fixed.Moving
> > the problem will just create different bugs: [BUG xxx] winecfg crashes
> > when autodetect button pressed or [BUG yyy] winecfg crashes when driver
> > xyz selected.
>
>
>
>
>
> > Yes, and I agree that that is a good idea, which is why I asked
> > about putting a known issues page somewhere where a lot of users will
> > see it. It wouldnt just have to be used for the issue mentioned
> > above. It could be done for anything that is frequently reported. I'm
> > going to go ahead and get started on putting it in tonight. Since it
> > will be in the wiki, as the issues are fixed, they can be removed, and
> > as other issues become more frequently reported, they can be added. I
> > think it will be a good supplement to bugzilla and the appdb, as more
> > people check out wiki's (as well as README's) than do the appdb, and so
> > therefore they will see that the issue is already reported, and can
> > find out what bug # it is instead of filing a duplicate bug. It also
> > helps cut down on the number of bug submissions in the comments of the
> > appdb..
>
> I sure hope all users will go look at this page first. But some how I
> don't think they will. When we getting _exact_ duplicates with the same
> summary and almost identical comments. I don't think users will bother to
> look anywhere else.
>
> But that will add extra work on our side to keep this list in synch. On
> top of the usual stuff that we already do.
>
> Vitaliy.
>
>
>
>
>
It wouldnt take much extra time outta my day to do it.  5 mins at max and
only once I notice something is being reported rather frequently.  I assume
that these people who are reporting identical duplicates read some of the
dodcumentation though, because otherwise they probably wouldn't have even
known about winecfg.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20060321/fe5f7453/attachment.htm