re: Please remove / block user from bugzilla
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 newbies. - Dan
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 Wine community to be ill-mannered and hostile to newbies. - Dan +1, google has a nice video to that topic: http://video.google.com/videoplay?docid=-4216011961522818645#
-- Best Regards, André Hentschel
On Wed, 14 Jul 2010 07:26:40 -0700 Dan Kegel <dank(a)kegel.com> 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 littered with comments that don't belong there. 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, but it might help cut down on the noise. -- Rosanne DiMesio <dimesio(a)earthlink.net>
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 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, but it might help cut down on the noise.
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 more than ten lines".
On Thu, 15 Jul 2010 07:09:22 -0700 Dan Kegel <dank(a)kegel.com> 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 more than ten lines".
It's not just a question of length, but of inappropriate content. The long inappropriate comments are more annoying, but the short ones ("I'm a newbie. How do I apply this patch?") don't belong in bug reports either. -- Rosanne DiMesio <dimesio(a)earthlink.net>
On 14 July 2010 16:26, Dan Kegel <dank(a)kegel.com> 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" theory.
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. Because what happens is that those people take that advice in good faith, start writing patches, and perhaps even develop some habits based on it. But when those patches then hit wine-patches and get shot down during review, it's the reviewers that get blamed for being "picky" or "harsh", while in some cases the entire premise on which those patches are based is simply wrong. I think that does far more harm to new developers than "being mean to someone on the internet". Of course with Wine being an open project there's not a whole lot we can do about people saying whatever they like, except perhaps teaching potential new developers about things like "git shortlog -s -n --since={5year}".
On Thu, Jul 15, 2010 at 7:45 AM, Henri Verbeet <hverbeet(a)gmail.com> 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. Because what happens is that those people take that advice in good faith, start writing patches, and perhaps even develop some habits based on it. But when those patches then hit wine-patches and get shot down during review, it's the reviewers that get blamed for being "picky" or "harsh", while in some cases the entire premise on which those patches are based is simply wrong. I think that does far more harm to new developers than "being mean to someone on the internet".
I'm listening. Can you give some examples of problems I've caused? Candidates include - 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. - 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.org/pipermail/wine-devel/2010-June/084632.html so that seems fine. Would you really prefer I retire from Wine? - Dan
On Thu, Jul 15, 2010 at 8:45 AM, Dan Kegel <dank(a)kegel.com> 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/wine-devel/2010-June/084309.html (and here's where you explained your position: http://www.winehq.org/pipermail/wine-devel/2010-July/085070.html ) The advice I gave him was
I'd suggest starting by looking at http://bugs.winehq.org/show_bug.cgi?id=15435 "Wine logs too verbose, quieter fixme's needed" and sending in a patch to make one of the overly-verbose fixme's a bit quieter. ...
... [ok, can I change FIXME itself?] changing FIXME itself might be going a bit too far during the current code freeze. You could try adding a FIXME_ONCE macro, though, and use it to quiet some particular message that really gets in the way of (i.e. slows down) a real application.
I agree that Max's patches and behavior so far haven't been up to snuff, but I'm trying to guide him towards the light in private email (e.g. "The thing to do is to wait until after wine-1.2 is released next week, and then submit your original patch plus a few (say, three) patches to fix existing ad hoc fixme-once instances. Your goal should be to *not* change behavior of wine with this set of patches, but rather make the code more readable and simple.") (And later, people who are experts at the various DLLs can go look at the FIXME_ONCEs, and deal with the underlying problem properly.) I agree that any automated way of finding problems, be it compiler warnings, valgrind warnings, or log messages, tends to attract people who try to "fix" them without understanding the underlying issues, with sometimes terrible results, and that one should guard against this and discourage newbies from changing things they don't actually understand. - Dan
On 15 July 2010 17:45, Dan Kegel <dank(a)kegel.com> wrote:
I'm listening. Can you give some examples of problems I've caused? Candidates include
- 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.
As you noted in your other mail, the problem with what you're telling him is mostly that you're telling him to work on a bug like 15435 at all. You might as well have told him to work on "fixing" coding style or naming conventions.
- 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.org/pipermail/wine-devel/2010-June/084632.html so that seems fine.
From the look of things Misha will be ok, but I imagine he would have been anyway.
But there are also cases like e.g. http://bugs.winehq.org/show_bug.cgi?id=21233#c8 where you completely miss the real issues in the patch, and instead recommend referring to a bug number in the commit log, if not directly putting in a link. Alexandre has told people several times in the past not to do that, and I believe even to you yourself. Now it turns out Mikko didn't do that, but listening to that advice would have hurt that patch more than it would have helped. This is of course not a new thing, you've been doing that for at least as long as I've been contributing patches, but the difference is that previously you didn't give a damn about Direct3D or D3DX, focusing on real, useful applications and associated APIs instead. That means this was mostly Alexandre's problem, and whoever happened to be the relevant module maintainer, if any. Alexandre and most other Wine developers are much nicer people than me, and Alexandre enjoys rejecting patches anyway. But *I* care about Wine's Direct3D, so I'm saying something about it.
Would you really prefer I retire from Wine? I haven't given that much thought, mostly because I don't think it's an option that has a realistic chance of happening, either way. More importantly, the "really" there is misleading, I 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 Wylda for example do lots of useful work in bugzilla, without primarily being developers. But if you're giving people development advice, or are trying to influence development direction, you'd better make sure that you actually know what you're talking about. (And no, you're certainly not the only person giving questionable development advice either. I'm mostly pointing this out because you started pointing fingers.)
- 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.org/pipermail/wine-devel/2010-June/084632.html so that seems fine.
From the look of things Misha will be ok, but I imagine he would have been anyway.
But there are also cases like e.g. http://bugs.winehq.org/show_bug.cgi?id=21233#c8 where you completely miss the real issues in the patch, and instead recommend referring to a bug number in the commit log,
Probably not my place to wade in here, but that's not true, he didn't mention the commit log: "Be sure to mention in the post that it fixes http://bugs.winehq.org/show_bug.cgi?id=21233" <http://bugs.winehq.org/show_bug.cgi?id=21233> I'm pretty sure he meant in the email when he emails wine-patches rather than in the commit log. I've got to say Henri, I think you are being a little unfair here. Yes, possibly Dan has given flawed advice in the past, but it's nothing that a private email or chat on IRC wouldn't have solved. Launching into a tirade against him publically isn't helping anything, all these instances are Dan trying to help out, quite obviously not to be "insidious" or to harm the project. Luke.
On 16 July 2010 12:26, Luke Benstead <kazade(a)gmail.com> wrote:
Probably not my place to wade in here, but that's not true, he didn't mention the commit log:
"Be sure to mention in the post that it fixes
http://bugs.winehq.org/show_bug.cgi?id=21233"
I'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 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 be included directly in the commit log. If it doesn't, well, the reference it just redundant. The other reason is that it's not unlikely that the commit log will outlive bugzilla. I.e., you can't depend on bugzilla always being there. That's essentially the same reason as for not including hyperlinks in comments, although at least the source code can easily be changed, while for the commit log that would be a serious pain.
I've got to say Henri, I think you are being a little unfair here. Yes, possibly Dan has given flawed advice in the past, but it's nothing that a private email or chat on IRC wouldn't have solved.
Launching into a tirade against him publically isn't helping anything, all these instances are Dan trying to help out, quite obviously not to be "insidious" or to harm the project.
"Insidious" doesn't imply intention, nor did I claim intention anywhere else. I'm sure Dan (like others) is just trying to help people get their patches committed. But then, I don't think Vitaliy is thinking "Let's have some fun being rude to people in bugzilla" either. That doesn't change the fact that I *do* think both of those hurt the project, or at best just irritate people. As for "tirade", I think the discussion has been fairly civil so far, and I also think wine-devel is the correct place for issues like these.
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 be included directly in the commit log. If it doesn't, well, the reference it just redundant. The other reason is that it's not unlikely that the commit log will outlive bugzilla. I.e., you can't depend on bugzilla always being there. That's essentially the same reason as for not including hyperlinks in comments, although at least the source code can easily be changed, while for the commit log that would be a serious pain.
I am confused. Following this list only, I so far did not notice someone saying "don't tell the bug number" (ok, might be my fault), but a few times asking the question "does this patch fix an actual" bug. 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. === Maybe this is a misunderstanding of terminology? 'commit log' is for me the combination of the single-line 'header' plus the 'description', which can be multiple paragraphs. (and is usually dropped when patches are imported to the official repo. Why is that BTW?) I would agree, that the bug number should not be in the header, but having it as additional information besides the regular description should not really hurt? Kind regards, Wolfram
On 16 July 2010 14:10, Wolfram Sang <wolfram(a)the-dreams.de> wrote:
I am confused. Following this list only, I so far did not notice someone saying "don't tell the bug number" (ok, might be my fault), but a few times asking the question "does this patch fix an actual" bug. 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 patch fix an actual bug?", I could see how that may confuse someone, but you should generally interpret that as "Does this fix a real issue in the code.", or "Are there any real applications that care about this.", as opposed to the patch making a style change, changing something that applications don't care about in practice, or only fixing a perceived bug because the patch author simply misunderstood the original code. An associated bug in bugzilla is not required for patches, and if the patch is good and gets applied it would only serve to spam wine-bugs, which is already a fairly high-volume list these days. I suppose you could open a bug if the patch gets rejected and the issue turns out to be too hard to fix though.
Maybe this is a misunderstanding of terminology? 'commit log' is for me the combination of the single-line 'header' plus the 'description', which can be multiple paragraphs. (and is usually dropped when patches are imported to the official repo. Why is that BTW?) I would agree, that the bug number should not be in the header, but having it as additional information besides the regular description should not really hurt?
If parts of the description are dropped, that's usually because they're considered superfluous. E.g., should be obvious from the patch itself, should be obvious for someone familiar with the code, etc. It should be pretty rare for a patch to need more than a couple of lines as a description. It's of course possibly that the issue you're fixing is really subtle / tricky, but in that case it probably makes more sense to document that in a comment directly in the code. Chances are though that if your patch *needs* a long description it's because it's trying to do too much at once, or tries to do it in a way that's too complicated.
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://www.winehq.org/pipermail/wine-patches/2010-March/086152.html ) How do frequent wine committers, and especially Alexandre, feel about these two issues? - Dan
On 16 July 2010 15:50, Dan Kegel <dank(a)kegel.com> 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 advice from a perceived position of authority. Please don't make me search through the archives to find every single specific instance.
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://www.winehq.org/pipermail/wine-patches/2010-March/086152.html )
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.
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 referring to the bug number in the patch itself there, rather than the subject line. Luke.
On Fri, Jul 16, 2010 at 7:08 AM, Henri Verbeet <hverbeet(a)gmail.com> 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 instance.
Without actual examples, I can't see what you're objecting to. - Dan
On 16 July 2010 16:31, Dan Kegel <dank(a)kegel.com> 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 out three times. I think that should be enough for you to be able to figure it out. I'd suggest to take all this as valuable advice, but you're of course also free to ignore it.
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 #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. The bug number is *only* additional information. It isn't the justification for a patch and definitely not the sole changelog. bye michael
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.
The bug number is *only* additional information. It isn't the justification for a patch and definitely not the sole changelog.
ACK. This was my rationale until two hours ago ;)
participants (7)
-
André Hentschel -
Dan Kegel -
Henri Verbeet -
Luke Benstead -
Michael Stefaniuc -
Rosanne DiMesio -
Wolfram Sang