Hey all, every time I do a Bugzilla query, I find the default value for State on the query page to be an annoyance. It would save me a lot of mouse clicks if the State field could either be totally unselected, or at least include the Unconfirmed state by default.
This came up because a QA volunteer complained about how hard it was to start using the Bugzilla query page. This was an annoyance for him, too.
Fixing this would simplify the Bugzilla quick start on my 'Wine needs YOU to triage bugs!' page, http://kegel.com/wine/qa/#tools
How do people feel about the proposed change?
Thanks, Dan
On Tue, 4 Oct 2005, Dan Kegel wrote: [...]
This came up because a QA volunteer complained about how hard it was to start using the Bugzilla query page. This was an annoyance for him, too.
Fixing this would simplify the Bugzilla quick start on my 'Wine needs YOU to triage bugs!' page, http://kegel.com/wine/qa/#tools
How do people feel about the proposed change?
Can't we simply bypass the standard Bugzilla search page altogether? After all, all that's needed is for our custom form to build the right URL. And then the customized form could have an 'Advanced Search' link pointing to the regular Bugzilla query page.
http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_...
From: "Francois Gouget" fgouget@free.fr
Can't we simply bypass the standard Bugzilla search page altogether? After all, all that's needed is for our custom form to build the right URL. And then the customized form could have an 'Advanced Search' link pointing to the regular Bugzilla query page.
I think this is a good idea -- I always found the Bugzilla search page overly complicated a big pain to use. But even if we do that, I think Dan's idea is still good for the 'Advanced' page if it's easily done.
Hello,
Dimi Paun wrote:
Can't we simply bypass the standard Bugzilla search page altogether? After all, all that's needed is for our custom form to build the right URL. And then the customized form could have an 'Advanced Search' link pointing to the regular Bugzilla query page.
That's something, one finds by default in newer Bugzilla versions: http://landfill.bugzilla.org/bugzilla-2.20-branch/query.cgi They actually not only seach in the bug's title, if I recall correctly.
I think this is a good idea -- I always found the Bugzilla search page overly complicated a big pain to use. But even if we do that, I think Dan's idea is still good for the 'Advanced' page if it's easily done.
Yes, by an admin. Simply go to http://bugs.winehq.org/editparams.cgi search for defaultquery and append &bug_status=UNCONFIRMED (or muddle it in somewhere)
Tobias
Tobias Burnus wrote:
Hello,
Dimi Paun wrote:
Can't we simply bypass the standard Bugzilla search page altogether? After all, all that's needed is for our custom form to build the right URL. And then the customized form could have an 'Advanced Search' link pointing to the regular Bugzilla query page.
That's something, one finds by default in newer Bugzilla versions: http://landfill.bugzilla.org/bugzilla-2.20-branch/query.cgi They actually not only seach in the bug's title, if I recall correctly.
I think this is a good idea -- I always found the Bugzilla search page overly complicated a big pain to use. But even if we do that, I think Dan's idea is still good for the 'Advanced' page if it's easily done.
Yes, by an admin. Simply go to http://bugs.winehq.org/editparams.cgi search for defaultquery and append &bug_status=UNCONFIRMED (or muddle it in somewhere)
Tobias
Thanks for the pointer. I did that :^). It was annoying me too but I never thought to changes it...
--
Tony Lambregts
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
Yes, by an admin. Simply go to http://bugs.winehq.org/editparams.cgi search for defaultquery and append &bug_status=UNCONFIRMED
Thanks for the pointer. I did that :^). It was annoying me too but I never thought to changes it...
Thanks! I'll update my QA page to simplify the instructions.
Dan Kegel wrote:
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
Yes, by an admin. Simply go to http://bugs.winehq.org/editparams.cgi search for defaultquery and append &bug_status=UNCONFIRMED
Thanks for the pointer. I did that :^). It was annoying me too but I never thought to changes it...
Thanks! I'll update my QA page to simplify the instructions.
I would like you to rethink puting your QA page onto the wiki. for now I have put a link to it in http://wiki.winehq.org/BugzillaInfo
--
Tony Lambregts
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
I would like you to rethink puting your QA page onto the wiki. for now I have put a link to it in http://wiki.winehq.org/BugzillaInfo
Thanks for the link!
As I said earlier, I'll add my QA page to WineHQ when it's in good shape. It still needs a bit of polish.
Thanks, Dan
Dan Kegel wrote:
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
I would like you to rethink puting your QA page onto the wiki. for now I have put a link to it in http://wiki.winehq.org/BugzillaInfo
Thanks for the link!
As I said earlier, I'll add my QA page to WineHQ when it's in good shape. It still needs a bit of polish.
But this should not go into Wine HQ. Stuff like this should be in the wiki not Wine HQ since it is not a published doc nor a page that is likely to be static (unchanging). We have moved out the Janitorial page and others to the wiki for the same reason.
As for polish it is more likely to get polished there quicker since more people can polish it ;^)
--
Tony Lambregts
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
I would like you to rethink puting your QA page onto the wiki. for now I have put a link to it in http://wiki.winehq.org/BugzillaInfo
As I said earlier, I'll add my QA page to WineHQ when it's in good shape. It still needs a bit of polish.
But this should not go into Wine HQ. Stuff like this should be in the wiki not Wine HQ since it is not a published doc nor a page that is likely to be static (unchanging). We have moved out the Janitorial page and others to the wiki for the same reason.
As for polish it is more likely to get polished there quicker since more people can polish it ;^)
<troll> The text on the wine wiki looks dreadful at the moment. I prefer to keep my pages somewhere where people who don't write well have trouble editing them. </troll>
OK, that's kind of trollish of me, but there's a kernel of truth to it...
Dan Kegel wrote:
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
I would like you to rethink puting your QA page onto the wiki. for now I have put a link to it in http://wiki.winehq.org/BugzillaInfo
As I said earlier, I'll add my QA page to WineHQ when it's in good shape. It still needs a bit of polish.
But this should not go into Wine HQ. Stuff like this should be in the wiki not Wine HQ since it is not a published doc nor a page that is likely to be static (unchanging). We have moved out the Janitorial page and others to the wiki for the same reason.
As for polish it is more likely to get polished there quicker since more people can polish it ;^)
<troll> The text on the wine wiki looks dreadful at the moment. I prefer to keep my pages somewhere where people who don't write well have trouble editing them. </troll>
OK, that's kind of trollish of me, but there's a kernel of truth to it...
http://wiki.winehq.org/BugzillaTriage?action=show
is that really so bad as compared to?
http://kegel.com/wine/qa/#triage.bugzilla
--
Tony Lambregts
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
http://wiki.winehq.org/BugzillaTriage?action=show
is that really so bad as compared to?
Tony, I don't recall giving permission for my text to be copied to the wiki...
We certainly don't want it in 2 places.
BTW
* The "last changed" query is actually "created"
* The "Submit" button should be "Commit"
Richard.
On 10/8/05, Richard Cohen richard@daijobu.co.uk wrote:
- The "last changed" query is actually "created"
I think I corrected it... can you check?
- The "Submit" button should be "Commit"
Got it, thanks!
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
But this should not go into Wine HQ. Stuff like this should be in the wiki not Wine HQ since it is not a published doc nor a page that is likely to be static (unchanging).
I think this ought to be published documentation.
I dislike the implication that only unchanging text should go onto WineHQ.
Wikis are not the only way to write text, no matter what some people think. - Dan (who is evidently a bit cranky today)
Dan Kegel wrote:
On 10/8/05, Tony Lambregts tony.lambregts@gmail.com wrote:
But this should not go into Wine HQ. Stuff like this should be in the wiki not Wine HQ since it is not a published doc nor a page that is likely to be static (unchanging).
I think this ought to be published documentation.
Then it ought to be sgml not html ;^)
I dislike the implication that only unchanging text should go onto WineHQ.
I just think it makes sence to put things that will be changed manually fairly regularily on the wiki. when the janitorial page was on Wine HQ I had to first write a patch and submit it to Wine Patches then Jeremy had to get around to getting it applied. The amount if time it took me was not that great but it took a skill set that not everyone has and it now takes less time to do on the wiki. So I for one am glad it is there. It is still linked to from Wine HQ so as far as I can see It is a win-win.
Wikis are not the only way to write text, no matter what some people think.
Look there is nothing wrong with you writing whatever you want in any format you want, but if you want it included in wine then there is nothing wrong with it being published in the wiki rather than any other site.
At one time the FAQ was in HTML and published on another site when we brought it into Wine HQ I converted It over to SGML for inclusion in the official documentation. About 4 months ago all the sgml was taken out of the tree and put on source forge and is maintained in a separate tree. It may or may not make sense to move the FAQ to the wiki and that is the point. Stuff ends up is where it best fits.
- Dan (who is evidently a bit cranky today)
For future reference: I violently dislike wikis, and generally prefer to work with traditional tools. Please keep that in mind when proposing to move my content to a wiki. - Dan
Dan Kegel wrote:
For future reference: I violently dislike wikis, and generally prefer to work with traditional tools. Please keep that in mind when proposing to move my content to a wiki.
- Dan
Sorry. I was talking about what makes sense for Wine, not personal preferences.
You say you want to contribute this to wine but you also want to put unreasonable restrictions on how we can use it. I, and probably most others do not want to duplicate your efforts. However if we do put it into Wine HQ as html we have to submit patches to keep it up to date and that is also a waste of time and effort that can be better spent elsewhere.
I encourage you to put your dislike of wikis aside if you really want to help in this regard.
--
Tony Lambregts
On 10/9/05, Tony Lambregts tony.lambregts@gmail.com wrote:
You say you want to contribute this to wine but you also want to put unreasonable restrictions on how we can use it. I, and probably most others do not want to duplicate your efforts. However if we do put it into Wine HQ as html we have to submit patches to keep it up to date and that is also a waste of time and effort that can be better spent elsewhere.
I agree that it should be easy to update WineHQ. If it's hard at the moment, that needs to be fixed.
And once my page is ready to go, I won't place any restrictions on where it can be used. I simply can't develop on the Wiki; it's too slow and painful for me compared to a normal text editor. - Dan
Dan Kegel wrote:
On 10/9/05, Tony Lambregts tony.lambregts@gmail.com wrote:
You say you want to contribute this to wine but you also want to put unreasonable restrictions on how we can use it. I, and probably most others do not want to duplicate your efforts. However if we do put it into Wine HQ as html we have to submit patches to keep it up to date and that is also a waste of time and effort that can be better spent elsewhere.
I agree that it should be easy to update WineHQ. If it's hard at the moment, that needs to be fixed.
Submitting patches is not something that needs to be fixed, and I know of no bettter way of updateing the websites! It is not hard but it does require a skill set and resourses to be set up that not everyone has.
In order to make a patch you need a copy of the WineHQ site on your computer. Next php and apache should be installed. Even if you have all that you still need to make the patch and wait for it to be commited. This raises the level of difficulty to the point that most people will not put in the effort and it makes for poorer and out of date documentation.
And once my page is ready to go, I won't place any restrictions on where it can be used.
I truely appreciate you doing that.
I simply can't develop on the Wiki; it's too slow and painful for me compared to a normal text editor.
- Dan
Why is it that slow? Is it that resource hungry or is it your connection speed? I tried it on my old box (the one that took 8 hours to compile wine) and it seemed fine. So it must be your connection speed (I have ADSL).
--
Tony Lambregts
On 10/9/05, Tony Lambregts tony.lambregts@gmail.com wrote:
I agree that it should be easy to update WineHQ. If it's hard at the moment, that needs to be fixed.
Submitting patches is not something that needs to be fixed, and I know of no bettter way of updateing the websites! It is not hard but it does require a skill set and resourses to be set up that not everyone has.
The difficulty I'm seeing is that it takes too long to review patches.
I simply can't develop on the Wiki; it's too slow and painful for me compared to a normal text editor.
Why is it that slow? Is it that resource hungry or is it your connection speed? I tried it on my old box (the one that took 8 hours to compile wine) and it seemed fine. So it must be your connection speed (I have ADSL).
My connection is very fast. One problem is that I'm used to quick iterations, and the time to save on the wiki is lots longer than the time it takes to save in vi.
I've often wished for a hybrid wiki that let users edit it using traditional tools (e.g. svn and vi) in addition to the live web update. Haven't had time to look into it, though. I actually did a wiki-like system back in 1994 that had some of those features - guess I should have kept at it! - Dan
On Sun, 2005-10-09 at 13:53 -0700, Dan Kegel wrote:
My connection is very fast. One problem is that I'm used to quick iterations, and the time to save on the wiki is lots longer than the time it takes to save in vi.
This is obviously the case. I can make the saving be a bit faster for our wiki by giving up on the email notifications (for whatever reason they take a rather substantial amount of time). However, is it that much of a problem? I mean, if you used vi and cvs ci say to maintain the page instead, it will hardly be any faster (in fact, judging how fast cvs works against SF or even WineHQ, it will definitely be slower).
I love vi too and I understand your position -- I think you should use whatever tool you want. However, you were making a very good point a few days ago about Bugzilla, saying that "if you really want to help Wine, please do try to get over your loathing of Bugzilla; it's a perfectly usable tool once you get used to it."
And hey, MoinMoin is certainly no worse than Bugzilla. :)
On 10/9/05, Dimi Paun dimi@lattica.com wrote:
If you used vi and cvs ci say to maintain the page instead, it will hardly be any faster (in fact, judging how fast cvs works against SF or even WineHQ, it will definitely be slower).
That's only true if I get my changes right the first time! But perhaps I haven't really identified the problem I have with wikis. It could also be that I have had too many bad experiences editing documents in web browsers. Now, if the wiki was as responsive and reliable as gmail, maybe I'd feel better. But there's probably more to the story, e.g. I feel more comfortable with formal markup languages, and dislike the baby markup of wikis. Whatever. It's probably not worth arguing about.
I love vi too and I understand your position -- I think you should use whatever tool you want. However, you were making a very good point a few days ago about Bugzilla, saying that "if you really want to help Wine, please do try to get over your loathing of Bugzilla; it's a perfectly usable tool once you get used to it."
Yeah, the irony was on my mind!
And hey, MoinMoin is certainly no worse than Bugzilla. :)
No, there's a real difference: in Bugzilla, one is not even trying to do formatting, it's really plain text. That makes the requirements much lower. There are other differences, too. - Dan
On 10/4/05, Francois Gouget wrote:
Can't we simply bypass the standard Bugzilla search page altogether? After all, all that's needed is for our custom form to build the right URL. And then the customized form could have an 'Advanced Search' link pointing to the regular Bugzilla query page.
[url snipped]
That's assuming that someone wants to search the bug description for one thing and each further comment for something else, which is rarely the case with QA volunteers.
If you want to search for one item, you need two urls:
http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=fo...
and (similar to yours)
http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_...
http://www.google.com/search?q=site%3Abugs.winehq.org doesn't work either, Google does not index the contents of the bugs pages. Not sure why.
On 10/4/05, Molle Bestefich molle.bestefich@gmail.com wrote:
If you want to search for one item, you need two urls:
http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=fo...
and (similar to yours)
http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_...
I suspect that nearly all of the time, it suffices to search in the Comments field (i.e. your first query). How often is that not enough in your experience, Molle?
Thanks, Dan
On 10/4/05, Dan Kegel daniel.r.kegel@gmail.com wrote:
On 10/4/05, Molle Bestefich molle.bestefich@gmail.com wrote:
If you want to search for one item, you need two urls:
http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=fo...
and (similar to yours)
http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_...
I suspect that nearly all of the time, it suffices to search in the Comments field (i.e. your first query). How often is that not enough in your experience, Molle?
To be honest, I've always searched both, starting with the top field. Guess I'm too used to Google to work Bugzilla ;-).
Just tried searching for a couple of items, and I think you're right. Searching comments seems sufficient!
Molle Bestefich wrote:
http://www.google.com/search?q=site%3Abugs.winehq.org doesn't work either, Google does not index the contents of the bugs pages. Not sure why.
See http:///bugs.winehq.org/robots.txt
I think at least the following paths should be opened up to GoogleBot and other indexers:
/buglist.cgi /show_bug.cgi
Then again, I'm not paying for the server, and there might be a concern that a spider could overload it. Still, I wish this information were made indexable; it might cut down of FAQs a bit.
-- DLL