James, I have apparently missed this whole development status page. Quite interesting. Thanks. For applciations I was imagining the most boring of the formats on the developmetn status page links: http://winehq.org/site/status_porting Down the left are applications. Across the top are CVS snapshots, releases, CVS dates - whatever people decide makes the most sense. (I think CVS snapshots since that's what most distributions provide.) Each line would be owned by a different user. I'll own a line for Native Instruments 'Reaktor' for instance. I'll test it against all the CVS snapshots that I Can build startign from 200312xx, for instance, and report what the results are. If I make changes tothe config file to get it to work then I'd want a way to put that on line. For instance, Myst ran badly on my system with nothing in the config file. The App DB didn't have much info, but Googling around I found a few lines from our own Duane Clark that I added and it suddenly worked much better. Possibly from all the inputs different users would give over time for each app we could build a more globally useful config file to be placed in the documentation/samples directory each month instead of just shipping an older version that doesn't help much these days. (I understand that the config file isn't officially used anymore, so maybe this should be in a registry or something, but since config files work that is what I'm used to right now.) Anyway, that's my thought. It only works if lots of users eventually participate. I'm not looking to get current Wine people to do any more than they already do, other than facilitate the info in a way users can get to. - Mark On Thu, 4 Nov 2004 14:09:59 -0500, James Hawkins <truiken@xxxxxxxxx> wrote: > > My real thought right now is to forget the developers for a little > > while and just start up a web-based database that lists how well > > things work right now. > > http://appdb.winehq.org/ > http://winehq.org/site/status > > Let me know if you're looking for something more specific or different > from what those links provide. > > > > On Thu, 4 Nov 2004 10:18:15 -0800, Mark Knecht <markknecht@xxxxxxxxx> wrote: > > On Thu, 4 Nov 2004 13:06:41 -0500, James Hawkins <truiken@xxxxxxxxx> wrote: > > > > > > > > it really appears to me that there isn't a consistent -APPLICATION- based > > > > test procedure happening with the standard version of Wine before each > > > > monthly release. > > > > > > As the open-source model of development goes, it's really up to the > > > people that use the application to maintain it. That includes the > > > developers from crossover, and anyone that uses wine. There are just > > > too many applications, and subsequently too many features in those > > > apps, to test before every major wine release. We do have a > > > conformance testing system in place for the api though: > > > > > > http://winehq.org/site/docs/wine-devel/testing > > > > > > The problem is that we don't have enough tests, and we need more help > > > writing new tests. The other problem is that it's very difficult to > > > test everything about wine that could break an app, say for example > > > whether a button is the right color or not. We can't really test that > > > with automated tests. > > > > > > > This is consistent with my understanding and (I think) with what I > > wrote earlier. However, that seems to imply that the only users are > > people who are programmers and can maintain it. I don't think that's > > necessarily a valid assumption as the user base and supported > > application base grows. > > > > My thought, good or bad I don't know, is to do something *user* based > > which tests real apps. This would then start to duplicate a bit of > > what Codeweavers is doing with their application database, but would > > do it for each monthly release. > > > > For instance, there are some apps I depend on Crossover for - M$ > > Office and Quicken - that I would be willing to 'reinstall' in a > > second user account monthly to test for the community. If other users > > operated purely as users and did the same for other apps then this > > would be good information, or so I think. > > > > There are other apps that I want to run, and can run, with newer > > versions of Wine. They include some that work, like Native Instruments > > Battery, and many that don't, like Native Instruments Reaktor, > > Steinberg's Groove Agent, Tascam's GigaStudio, etc. I'd be absolutely > > incentivized to to try installing these once a month if some progress > > was being made to get them to work. This is where the users, somehow, > > have to get linked up, directly or indirectly, with the developers. > > (I'd probably prefer indirectly, but that's my bias...) > > > > My real thought right now is to forget the developers for a little > > while and just start up a web-based database that lists how well > > things work right now. 4-5 users, like me, trying out a few things and > > displaying results in a new way. If it helps it helps. If it doesn't > > it's no great loss, and not an issue for the developers since they > > aren't involved if they don't want to be. > > > > - Mark > > > > > -- > James Hawkins > _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
