On IRC we started a chat on #WineHQ and discussed how to improve Wine. There were comments made and I wanted to summarize them and ask for your opinion. By the way: Who is in charge of WineHQ, AppDB etc.? A list of people who are responsible for that would be nice (it could be I've missed that one though).
Back onto the main topic. Remarks made: 1. AppDB needs a revamp. Maybe drop the maintainers (those things just need to be set by developers only). Just have a look at the activity of all the maintainers in the last year. **Read on for suggestions to drop the AppDB.
2. Create a Wine forum. This solves the problem of users asking the same questions over and over again. Here also the "comments" of the AppDB could be centralized (because most of them aren't really comments)
3. With a forum in place, the user-mailing list could be dropped and maybe also even the devel-mailing list.
4. Create a Wine Wiki, instead of the AppDB. Only certain developers (or maybe users) can set/edit certain pages. Then also howto's could be inserted here.
5. It's too difficult for users to add a bugreport. Either create a small program/app which does it for the user (like "Submit this bugreport" *click*) and you're done. The other option is to create a simplified method for searching and inserting a bug report, because from a users view, there are too many options. (and probably the user wouldn't even know what to click on. Don't forget to give the users the option to 'add' a file with certain 'debug channels' (which ones? only +seh?)
6. Users need to know that if they submit a bug report (when it's simplified) that it actually HELPS you, the developers. So it's "Help us, help you".
What's your opinion about this? In my eyes, it would greatly improve the user input/feedback and would even make Wine more popular.
Regards,
SWAT
Le lundi 09 janvier 2006 à 15:47 +0100, S. Schauenburg a écrit :
On IRC we started a chat on #WineHQ and discussed how to improve Wine. There were comments made and I wanted to summarize them and ask for your opinion. By the way: Who is in charge of WineHQ, AppDB etc.? A list of people who are responsible for that would be nice (it could be I've missed that one though).
Back onto the main topic. Remarks made:
- AppDB needs a revamp. Maybe drop the maintainers (those things just
need to be set by developers only). Just have a look at the activity of all the maintainers in the last year. **Read on for suggestions to drop the AppDB.
I don't know why you are thinking maintainers should be developers only. Maintainers are quite active on the AppDB. And new features (like send test result) are making the job of the maintainers even more easy.
- Create a Wine forum. This solves the problem of users asking the
same questions over and over again. Here also the "comments" of the AppDB could be centralized (because most of them aren't really comments) 3. With a forum in place, the user-mailing list could be dropped and maybe also even the devel-mailing list.
A mailing list has many advantages over a forum (readable from any nntp client, etc.).
- Create a Wine Wiki, instead of the AppDB. Only certain developers
(or maybe users) can set/edit certain pages. Then also howto's could be inserted here.
There are already two Wine Wiki:
http://wiki.winehq.org (official, developper centric) http://wine-wiki.org/ (more user oriented)
As of dropping the AppDB, I don't see the point ? The AppDB might be improved but it's a lot more efficient than a simple wiki to track applications. You can track the bugs linked to a particular application, get an e-mail each time someone adds something to an application of interest, ...
- It's too difficult for users to add a bugreport. Either create a
small program/app which does it for the user (like "Submit this bugreport" *click*) and you're done. The other option is to create a simplified method for searching and inserting a bug report, because from a users view, there are too many options. (and probably the user wouldn't even know what to click on. Don't forget to give the users the option to 'add' a file with certain 'debug channels' (which ones? only +seh?)
The bug reporting tool used by Wine is the same used by most Opensource projects (bugzilla). I don't think this tool is too much complicated but if it is, it must be fixed upstream.
Dan Kegel has a nice page on how to do QA for Wine though: http://www.kegel.com/wine/qa/
The integration of this page in WineHQ or in the Wiki has been discussed on this mailing list.
Jonathan
On 1/9/06, Jonathan Ernst jonathan@ernstfamily.ch wrote:
I don't know why you are thinking maintainers should be developers only. Maintainers are quite active on the AppDB. And new features (like send test result) are making the job of the maintainers even more easy.
I have doubts about the user submitted test results. I think its discouraging proper bug reporting. Like the current test on the diablo 2 node: http://appdb.winehq.org/appview.php?versionId=49
I really think there's something wrong with his wine setup. What's worse is there is no way to find who sent it. It would be better for people to submit their test problems to bugzilla, and have the bug links added to the db entry.
(PS, I must have been removed as maintainer in the db by mistake, because it doesn't show any maintained under my account anymore)
On 1/9/06, S. Schauenburg s.schauenburg@gmail.com wrote:
Back onto the main topic. Remarks made:
- AppDB needs a revamp. Maybe drop the maintainers (those things just
need to be set by developers only). Just have a look at the activity of all the maintainers in the last year. **Read on for suggestions to drop the AppDB.
What is the point of dropping maintainers? Activity is always appreciated, but for most apps it doesn't take much. It either works out of the box, or the status doesn't really change much over the releases. Simply putting up a HOWTO is the most some maintainers need to do for an app. The maintainer doesn't need to report back to the appdb every release to say no regressions have occurred.
- Create a Wine forum. This solves the problem of users asking the
same questions over and over again. Here also the "comments" of the AppDB could be centralized (because most of them aren't really comments)
The AppDB comments need to stay where they are. Each comment is specific to a particular app and only shows up on that app's page. We already have wine-users, bugzilla, and the appdb for users to communicate about wine. Adding a forum would spread ourselves too thin.
- With a forum in place, the user-mailing list could be dropped and
maybe also even the devel-mailing list.
hehe that'll never happen.
- Create a Wine Wiki, instead of the AppDB. Only certain developers
(or maybe users) can set/edit certain pages. Then also howto's could be inserted here.
wiki.winehq.org
- It's too difficult for users to add a bugreport. Either create a
small program/app which does it for the user (like "Submit this bugreport" *click*) and you're done. The other option is to create a simplified method for searching and inserting a bug report, because from a users view, there are too many options. (and probably the user wouldn't even know what to click on. Don't forget to give the users the option to 'add' a file with certain 'debug channels' (which ones? only +seh?)
I don't see how a program would make submitting bugs easier. I'm guessing you're thinking about a crash reporter, which would report a bug with the crash info/backtrace etc, but that would just flood the bugzilla with duplicate crash-only bugs. I'm curious as to what user's find hard about submitting bug reports. If you know, please post the issues here.
- Users need to know that if they submit a bug report (when it's
simplified) that it actually HELPS you, the developers. So it's "Help us, help you".
I agree.
-- James Hawkins
OK, but I mean (don't hit me for this) take a look at Cedega. They have a forum and a wiki and have loads of user input. This generates (inter)activity of users and 'promotes' the application in a certain way, people like to tell other people something finally works :-)
5. First you need to search for a bug. A normal user wouldn't know what things to select and would need to 'guess' where to fill in the keywords etc. The search form looks threatening/scary, so it needs to be simplified into (for example) keyword and wine version. With the bug submission page I wouldn't know what to fill in at "Component" and "Priority". And there's no real place to 'attach' a error report/log to (for example a +seh debug channel)
By the way, I hate the AppDB comments/summarize where people put a error log or something into the comment and/or the summary (under what doesn't work).... This clearly states that people aren't using bugzilla. So if we (Wine) would be a bit more user-friendly I guess it would get the ball rolling. Offtopic: I myself would volunteer to be a moderator on the forum.
On 1/9/06, James Hawkins truiken@gmail.com wrote:
On 1/9/06, S. Schauenburg s.schauenburg@gmail.com wrote:
Back onto the main topic. Remarks made:
- AppDB needs a revamp. Maybe drop the maintainers (those things just
need to be set by developers only). Just have a look at the activity of all the maintainers in the last year. **Read on for suggestions to drop the AppDB.
What is the point of dropping maintainers? Activity is always appreciated, but for most apps it doesn't take much. It either works out of the box, or the status doesn't really change much over the releases. Simply putting up a HOWTO is the most some maintainers need to do for an app. The maintainer doesn't need to report back to the appdb every release to say no regressions have occurred.
- Create a Wine forum. This solves the problem of users asking the
same questions over and over again. Here also the "comments" of the AppDB could be centralized (because most of them aren't really comments)
The AppDB comments need to stay where they are. Each comment is specific to a particular app and only shows up on that app's page. We already have wine-users, bugzilla, and the appdb for users to communicate about wine. Adding a forum would spread ourselves too thin.
- With a forum in place, the user-mailing list could be dropped and
maybe also even the devel-mailing list.
hehe that'll never happen.
- Create a Wine Wiki, instead of the AppDB. Only certain developers
(or maybe users) can set/edit certain pages. Then also howto's could be inserted here.
wiki.winehq.org
- It's too difficult for users to add a bugreport. Either create a
small program/app which does it for the user (like "Submit this bugreport" *click*) and you're done. The other option is to create a simplified method for searching and inserting a bug report, because from a users view, there are too many options. (and probably the user wouldn't even know what to click on. Don't forget to give the users the option to 'add' a file with certain 'debug channels' (which ones? only +seh?)
I don't see how a program would make submitting bugs easier. I'm guessing you're thinking about a crash reporter, which would report a bug with the crash info/backtrace etc, but that would just flood the bugzilla with duplicate crash-only bugs. I'm curious as to what user's find hard about submitting bug reports. If you know, please post the issues here.
- Users need to know that if they submit a bug report (when it's
simplified) that it actually HELPS you, the developers. So it's "Help us, help you".
I agree.
-- James Hawkins
I disagree with both sides of the forum issue.. I think that depending on how it is implemented, it could go either way..
There are forum software's out there that will send you a mail (including what was said) whenever a section is replied to.. Which means you just subscribe to the wine-devel section for example and any new threads will be emailed to you, as well as replies to the ones already posted..
And I'm sure someone here could write something so that you could reply to the email and have a script send whatever you wrote to the forum for you.
Of course at the same time, you have to worry about forum db crashes (i know we have all heard of that happening from time to time)..
Bug searching is harder than it needs to be. I personally have made a custom search to find bugs that i have reported, and bugs that are assigned to me, just because the my bugs and bugs by me links dont find all of them.. Plus, when searching for an app-specific crash, searching thru just the summary doesn't always work, as user may post the err message on the console, so then you need to create a custom search thru the comments as well. And most users who are searching for a bug dont care what the status of the bug is, they want to search all bugs, in case it has a known workaround..
So here are my recommendations for bugzilla, obviously these would have to be implemented by mozilla, but we'll worry about that later.
1) Create a simplified mode and advanced mode, and if the user hasn't specified which mode they want, then default to simplified. Advanced mode would be the search as it is now, simplified mode would be the modifications below:
2) At the top of the page, change the word summary to "Search for:" and make the text field next to it search thru all comment and summary fields, and if possible, textonly attachments, and put a link to the advanced search.
3) Remove the following sections: component, status, resolution, severity, priority, hardware, os, email and numbering, and bug changes, as well as the advanced querying section. That way it is more google-ish, which is what users want..
For entering new bugs, the following changes should be implemented:
1) Remove component altogether, or make it a little more clear at least. If I am entering a bug for an app crash, and it doesnt use directx, for the most part i use wine-misc, which doesnt help anyone out. At the very least if it does stay in there, put an unknown component in the list so i can pick unknown and change it later, once the area in question is discovered.
2) Allow us to attach a file on the main bug entry page, so we can attach the trace and comment the trace at the same time, instead of having to file the report, and then go back to the bug to attach the log.
3) Change the default for platform to PC, the default for os to linux, and remove the windows entries from os.
4) Remove priority and severity.
Anything that I have asked to be removed from the enter bug form should be left in the actual report, but should be allowed to be changed or set by regular users, only by developers, and people with the change flags set (bugzilla maintainers)..
Thats all I can think of for the user-friendliness factor in those areas. I should add that the appdb is flooded with bug reports, which doesnt look good for wine. I say we reset the appdb comments to null, and pot a note at the top of every page in red letters that says "Problems using a particular app? Click here!" and make Click here! be a link to bugzilla's bug report page. That will reduce the number of bug reports in the comments. Then each app maintainer should put a note at the top of their app pages saying "If you have a problem using this app, please (do such and such)" where such and such is whatever the maintainer would prefer, either email them privately, or file a bug report, or write to wine-devel, or anything other than complain about it in that app's thread. That would make wine look a lot more user-friendly, as new users can see hey this app works, and there arent any issues with it, or they can see hey this app partially works, but any problems i have can be easily reported, and people aren't bashing wine about lack of support for that app.
ANYWAYS this email has gotten longer than I planned, and my hands are starting to hurt, so please, comments or suggestions, send em my way.
Tom
S. Schauenburg wrote:
OK, but I mean (don't hit me for this) take a look at Cedega. They have a forum and a wiki and have loads of user input. This generates (inter)activity of users and 'promotes' the application in a certain way, people like to tell other people something finally works :-)
- First you need to search for a bug. A normal user wouldn't know
what things to select and would need to 'guess' where to fill in the keywords etc. The search form looks threatening/scary, so it needs to be simplified into (for example) keyword and wine version. With the bug submission page I wouldn't know what to fill in at "Component" and "Priority". And there's no real place to 'attach' a error report/log to (for example a +seh debug channel)
By the way, I hate the AppDB comments/summarize where people put a error log or something into the comment and/or the summary (under what doesn't work).... This clearly states that people aren't using bugzilla. So if we (Wine) would be a bit more user-friendly I guess it would get the ball rolling. Offtopic: I myself would volunteer to be a moderator on the forum.
Tom Spear (aka Dustin Navea) wrote:
ANYWAYS this email has gotten longer than I planned, and my hands are starting to hurt, so please, comments or suggestions, send em my way.
Maybe the reason that your mail is so long is that it's an impossible feat to save that zilla.
Let's pronounce that monstrosity from the past dead and start using a better product.
Switch to Trac, for example. It will import your Bugzilla bugs in a snap and you're ready to go. User friendly and much simpler and much more consistent than Bugzilla. http://projects.edgewall.com/trac/
The administrator can define custom reports, they're available under < View Tickets >. Click this and see.
Instead of the custom script you talk of, now choose < Custom Query
, add a "reporter" filter and set it to yourself. Can also be used
in URL fashion like this: http://projects.edgewall.com/trac/query?reporter=jonas
Lots of other niceties too. There's an integrated Wiki where you make inline references to the ticket system. Or inline references to the source code, which is also conveniently browsable in Trac. You can search across tickets, source code commits and the wiki with a simple google-like search box. You can even keep your product manual in the wiki like the Trac project does (see http://projects.edgewall.com/trac/wiki/TracGuide). There's even a plugin for making the wiki DOCBOOK compatible somewhere. Possibilities seems endless.
Perhaps we should check this out? Anyone?
Tom
Molle Bestefich wrote:
Tom Spear (aka Dustin Navea) wrote:
ANYWAYS this email has gotten longer than I planned, and my hands are starting to hurt, so please, comments or suggestions, send em my way.
Maybe the reason that your mail is so long is that it's an impossible feat to save that zilla.
Let's pronounce that monstrosity from the past dead and start using a better product.
Switch to Trac, for example. It will import your Bugzilla bugs in a snap and you're ready to go. User friendly and much simpler and much more consistent than Bugzilla. http://projects.edgewall.com/trac/
The administrator can define custom reports, they're available under < View Tickets >. Click this and see.
Instead of the custom script you talk of, now choose < Custom Query
, add a "reporter" filter and set it to yourself. Can also be used
in URL fashion like this: http://projects.edgewall.com/trac/query?reporter=jonas
Lots of other niceties too. There's an integrated Wiki where you make inline references to the ticket system. Or inline references to the source code, which is also conveniently browsable in Trac. You can search across tickets, source code commits and the wiki with a simple google-like search box. You can even keep your product manual in the wiki like the Trac project does (see http://projects.edgewall.com/trac/wiki/TracGuide). There's even a plugin for making the wiki DOCBOOK compatible somewhere. Possibilities seems endless.
We use trac where I work and users that would normally be unable to use bugzilla appear to have success with the simpler interface of trac.
Chris
Switch to Trac, for example. It will import your Bugzilla bugs in a snap and you're ready to go. User friendly and much simpler and much more consistent than Bugzilla. http://projects.edgewall.com/trac/
The administrator can define custom reports, they're available under < View Tickets >. Click this and see.
On 1/10/06, Molle Bestefich molle.bestefich@gmail.com wrote:
Switch to Trac, for example. It will import your Bugzilla bugs in a snap and you're ready to go. User friendly and much simpler and much more consistent than Bugzilla. http://projects.edgewall.com/trac/
Trac looks interesting, but the demo there seems a bit messy. Unfortunately it uses SQLite, which may not be able to effectively handle the huge needs of wine's bug tracking. It says they will try implement support for other sql servers in later versions, but currently it doesn't.
n0dalus.
n0dalus wrote:
Trac looks interesting, but the demo there seems a bit messy.
The demo has write access for anonymous users, so yes. Look at the Trac project's own ticket system instead.
Perhaps try one of these URLs. http://projects.edgewall.com/trac/report http://projects.edgewall.com/trac/search http://projects.edgewall.com/trac/browser/trunk http://projects.edgewall.com/trac/log/trunk
Or a couple of the weirder ones: automatic timeline - http://projects.edgewall.com/trac/timeline?daysback=14&milestone=on&... automatic changelog generation - http://projects.edgewall.com/trac/log/trunk?format=changelog
I'll agree any day that Trac has less features than Bugzilla.
I just think that extending Trac with any features needed is a lot easier than making Bugzilla remotely usable :-).
Unfortunately it uses SQLite, which may not be able to effectively handle the huge needs of wine's bug tracking. It says they will try implement support for other sql servers in later versions, but currently it doesn't.
Bull... There are commercial products out there that handle millions of records of data per hour running on SQLite. I can't quite imagine what you're afraid of.
On 1/10/06, Molle Bestefich molle.bestefich@gmail.com wrote:
Unfortunately it uses SQLite, which may not be able to effectively handle the huge needs of wine's bug tracking. It says they will try implement support for other sql servers in later versions, but currently it doesn't.
Bull... There are commercial products out there that handle millions of records of data per hour running on SQLite. I can't quite imagine what you're afraid of.
In my experience SQLite has been several times slower than a well-configured MySQL server when dealing with large record sets, complex table structures and blob data. Maybe the newer versions of SQLite have improved on this though.
n0dalus.
On Mon, Jan 09, 2006 at 06:48:26PM +0100, Molle Bestefich wrote:
Tom Spear (aka Dustin Navea) wrote:
ANYWAYS this email has gotten longer than I planned, and my hands are starting to hurt, so please, comments or suggestions, send em my way.
Maybe the reason that your mail is so long is that it's an impossible feat to save that zilla.
Let's pronounce that monstrosity from the past dead and start using a better product.
You are not a user of bugzilla, at least for WINE.
The number of new bugs is definitely not an issue, we get more than enough good bugreports.
Ciao, Marcus
On 1/9/06, S. Schauenburg s.schauenburg@gmail.com wrote:
By the way, I hate the AppDB comments/summarize where people put a error log or something into the comment and/or the summary (under what doesn't work).... This clearly states that people aren't using bugzilla. So if we (Wine) would be a bit more user-friendly I guess it would get the ball rolling.
Yes, this is why I have stated in the very beginning of the War3 howto to report problems to bugzilla. All the logs were filling up the comments block making very long, and I'd say that none of them have ever been seriously looked at. With the test results section, they are starting to put it there now and only the appdb maintainers see anyways. If people filed reports in bugzilla, more people would see it, and we can actually interact with the user easier.
On 1/10/06, S. Schauenburg s.schauenburg@gmail.com wrote:
On IRC we started a chat on #WineHQ and discussed how to improve Wine. There were comments made and I wanted to summarize them and ask for your opinion. By the way: Who is in charge of WineHQ, AppDB etc.? A list of people who are responsible for that would be nice (it could be I've missed that one though).
Back onto the main topic. Remarks made:
- AppDB needs a revamp. Maybe drop the maintainers (those things just
need to be set by developers only). Just have a look at the activity of all the maintainers in the last year. **Read on for suggestions to drop the AppDB.
- Create a Wine forum. This solves the problem of users asking the
same questions over and over again. Here also the "comments" of the AppDB could be centralized (because most of them aren't really comments)
- With a forum in place, the user-mailing list could be dropped and
maybe also even the devel-mailing list.
I think a forum is a good idea, but the lists are invaluable. Please don't remove the lists. I think you'll find many developers prefer mailing lists anyway, as they can use their own mail clients and setups and have the posts delivered to them instead of having to go to some forum.
- Create a Wine Wiki, instead of the AppDB. Only certain developers
(or maybe users) can set/edit certain pages. Then also howto's could be inserted here.
- It's too difficult for users to add a bugreport. Either create a
small program/app which does it for the user (like "Submit this bugreport" *click*) and you're done. The other option is to create a simplified method for searching and inserting a bug report, because from a users view, there are too many options. (and probably the user wouldn't even know what to click on. Don't forget to give the users the option to 'add' a file with certain 'debug channels' (which ones? only +seh?)
Bugzilla is not hard to use as it is, maybe we just need to have more tutorials and info, and a link to it when an app crashes.
- Users need to know that if they submit a bug report (when it's
simplified) that it actually HELPS you, the developers. So it's "Help us, help you".
What's your opinion about this? In my eyes, it would greatly improve the user input/feedback and would even make Wine more popular.
Other than those things, most of the ideas here I agree with to some extent.
Just my $0.015, n0dalus.
On Tue, 2006-01-10 at 01:55 +1030, n0dalus wrote:
On 1/10/06, S. Schauenburg s.schauenburg@gmail.com wrote:
- Create a Wine forum. This solves the problem of users asking the
same questions over and over again. Here also the "comments" of the AppDB could be centralized (because most of them aren't really comments)
- With a forum in place, the user-mailing list could be dropped and
maybe also even the devel-mailing list.
I think a forum is a good idea, but the lists are invaluable. Please don't remove the lists. I think you'll find many developers prefer mailing lists anyway, as they can use their own mail clients and setups and have the posts delivered to them instead of having to go to some forum.
Forums are absolutely a good idea. I can't tell you how many Wine-related posts I find on places like the Ubuntu forums, Linux-gamers, and even Something Awful's Serious Hardware/Software Crap forum. The reason is the same reason I post to these forums - they're far more usable, well-sorted, and accessable than a mailing list.
I brought this up about a year ago when I pointed out that the whole reason websites with forums such as Frankscorner had popped up was because we weren't supplying forums at winehq, but nothing ever happened because of it as we assumed that fixing the AppDB would take care of that problem. It hasn't - there's still a lot to say about Wine, and it ain't happening there.
Thanks, Scott Ritchie
Thanks, Scott Ritchie
On Mon, Jan 09, 2006 at 08:42:06PM -0800, Scott Ritchie wrote:
Forums are absolutely a good idea. (...) The reason is the same reason I post to these forums - they're far more usable, well-sorted, and accessable than a mailing list.
The problem is that (AFAIK) most if not all Wine developpers do not share at all this view (at last for me nothing beats either a mailing list or a newsgroups :-) ).
So you will have a nice forum full of Wine questions and no developpers who read them to answer the posts because no-one will care actually reading the forum.
I may be wrong though thinking that all other Wine developpers are 'dinosaurs' like me :-)
Lionel
Lionel Ulmer [mailto:lionel.ulmer@free.fr] wrote:
The problem is that (AFAIK) most if not all Wine developpers do not share at all this view (at last for me nothing beats either a mailing list or a newsgroups :-) ).
So you will have a nice forum full of Wine questions and no developpers who read them to answer the posts because no-one will care actually reading the forum.
I may be wrong though thinking that all other Wine developpers are 'dinosaurs' like me :-)
While I'm not a very active Wine developer, but participate in other projects as well, I myself also prefer mailing lists. I can read them offline anywhere I want without needing an online connection. It allows you to do research on the question and prepare an answer offline as well. Forums are more interactive but that is in this respect also their biggest drawback. I did newsgroups in the past for a forum that had a news link but some changes to that gateway made the newsgroup less and less usable.
Rolf Kalbermatter
I actually prefer forums because there's less of a barrier to get started. I can continue working through my browser, and I don't have to setup a message filter.
Even if there's not a forum where developers participate, but just a forum on winehq for users to help each other, I think that would be much better than no forum. More users have experience with forums than mailing lists, so it's much more likely they'll sign up.
Rolf Kalbermatter wrote:
Lionel Ulmer [mailto:lionel.ulmer@free.fr] wrote:
The problem is that (AFAIK) most if not all Wine developpers do not share at all this view (at last for me nothing beats either a mailing list or a newsgroups :-) ).
So you will have a nice forum full of Wine questions and no developpers who read them to answer the posts because no-one will care actually reading the forum.
I may be wrong though thinking that all other Wine developpers are 'dinosaurs' like me :-)
While I'm not a very active Wine developer, but participate in other projects as well, I myself also prefer mailing lists. I can read them offline anywhere I want without needing an online connection. It allows you to do research on the question and prepare an answer offline as well. Forums are more interactive but that is in this respect also their biggest drawback. I did newsgroups in the past for a forum that had a news link but some changes to that gateway made the newsgroup less and less usable.
Rolf Kalbermatter
Joseph Garvin <k04jg02 <at> kzoo.edu> writes:
I actually prefer forums because there's less of a barrier to get started. I can continue working through my browser, and I don't have to setup a message filter.
I don't have external mail or nntp access at work, so I just use http://news.gmane.org/gmane.comp.emulators.wine.devel
For the most part this operates very similar to any of the forums I regularly visit. There are a couple of qwerks, but all in all very easy to use for the non-NNTP users out there. If it wasn't for this site I'd never be able to procrastinate in the office ;)
Even if there's not a forum where developers participate, but just a forum on winehq for users to help each other, I think that would be much better than no forum. More users have experience with forums than mailing lists, so it's much more likely they'll sign up.
A user forum might be useful. I'd have to admit there are a lot of new users who seem to easily manage to find Linux forums. I see this often on Rage3D's Linux forums as well as Ubuntu and Gentoo forums.
The problem is that there are already well-established wine forums, currently in mailing list format, and they will never go away. So the most likely solution would be a web-nntp gateway, which is exactly what news.gmane.org is. Whether wine decides to host's its own gateway software or not I would leave up to the winehq admins.
- Aric
Aric Cyr wrote:
I don't have external mail or nntp access at work, so I just use http://news.gmane.org/gmane.comp.emulators.wine.devel
I didn't think of that. What about posting a link to the 'Wine Forums' on winehq that goes there?
Joseph Garvin wrote:
Aric Cyr wrote:
I don't have external mail or nntp access at work, so I just use http://news.gmane.org/gmane.comp.emulators.wine.devel
I didn't think of that. What about posting a link to the 'Wine Forums' on winehq that goes there?
It's been there a long time...
http://www.winehq.org/site/forums
look at [Archive 2]
--
Tony Lambregts
Tony Lambregts wrote:
It's been there a long time...
http://www.winehq.org/site/forums
look at [Archive 2]
--
Tony Lambregts
That's not very good from a usability standpoint. The gmane link is buried as Archive2. It's not at all clear that Archive1 (winehq pipermail) doesn't let you post new messages while Archive2 (gmane) does. And maybe a more experienced gmane user will correct me, but it doesn't look like there's any way to tell what posts are new since your last visit.
Now actually having looked at gmane, I can say that it's not nearly as newb friendly as a real phpBB forum would be -- it wasn't even immediately obvious that I could post replies, and the option is labeled "Followup" a term which no modern forum/bulletin board uses anymore and people won't recognize. That, and the option is in the frame displaying the list of posts in the thread, and not in the frame containing the message body (the thing the user actually perceives they want to reply to).
That the World of Warcraft thread in the Gentoo Gamer's and Players forum has become the center for discussion for running WoW under wine for ALL distributions I think says something about the newb friendliness of the mailing lists. Not to disparage the mailing lists -- they let developers use their preferred interface for writing text. But people are going to phpBB forums that aren't even for their own distro before they e-mail wine-devel.
Even if the forum didn't get much developer participation there would at least be a place for all wine users to go, with some nice sticky posts detailing how to submit bugs and test against cvs, something other forums aren't doing. Wine could probably pick up a lot of good bug reports this way.
Joseph Garvin <k04jg02 <at> kzoo.edu> writes:
Tony Lambregts wrote:
It's been there a long time...
http://www.winehq.org/site/forums
look at [Archive 2]
Now actually having looked at gmane, I can say that it's not nearly as newb friendly as a real phpBB forum would be -- it wasn't even immediately obvious that I could post replies, and the option is labeled "Followup" a term which no modern forum/bulletin board uses anymore and people won't recognize. [...]
It would be easy to set up a forum for wine-user using phpBB and mail2forum. The tricky part would be administration. A poorly-mintained forum could be a point-of-entry for spammers, and might also encourage people to ask questions but never check the response.
That the World of Warcraft thread in the Gentoo Gamer's and Players forum has become the center for discussion for running WoW under wine for ALL distributions I think says something about the newb friendliness of the mailing lists. [...]
And the AppDB page for WoW has a prominent link to the Wine thread in that forum. Wine is a big project, and all discussion of it needn't be in one place.
There are features that I'd like to see in AppDB, Bugzilla and the lists that aren't present, but at this point we've collected so much information that it would be a waste to switch to a different system.
The one step that I think would help the problem you're trying to address is something I've suggested before: add a permissive "robots.txt" to appdb.winehq.org, and make the one on "bugs.winehq.org" more open. That would probably lead to fewer duplicate bug-reports as people find similar postings using Google or Yahoo.
Incidentally, I'm posting this via GMane...
-- DLL
David Lee Lambert <as4109 <at> wayne.edu> writes:
[snip really good stuff]
The one step that I think would help the problem you're trying to address is something I've suggested before: add a permissive "robots.txt" to appdb.winehq.org, and make the one on "bugs.winehq.org" more open. That would probably lead to fewer duplicate bug-reports as people find similar postings using Google or Yahoo.
Could you submit a patch for these (please)
Incidentally, I'm posting this via GMane...
same Here ;^)
--
Tony Lambregts
The one step that I think would help the problem you're trying to address is something I've suggested before: add a permissive "robots.txt" to appdb.winehq.org, and make the one on "bugs.winehq.org" more open. That would probably lead to fewer duplicate bug-reports as people find similar postings using Google or Yahoo.
I noticed your first patch. I had a lot of trouble due to the caching change patch you submitted previously and since I didn't have time to verify the robots.txt change carefully I've just put it aside for now. If Tony or someone would like to check it I'd be happy to put it into the repo, I just don't want breakage like last time.
Chris
On 1/9/06, S. Schauenburg s.schauenburg@gmail.com wrote:
On IRC we started a chat on #WineHQ and discussed how to improve Wine. There were comments made and I wanted to summarize them and ask for your opinion. By the way: Who is in charge of WineHQ, AppDB etc.? A list of people who are responsible for that would be nice (it could be I've missed that one though).
Back onto the main topic. Remarks made:
- AppDB needs a revamp. Maybe drop the maintainers (those things just
need to be set by developers only). Just have a look at the activity of all the maintainers in the last year. **Read on for suggestions to drop the AppDB.
I have mail from the many thousands of changes to the appdb that have occurred in the last few months, I even deleted some 10k+ of them just a few weeks ago. Its more active now than it has ever been :-)
Chris
S. Schauenburg wrote:
On IRC we started a chat on #WineHQ and discussed how to improve Wine. There were comments made and I wanted to summarize them and ask for your opinion.
My comments:
* It would be nice to have a checkbox:
[x] "installs and works with Wine and a fresh ~/.wine"
This is the most valuable kind of application for regression testing, and the target Wine should aim for. Apps that require copying windows dlls into ~/.wine and tweaking the configuration are prone to breaking, and the breakage tells us little about Wine regressions, especially as it's not always recorded which set of native dlls/configuration the app worked with.
Secondly encouraging users to use windows dlls reduces the chances that they will find and report bugs with the Wine dlls, or that they will figure out that their application works without those dlls.
* Minor problems with the app screenshots
The screenshots screen (eg. [1]) has too many boxes and requires too many clicks to see a screenshot. IMO, it would be a little cleaner to just show the first screenshot here, and have a [<<prev] and [next>>] link or quick index.
Other than that, the App DB looks great, and it's great work :)
Mike
[1] http://appdb.winehq.org/screenshots.php?appId=1567&versionId=
-
Aric Cyr -
Chris Morgan -
David Lee Lambert -
James Hawkins -
Jesse Allen -
Jonathan Ernst -
Joseph Garvin -
Lionel Ulmer -
Marcus Meissner -
Mike McCormack -
Molle Bestefich -
n0dalus -
n0dalus -
n0dalus -
Rolf Kalbermatter -
S. Schauenburg -
Scott Ritchie -
Tom Spear (aka Dustin Navea) -
Tony Lambregts