Austin English wrote:
> Anastasius mentioned at
> http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for
> bugs that are caused by applications using broken/deprecated behavior
> might be useful. I'm in favor of it, but wanted some more opinions
> (and potentially a better naming sche
Anastasius mentioned at
http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for
bugs that are caused by applications using broken/deprecated behavior
might be useful. I'm in favor of it, but wanted some more opinions
(and potentially a better naming scheme).
Comments/opinions?
--
-Aus
On Wed, 7 Aug 2013 21:07:29 +0200
Frédéric Delanoy wrote:
>
> There's no win32 keyword ; only win16 and win64
>
> There wouldn't be any use anyway since it would be the default
>
I know; Ken pointed that out. I think I misread win16. Clearly I should not
post before having coffee.
--
Rosa
On Wed, Aug 7, 2013 at 4:30 PM, Ken Sharp wrote:
> +1 from me.
>
> On 07/08/13 15:03, Rosanne DiMesio wrote:
>>
>> As to keyword usage, some of those bugs were tagged with the win64
>> keyword, some weren't. I know there is also a win32 keyword, and perhaps
>> that is meant to be used for the kind
+1 from me.
On 07/08/13 15:03, Rosanne DiMesio wrote:
On Wed, 07 Aug 2013 14:23:53 +0100
Ken Sharp wrote:
Would I be right in assuming you would like to see bugs in 32-bit
applications that are only present in a wow64 WINEPREFIX? Are there many?
Yes. As to how many there are, I've been abl
On 07/08/13 13:59, Rosanne DiMesio wrote:
Can wow64 be added as a keyword to bugzilla? I know we already have win64 as a
keyword, but that's being used for both 64 bit apps and 32 bit apps in a 64 bit
wineprefix. I'm interested in being able to track the latter, as it's hitt
Can wow64 be added as a keyword to bugzilla? I know we already have win64 as a
keyword, but that's being used for both 64 bit apps and 32 bit apps in a 64 bit
wineprefix. I'm interested in being able to track the latter, as it's hitting
increasing numbers of users.
--
Rosanne DiMesio
On Tue, Jun 18, 2013 at 1:02 PM, Rosanne DiMesio wrote:
>
>>
>> NOTOURBUG or 3RDPARTY seem to be the most common.
>>
>
> NOTOURBUG would be clearer to users. We generally refer to things like
> PlayOnLinux, Wineskin, etc. as "third party," so using that could potentially
> cause some confusion.
>
> NOTOURBUG or 3RDPARTY seem to be the most common.
>
NOTOURBUG would be clearer to users. We generally refer to things like
PlayOnLinux, Wineskin, etc. as "third party," so using that could potentially
cause some confusion.
--
Rosanne DiMesio
Austin English writes:
> On Tue, Jun 18, 2013 at 4:12 AM, Alexandre Julliard
> wrote:
>> André Hentschel writes:
>>
>>> +
>>> + The problem is not a [% terms.bug %] in Wine,
>>> + but in some upstream software Wine depends on or broken
>>> + packages in distr
On Tue, Jun 18, 2013 at 4:12 AM, Alexandre Julliard wrote:
> André Hentschel writes:
>
>> +
>> + The problem is not a [% terms.bug %] in Wine,
>> + but in some upstream software Wine depends on or broken
>> + packages in distributions.
>> + Note: Most o
André Hentschel writes:
> +
> + The problem is not a [% terms.bug %] in Wine,
> + but in some upstream software Wine depends on or broken
> + packages in distributions.
> + Note: Most other bug trackers call this "NOTOURBUG".
We should probably rename
On 16 June 2013 01:26, André Hentschel wrote:
> +
> + [% display_value("resolution", "UPSTREAM") FILTER html %]
> +
> +
> + The problem is not a [% terms.bug %] in Wine,
> + but in some upstream software Wine depends on.
> +
I don't care
2013/6/4 Bruno Jesus <00cp...@gmail.com>
> On Tue, Jun 4, 2013 at 12:38 PM, Christian Costa
> wrote:
> >
> > Hi,
> >
> > Minor but shouldn't it be "bug" instead "bugs"?
>
> At least in portuguese zero is plural.
Ta! Mas nao nehum?
> In english according to [1] :
>
> Treatments differ in expre
On Tue, Jun 4, 2013 at 12:38 PM, Christian Costa wrote:
>
> Hi,
>
> Minor but shouldn't it be "bug" instead "bugs"?
At least in portuguese zero is plural. In english according to [1] :
Treatments differ in expressions of zero quantity: English often uses
the plural in such expressions as no inju
Hi,
Minor but shouldn't it be "bug" instead "bugs"?
Christian
On Mon, Feb 27, 2012 at 10:39, wrote:
> Hi,
>
> Somehow I discovered that bugzilla can display the component in a search
> result list. Now I'm using that instead of the useless "assignee" field.
> Here's part of the URL I'm using:
>
> &columnl
Hi,
Somehow I discovered that bugzilla can display the component in a search
result list. Now I'm using that instead of the useless "assignee" field.
Here's part of the URL I'm using:
&columnlist=bug_severity%2Cop_sys%2Ccomponent%2Cbug_status%2Cshort_desc&
Unfo
>>
>> Howdy,
>>
>> We seem to discourage use of the use of 'all' platform/os on bugzilla.
>> While I personally am not opposed to it, in cases where it's obviously
>> true (e.g., http://bugs.winehq.org/show_bug.cgi?id=29901), changing
>> these
Yes, all and other seem redundant. +1 on removing All.
By the way, what happened to merging all the sound components?
J. Leclanche
On Thu, Feb 16, 2012 at 9:09 PM, Austin English wrote:
> Howdy,
>
> We seem to discourage use of the use of 'all' platform/os on bugzilla.
>
Howdy,
We seem to discourage use of the use of 'all' platform/os on bugzilla.
While I personally am not opposed to it, in cases where it's obviously
true (e.g., http://bugs.winehq.org/show_bug.cgi?id=29901), changing
these fields causes unnecessary spam. It would be easier, imho
Vitaliy Margolen wrote:
> I've spent enough time doing so and can tell that you are the first person
> to move _all bugs_ to "unknown" component. And leave them there.
That's a gratuitous conclusion, where did get that idea?
> And that
> all developers can't be expected to read every single b
On Sat, Jan 21, 2012 at 6:22 PM, Vitaliy Margolen
wrote:
> On 01/21/2012 10:07 AM, Jerome Leclanche wrote:
>
>> I think that's the point Henri was trying to make. Most of these
>> components
>> are useless.
>>
>> Sure, you *can* pinpoint every component down, but as Henri said, if you
>> do
>> tha
ent one. It's not an excuse to
disrespect everyone else on this list.
On 01/21/2012 10:01 AM, Dmitry Timoshkov wrote:
> Sorry, but honestly, in order to support an idea if adding/changing
> something in Wine bugzilla one should spend several months actively
> triaging bugs first.
I
e name all of them
> > > "unknown-something" that will help user / bugzilla triage people to
> pick
> > > closer area for SMEs to do more detailed investigation.
> > >
> > > To begin with I propose to create following components:
> > > unk
Saulius Krasuckas wrote:
> > While keywords & components overlap, more generic components will not
> > overlap with specific ones. And if we name all of them
> > "unknown-something" that will help user / bugzilla triage people to pick
> > closer area for
* On Fri, 20 Jan 2012, Vitaliy Margolen wrote:
>
> While keywords & components overlap, more generic components will not
> overlap with specific ones. And if we name all of them
> "unknown-something" that will help user / bugzilla triage people to pick
> cl
On 21 January 2012 03:48, Vitaliy Margolen wrote:
> IMHO, it should be an additional component sound-general, or sound-unknown,
> or better yet "unknown-sound". There are many areas like that, that require
> investigation by a person with knowledge of said area to properly set
> component.
>
Yes,
tivity).
IMHO, it should be an additional component sound-general, or sound-unknown,
or better yet "unknown-sound". There are many areas like that, that require
investigation by a person with knowledge of said area to properly set component.
With Wine growing we can't require every de
On Fri, Jan 20, 2012 at 11:04, Dmitry Timoshkov wrote:
> Henri Verbeet wrote:
>
>> On 20 January 2012 17:25, Dmitry Timoshkov wrote:
>> > If the problem is sound related there are usually some known words in
>> > the summary line describing the problem, why not search for them? Why
>> > do you t
Henri Verbeet wrote:
> On 20 January 2012 17:25, Dmitry Timoshkov wrote:
> > If the problem is sound related there are usually some known words in
> > the summary line describing the problem, why not search for them? Why
> > do you think inventing a new keyword and adding it to the buch of bugs
On 20 January 2012 17:25, Dmitry Timoshkov wrote:
> If the problem is sound related there are usually some known words in
> the summary line describing the problem, why not search for them? Why
> do you think inventing a new keyword and adding it to the buch of bugs
> is easier that correctly form
Andrew Eikum wrote:
> > > Because then I can search for audio-related bugs where the component
> > > is not yet known.
> >
> > If the component is unknown probably there is no need to speculate about
> > the reasons and the source of the bug and investigate the problem instead?
> >
>
> I can't
On Fri, Jan 20, 2012 at 10:40:53PM +0800, Dmitry Timoshkov wrote:
> Andrew Eikum wrote:
>
> > > > Austin English wrote:
> > > > >If no one opposes in the next few days I'll add it/start tagging bugs.
> > > > I'm no more opposed to adding a pseudo-component. I simply
> > > > suggest naming it unk
Andrew Eikum wrote:
> > > Austin English wrote:
> > > >If no one opposes in the next few days I'll add it/start tagging bugs.
> > > I'm no more opposed to adding a pseudo-component. I simply
> > > suggest naming it unknown-audio or unknown-sound instead of
> > > "sound" such that people will hop
On Fri, Jan 20, 2012 at 07:23:42PM +0800, Dmitry Timoshkov wrote:
> joerg-cyril.hoe...@t-systems.com wrote:
>
> > Austin English wrote:
> > >If no one opposes in the next few days I'll add it/start tagging bugs.
> > I'm no more opposed to adding a pseudo-component. I simply
> > suggest naming it
joerg-cyril.hoe...@t-systems.com wrote:
> Austin English wrote:
> >If no one opposes in the next few days I'll add it/start tagging bugs.
> I'm no more opposed to adding a pseudo-component. I simply
> suggest naming it unknown-audio or unknown-sound instead of
> "sound" such that people will hope
On Fri, Jan 20, 2012 at 9:49 AM, wrote:
> BTW, can I rename one of my saved searches?
>
Saving it as a different name (at the bottom of the page) does the trick.
> Thank you,
>Jörg Höhle
>
>
J. Leclanche
isting
quartz, mmdevapi, winealsa, winmm&mci, direct-dmusic and direct-dsound.
Dmitry Timoshkov wrote:
>If somebody is lazy or clueless to set a proper bugzilla component, then
>using the word 'printing' somewhere in the bug summary would do the trick.
Yes. I've sometimes a
Jerome Leclanche wrote:
> I see your point on printing but I disagree on it being "useless". If
> "proper printing" had been a 1.4 milestone, I'm sure whoever would have
> worked on it would find it wonderfully useful.
If somebody is lazy or clueless to set
I see your point on printing but I disagree on it being "useless". If
"proper printing" had been a 1.4 milestone, I'm sure whoever would have
worked on it would find it wonderfully useful.
J. Leclanche
On Fri, Jan 20, 2012 at 9:35 AM, Dmitry Timoshkov wrote:
> Austin English wrote:
>
> > I wo
Austin English wrote:
> I would say this is what components are for, though the point that
> pulseaudio/etc. bugs were filed as -unknown is valid.
>
> If no one opposes in the next few days I'll add it/start tagging bugs.
I'd oppose to adding yet another useless keyword just to avoid setting
ap
On Wed, Jan 18, 2012 at 13:25, Andrew Eikum wrote:
> On Wed, Jan 18, 2012 at 07:03:24PM +, Jerome Leclanche wrote:
>> Any comments?
>>
>
> Seems like a useful idea to me, though I'd defer to the heavier
> Bugzilla users' opinions.
>
> Andrew
>
On Wed, Jan 18, 2012 at 07:03:24PM +, Jerome Leclanche wrote:
> Any comments?
>
Seems like a useful idea to me, though I'd defer to the heavier
Bugzilla users' opinions.
Andrew
> On Tue, Jan 17, 2012 at 1:09 AM, Jerome Leclanche wrote:
>
> > Hi,
> >
>
Any comments?
J. Leclanche
On Tue, Jan 17, 2012 at 1:09 AM, Jerome Leclanche wrote:
> Hi,
>
> Joerg and I exchanged a couple of emails where I proposed a "sound"
> keyword on bugzilla. Reasoning: there are multiple sound components, and
> most of the time, the correct
Hi,
Joerg and I exchanged a couple of emails where I proposed a "sound" keyword
on bugzilla. Reasoning: there are multiple sound components, and most of
the time, the correct component is unknown (or could even be caused by
non-sound components).
Thoughts?
J. Leclanche
ne be opposed to merging the Mac OS X versions (and
>> possibly the Windows versions) in the OS field in Bugzilla? We don't
>> differentiate any other OS, and for Windows, there are very few bugs
>> filed anyway (mostly against the test suite or building on cygwin).
>&g
ly avoiding finding incorrect
>>>> bisect results.
>>>
>>> Yay, that would be even better!
>>
>> While doing some other bugzilla maintenance, I've found where to add
>> custom fields, so a 'regression commit sha1-id' (or other preferred
>> name) field is now a possibility.
>>
>> I'll wait a week for comments before adding it.
>
> Yay! \o/
>
Done.
--
-Austin
'regression' with a commit id would automatically mean
>>> 'bisected'. That would also save time of finding the commit id by looking
>>> at every comment in the bug, and possibly avoiding finding incorrect
>>> bisect results.
>>
>> Yay
lly mean
>> 'bisected'. That would also save time of finding the commit id by looking
>> at every comment in the bug, and possibly avoiding finding incorrect
>> bisect results.
>
> Yay, that would be even better!
While doing some other bugzilla maintenance, I'v
ons) in the OS field in Bugzilla? We don't
> differentiate any other OS, and for Windows, there are very few bugs
> filed anyway (mostly against the test suite or building on cygwin).
>
> So, instead of:
> Windows 3.1
> Windows 95
> Windows 98
> Windows ME
> Windows
This was mentioned a while back, though I can't find the reference on
wine-devel, perhaps it was in #winehackers...
Anyway, would anyone be opposed to merging the Mac OS X versions (and
possibly the Windows versions) in the OS field in Bugzilla? We don't
differentiate any other O
On 05/18/2011 12:03 PM, siro wrote:
This patch don't clear the dinput queue in IDirectInputDevice2WImpl_Acquire
Clearly this is wrong. Of course you can prove otherwise with some tests.
You can also test with native dinput to see if it has the same issue or not.
Vitaliy.
from the report bug page?
> I'm talking about the 2001-era version numbers, before 0.9 even.
I'm not sure if bugzilla allows it, but I'd say it's a good idea if
possible (I assume you mean the page to file new bugs?).
--
-Austin
Wise idea or no?
If not is there at least a way to hide them from the report bug page?
I'm talking about the 2001-era version numbers, before 0.9 even.
-Scott Ritchie
have
>> that discussion as 1) more than one packager would see it, and 2) if
>> we're doing something wrong a developer can tell us too.
>
> Bugzilla is not the best place for discussiions, wine-devel is a better one
> IMHO. Usually the packaging bugs are detected by compar
ackager would see it, and 2) if
> we're doing something wrong a developer can tell us too.
Bugzilla is not the best place for discussiions, wine-devel is a better one
IMHO. Usually the packaging bugs are detected by comparing behaviour of a
pre-packaged Wine version with the one built by a
Sometimes it's not 100% clear whether a problem is in the packaging or
upstream part of Wine, and packaging bugs are just as much legitimate
problems as normal Wine bugs. WineHQ is often the best place to have
that discussion as 1) more than one packager would see it, and 2) if
we're doing somethi
On Mon, Sep 20, 2010 at 5:38 PM, Joerg Schiermeier
wrote:
> ---
> skins/custom/index.css | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/skins/custom/index.css b/skins/custom/index.css
> index 2c40719..bf064c4 100644
> --- a/skins/custom/index.css
> +++ b/skins/cu
---
skins/custom/index.css |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/skins/custom/index.css b/skins/custom/index.css
index 2c40719..bf064c4 100644
--- a/skins/custom/index.css
+++ b/skins/custom/index.css
@@ -7,6 +7,8 @@
}
div#login_box {
position: relative
Hello dear Bugzilla maintainers and administrators,
I am Frédéric "LpSolit" Buclin, the QA lead and one of the two assistant
project leads for the Bugzilla project. You are receiving this email
because you have already been contacted by Max Kanat-Alexander (mkanat)
some time ago whe
e). Some users come straight to bugzilla
from a Google search, and don't even know about the forum, FAQ, etc. It's true
some people don't read, but that's not a reason not to put clearer instructions
for people who do.
--
Rosanne DiMesio
On Sat, Jul 17, 2010 at 10:27, David Gerard wrote:
> You are going to get noise. Stopping people reporting bugs is probably
> not the answer. It's hard enough to get bug reports out of people
> already.
A "Where do I" (of "What do I do when...") section in the FAQ
might help in some cases? (w
ty of a bad comment on Bugzilla
(b) lots of people being unable to post their bugs.
(b) will get the bug count down nicely, but rather misses the point of
having a bug tracker.
You are going to get noise. Stopping people reporting bugs is probably
not the answer. It's hard enough to get b
system configuration, etc...
I agree. I've often exceeded 4 lines in comments.
I see your point. However, should it not be sufficient to state a problem
in ten lines or less? This prevents pasting lengthy logs, statements, etc.
in bugzilla? I'll go with that n
> Very BAD:
> -
> Changelog: This fixes bug #4711
>
> BAD:
>
> Changelog: Change the handling of flags X Y Z because this fixes bug #4711
>
> OK:
> ---
> Changelog: Change a corner case in the handling of flags X Y Z (with tests).
> This resolve the issue from bug #4711.
On 07/16/2010 03:50 PM, Dan Kegel wrote:
So it boils down to disagreements about two things:
- mentioning a bug number when posting a patch
I think this is a misunderstanding. There are different ways of adding
the bug number when posting a patch:
Very BAD:
-
Changelog: This fixes bug
On 16 July 2010 16:31, Dan Kegel wrote:
> Without actual examples, I can't see what you're objecting to.
There are three specific examples in this thread, two of those were
provided by yourself, one was by me. If you read carefully you can
probably find them. I also explicitly spelled the issue ou
On Fri, Jul 16, 2010 at 7:08 AM, Henri Verbeet wrote:
> No, you're mistaking specific instances for the larger issue there.
> What it boils down to is giving bad advice from a perceived position
> of authority. Please don't make me search through the archives to find
> every single specific instan
Luke Benstead wrote:
>Sent: Jul 16, 2010 7:18 AM
>To: Henri Verbeet
>Cc: wine-devel@winehq.org, Dan Kegel
>Subject: Re: Please remove / block user from bugzilla
>
>> How do frequent wine committers, and especially Alexandre, feel about
>> > these two issues?
>
> How do frequent wine committers, and especially Alexandre, feel about
> > these two issues?
> I'd say Alexandre's opinion is pretty clear, as always:
> http://www.winehq.org/pipermail/wine-devel/2010-February/081744.html.
>
>
That's doesn't settle this at all, Alexandre is almost certainly referr
On 16 July 2010 15:50, Dan Kegel wrote:
> So it boils down to disagreements about two things:
>
> - mentioning a bug number when posting a patch
>
> - turning spammy FIXMEs into oneshots
>
No, you're mistaking specific instances for the larger issue there.
What it boils down to is giving bad advic
So it boils down to disagreements about two things:
- mentioning a bug number when posting a patch
- turning spammy FIXMEs into oneshots
These both seem like things reasonable developers could disagree about.
(Indeed, Roderick recently posted a patch with a bug number in the subject line,
http:/
ug. Also,
> SubmittingPatches says:
>
> ===
>
> ...
> Include a description
> ...
> If you're working on a bug in bugzilla, mention the bug number, and
> consider filing a bug if none exists.
>
> ===
>
I'd say that's misinformation. As for "Does this pat
> For reference, there are two basic reasons for not referring to
> bugzilla when sending patches, in the commit log or otherwise. The
> first one is that patches should stand on their own. If the bug
> contains important information that's relevant to the patch, that
> should
'm pretty sure he meant in the email when he emails wine-patches rather
> than in the commit log.
>
Sure. Practically speaking there's no real distinction between those
though, especially not if you're using "git send-email" (recommended)
to send your patches.
For refere
> > - Misha; I told him tests were ok to submit during a code freeze; this is
> true,
> > given that Alexandre accepted tests as last as last Friday. I should
> have
> > told him that tests which add stubs probably aren't ok, but he learned
> > that as soon as he submitted.
> > http://www.winehq.o
didn't mention or ask
for that. What I *would* like to ask is that you don't misrepresent
yourself as somehow speaking for the Wine project, or being an
experienced Wine developer. And just so it's clear, it's perfectly
fine that not everyone is an active developer. Austin and W
gt;>>>>
>>>> 4 lines is horribly short... Especially for posting instructions to
>>>> reproduce problems, an overview of your system configuration, etc...
>>>>
>>>>
>>> I agree. I've often exceeded 4 lines in comments.
>&
;>> 4 lines is horribly short... Especially for posting instructions to
>>> reproduce problems, an overview of your system configuration, etc...
>>>
>>>
>>
>> I agree. I've often exceeded 4 lines in comments.
>>
>>
>
> I see your point. How
ot be sufficient to state a
problem in ten lines or less? This prevents pasting lengthy logs,
statements, etc. in bugzilla? I'll go with that number then.
James McKenzie
James Mckenzie wrote:
> On that vein of thought, why don't we have a code standard page? I've been
> asking this question and maybe this should be my next area of concern after
> the release of Wine 1.2 and the reinput of my patches. This way, I can use
> my 'years of expertise' and what I've l
On Thu, Jul 15, 2010 at 8:45 AM, Dan Kegel wrote:
> - the FIXME_ONCE guy; I think you and I are giving him the same advice;
> http://www.winehq.org/pipermail/wine-devel/2010-July/085069.html
> so that seems fine.
Aha. This is the thread that probably bothered you:
http://www.winehq.org/pipermail
Am 15.07.2010 18:29, schrieb James Mckenzie:
> On that vein of thought, why don't we have a code standard page? I've been
> asking this question and maybe this should be my next area of concern after
> the release of Wine 1.2 and the reinput of my patches. This way, I can use
> my 'years of ex
On Thu, 15 Jul 2010 17:08:30 +0200
Gert van den Berg wrote:
> On Thu, Jul 15, 2010 at 16:23, James Mckenzie
> wrote:
> > Rosanne and you have a good point, but I would restrict it the limit to
> > four lines. You should be able to describe a valid bug in that space.
> > Anything more, and it
Henri Verbeet wrote:
>
>On 14 July 2010 16:26, Dan Kegel wrote:
>> If you ask me,
>> http://bugs.winehq.org/show_bug.cgi?id=6971#c371
>> is more objectionable, because it shows the Wine
>> community to be ill-mannered and hostile to newbies.
>Sure, it could have been worded more carefully, but I
On Thu, 15 Jul 2010 07:09:22 -0700
Dan Kegel wrote:
>
> As you point out, people don't read... it might be more useful to
> put a length limit check so that posting a long comment requires
> privileges. Maybe that could be done as simply as "if this is user's
> first bug, don't let him post mor
On Thu, Jul 15, 2010 at 7:45 AM, Henri Verbeet wrote:
> However, if we're talking about being harmful to the project, I think
> it's far more insidious and actively harmful to pretend being an
> active / respected Wine developer and giving potential new developers
> bad advice from that position.
ially for posting instructions to
reproduce problems, an overview of your system configuration, etc...
If bugzilla supports word-based filtering, looking for words commonly
present in logs and not present in most posts ("fixme:"?) to try and
prevent users from posting logs as comments...
On 14 July 2010 16:26, Dan Kegel wrote:
> If you ask me,
> http://bugs.winehq.org/show_bug.cgi?id=6971#c371
> is more objectionable, because it shows the Wine
> community to be ill-mannered and hostile to newbies.
Sure, it could have been worded more carefully, but I don't buy the
"taints us all"
>> Would it be possible to add a line to the text above the comment entry box
>> (by the "do not paste logs" warning) telling people more explicitly what
>> sorts
>> of comments are appropriate, and directing them to the forum for user
>> support?
>> Yes, I know some people will ignore it anyway,
Rosanne wrote:
> A lot of new users mistake bugzilla for a support forum, and bug reports are
> littered with comments that don't belong there.
Yes, that's a problem.
> Would it be possible to add a line to the text above the comment entry box
> (by the "do not p
On Wed, 14 Jul 2010 07:26:40 -0700
Dan Kegel wrote:
> I only see one post from him ever, and he was *trying* to be
> helpful. Everybody should get a few chances. A warning
> should suffice.
>
Dan,
A lot of new users mistake bugzilla for a support forum, and bug reports are
l
Am 14.07.2010 16:26, schrieb Dan Kegel:
> I only see one post from him ever, and he was *trying* to be
> helpful. Everybody should get a few chances. A warning
> should suffice.
>
> If you ask me,
> http://bugs.winehq.org/show_bug.cgi?id=6971#c371
> is more objectionable, because it shows the W
I only see one post from him ever, and he was *trying* to be
helpful. Everybody should get a few chances. A warning
should suffice.
If you ask me,
http://bugs.winehq.org/show_bug.cgi?id=6971#c371
is more objectionable, because it shows the Wine
community to be ill-mannered and hostile to newbie
Austin English wrote:
>Sent: Jul 13, 2010 10:57 PM
>To: Vitaliy Margolen
>Cc: Wine Develop , matthewdchish...@gmail.com
>Subject: Re: Please remove / block user from bugzilla
>
>On Tue, Jul 13, 2010 at 11:12 PM, Vitaliy Margolen
> wrote:
>> Please remove Matt Chishol
On Tue, Jul 13, 2010 at 11:12 PM, Vitaliy Margolen
wrote:
> Please remove Matt Chisholm from bugazilla
> and/or block him from posting. Also please remove this post:
> http://bugs.winehq.org/show_bug.cgi?id=6971#c370
>
> Vitaliy.
(Repeating my comment from the bug):
While I agree that comment d
Please remove Matt Chisholm from bugazilla
and/or block him from posting. Also please remove this post:
http://bugs.winehq.org/show_bug.cgi?id=6971#c370
Vitaliy.
Greetings,
Help wanted
Re: http://bugs.winehq.org/show_bug.cgi?id=3023
Short summary:
Commenting line 934 of dlls/user32/dialog.c in EndDialog makes OrCad usable.
EndDialog( HWND hwnd, INT_PTR retval )
{
...
// comment the following line
if (hwnd == GetActiveWindow()) WINPOS_ActivateOtherWindow(
> Probably it would be better to add a field for commit id that caused
> a regression just like there is one for url/keywords instead of inventing
> new keywords. So a 'regression' with a commit id would automatically mean
> 'bisected'. That would also save time of finding the commit id by looking
1 - 100 of 734 matches
Mail list logo
