Bug 164969

*** Bug 166931 has been marked as a duplicate of this bug. ***

I think this feature could be very useful, especially when you have to use low resolution screens, or you need as much space as possible (e.g: when you are using development environments). This wish is related:

http://bugs.kde.org/votes.cgi?action=show_bug&bug_id=158556

*** This bug has been confirmed by popular vote. ***

Sorry to report that this doesn't work in TRUNK.

this is why i don't like people re-opening bugs i've closed: 90% of the time they are wrong. i'd rather just re-open the 10% of the time the bug actually has resurfaced.

in this case, you have to *turn on the option in the configuration interface* for it to work. it's not the default, and for pretty obvious reasons i'd say.

btw, i'm still working on the hiding feature set, so you'll find various oddities from time to time in trunk between now and betas. but yeah .. this report is indeed addressed.

You are "begging the bug" -- similar to begging the question.

Might I first say that this is why I don't think that reporting bugs in bugzilla for problems in TRUNK is a good idea (and why the Alpha should start a new BRANCH) -- Plasma in TRUNK is currently too unstable to tell if it works.  We have mailing lists to discuss problems with TRUNK.  But, the problem is that developers have this: "it works in TRUNK so the bug is fixed" idea which I think is crap -- a bug is fixed when it is fixed in an RC and not before.

Now the problem here is that you said: *turn on the option in the configuration interface*.  I don't have any idea what that means or where you are quoting it from.  But, the point is that I doubt that the users got that bulletin.

So, the bug was begged and the new bug is this:

If you go to "Panel Setting -> More Settings" and select: "Window Can Cover" then it doesn't work -- I opened Konqueror and it didn't cover the Panel.  That is the bug that I have observed and that is the bug I am now reopening.  NOTE, title has been changed.

I can confirm this with todays svn. The window does not cover the panel but is put behind the panel.

Sven: you need svn from an hour or two ago. 

and as i said, this is a work in progress and various bits git ironed out week by week. i closed this report because the feature, raw as it was, was put into trunk/. it's easier for me to do that when something hits trunk/ because i'm thinking about it right then (versus when doing random improvements/fixes between hitting trunk/ and a release).

so for the love of $DEITY, stop opening this report. this will be my last request in the matter. thank you.

Note to AJS: Yes, we know that this is a work in progress.

The problem is that your comments are unprofessional -- not useful.

If what I have observed is a regression, you need only tell me which revision number you think has fixed it and I will build >= that revision number and test it.  I will even close the bug if it tests OK.  Instead you make this some sort of argument.  There is no argument about this.  Either it works or it doesn't.

> The problem is that your comments are unprofessional

an open bug repository without a dedicated triage and support team where the reporter (or others who happen to have 'can adjust bug reports') can muck around with reports without consulting the owner of the report is unprofessional. if you want to be treated with "professionalism", start by not loading me with crap a *developer* should not need to deal with.

changing the status of a report without consulting the person who has taken responsibility for it is poor form, and that's precisely what you're getting a response to.

> If what I have observed is a regression, 

... then leave a comment, i'll be cc'd with your comment, and i'll reply to that comment. you don't need to re-open the report or otherwise muck with it.

> I will even close the bug if it tests OK. 

if you want to be opening and closing bugs, then you take responsibility for the report from the start. if i triage a bug, don't try and take over triage from me. it's not a difficult concept.

> Instead you make this some sort of argument. 

i commented as i did because this is *not the first time*.

> There is no argument about this. Either it works or it doesn't.

what you're failing to understand, James, is that i closed this report as part of *my* workflow knowing *precisely* what the state of things is.

the *moment* you are managing my time and defining *my* work schedule, you can't start telling me how to do it. until then, please cooperate so that our time is not spent working at odds to each other. thanks ...

Re: unprofessional Comment #10

I note your rhetorical device: You snipped out my main point which was what I feel that you needed to do to work with other people (to work in a useful and professional manner):

"you need only tell me which revision number you think has fixed it and I will build >= that revision number and test it."

and then made somewhat nonsequitur comments on my statements taken out of the context of my main point.

This seems to be about you and not about the code -- you argue about who will do what with the bug report rather than discussing the problem with the code.  You obviously seem to feel the need to mark your territory.  That is sad, but I get the message: 'NO HELP WANTED'.

I do note that the way my work flow is as follows:

First, I fix the bug.

Second, I test it to make sure it is fixed.

Third, I close the bug report.

Apparently, your work flow involves first closing the bug report.

I really don't understand your trip and I do not understand part of what you said in Comment #5.  My process is simple.  If I find a bug that hasn't been fixed, I reopen it.  Most people would take that as being helpful.

Since I can not work with you as your peer and I will not work as your underling, my only alternative is not to work with you.  I can only presume that this is what you want, but I will do so anyhow because it just isn't worth the aggravation anymore.

Please note, I lost the nail on my right big toe yesterday.  It hurt like hell and perhaps (therefore) I am not in the best mood today. ;-D  My apologies for that.

PS: I tested this with r859189 and it works correctly except that Plasma isn't stable.

> You snipped out my main point

i read your main point and understood it but it was not cogent to the issue of "don't re-open bugs i have triaged, instead comment on them and then i can continue triaging them".

> You obviously seem to feel the need to mark your territory.
> That is sad, but I get the message: 'NO HELP WANTED'. 

you are free to take away any message you wish, but the message i am trying to get across is: 'Please coordinate your efforts with mine.' if you can't manage that, then yes ... i don't want your help.

> I do note that the way my work flow is as follows: 

for defect reports, i work that way too. 

> your work flow involves first closing the bug report. 

this was actually a feature request. i happen to treat those differently: when the feature is merged into trunk, i close the feature request, as that is the most reliable time (e.g. least likely to be missed) to do so.

often features that hit trunk continue to need development and sometimes even exhibit bugs until the feature is release ready. 

what you did here is change the status of the bug without inquiring as to the status of development. the report no longer matched development, resulting in me having to triage the bug again (instead of just very quickly replying via email) and possibly leading another person to look into implementing this feature which is already claimed and which is already in trunk. 

now, this is a new feature that has not been part of a release, not even a beta. and since you can comment on a bug, it's easy to request updates on reports such as these.

it's fairly straightforward coordination and communication, and it keeps things efficient in the mid-term. not having a Q/A management team makes this all a bit more chaotic (or in your terms "less professional") than it should be, and that's why *cooperating* with each other is so important, and why i keep asking for such cooperation.

so, in summary:

* if i change the status of a bug and you feel it has been in error or that subsequent development begs for it to be re-opened, leave a comment to that effect on the report

* that comment will be CC'd to the plasma-bugs list, and i (or someone like me) can confirm and re-open, or clarify and leave it as is

does that make sense?

No, it doesn't make sense.

Specifically, your statement: "don't re-open bugs i have triaged, instead comment on them and then i can continue triaging them" doesn't make sense.

What does make sense is that I made an error when I reopened the bug without changing it from "wishtlist" to "normal" -- an error which I did correct.

I reopened this bug instead of filing a new one.  So, it should be looked at in that context.  You claimed that you had fixed it in your blog of Aug 22.  You stated: "Oh, I also implemented the windows-can-cover-the-panel option. Ta-da."  To me this means that it should have been fixed 3 weeks ago.  So when it still didn't work, a bug report was appropriate.  If I caused confusion by my failure to upgrade this to a defect report, again my apologies.

But, in all cases, all you had to do was state that you thought that it was finally fixed with r<revision_number>.  I would have built >= that revision and tested it and taken appropriate action.  End of story (the professional way to do it).

Instead you start a pissing contest.  You claim that I am causing you crap and telling you how to work, when, in fact, you are doing same to me.  I would suggest that your workflow with feature requests could use some improvement.  I suggest this since most people will think that "RESOLVED FIXED" means that it is fixed.  Especially after _three_weeks_ have passed since you blogged that it was implemented.  So, I would suggest the same work flow (I stated) be used for feature requests except that you might want to add a comment to the bug that you are working on it.  I suggest this because there is no way to tell this otherwise.

Although this was a one bug only issue this time.  Please consider that someone was going through bugs with bugbuster (as I have done in the past).  Are you suggesting that instead of dealing with each bug on its face that they should send the assignee an email before taking action?  And, please note that it is not assigned to AJS personally, it is assigned to the list (IIUC, this is done automatically by bugzilla).  No way to know that you are working on it at all by looking at the bug.

Now, if you had reassigned the bug to AJS personally and/or left a comment that you were working on it, I might have been remiss in not contacting you.  I say might have been because there is, in this case, the additional data point of your blog.

Clearly, if you had left the wishlist item open with a comment that you were working on it, there would have been no problem.  You clearly created an issue by marking it as fixed before it was actually fixed -- well DUH!

"Are you suggesting that instead of dealing with each bug on its face that they should send the assignee an email before taking action?"

as i've said in two prior comments to this report: i'm suggesting that you leave a comment on the bug. that results in an automatic email to the plasma bugs list.

"the additional data point of your blog."

my blog is not where i coordinate development, nor should you use it as such.

"You clearly created an issue by marking it as fixed before it was actually fixed"

as you are insistent on working the way you want to work which happens to be at odds with the way i work, please don't deal with any Plasma reports on bugs.kde.org in the future. there are many other projects in KDE that can use your time and energy.

thanks.

I have made what I think are good suggestions about how we might avoid misapplication in the future.  You do not seem to find any merit in these, but rather expect for me to know things that only you know.  Since I am not psychic, I am unable to do that.

I will not comment further on BugZilla.  If you want to start a thread on KDEQuality to try to write a general policy about how to best handle bugs in TRUNK I will join you there.  If such a policy is then posted in an appropriate place, I will try to follow it.  We all make errors as I stated above with my apologies so I could not guarantee that I would follow it, only to do my best.