Hi,
I see a lot of programs tested in the database without any reference how it
was installed.
One has to reinvent the wheel once again.
Also the line between a bug and a wrong install is a fine one, it would
clear up some test data as-well
So why not force a howto in the database, same like is being done with what
works & what doesn't work
--
View this message in context: http://www.nabble.com/Improve-applicati ... 59967.html
Sent from the Wine - Users mailing list archive at Nabble.com.
Improve application database
Improve application database
Adri wrote:
maintainer is not for everyone. It comes with responsibilities and
someone should not sign up to maintain a program if they know they can
not do the job. I do not keep up-to-date with all the releases. I need
my programs to be stable so I update my wine in fits and spurts to keep
it so. I would not always be grabbing the newest version as it comes
out. I have tried to keep a separate wine-git of the newest version and
test programs in that to help out, but I am not a programmer and was not
able to figure out how to keep it current. Also, the programs I use
already have maintainers, in some cases several of them.
When I posted I wasn't meaning it as a criticism to people. You had said
you would like to see more information on installation, and I was just
wondering if some of the people who got scared off from using the db
might have been ones who would have provided that information in their
submissions.
Right now the db is the first place new people are sent, but it is
fairly new user unfriendly. The first hit that shows up when searching
for an app is often for an old/obsolete version. This works fine once
you've been around a while and understand the site layout and can worm
your way over to the page for the current version. If you just did your
first wine install and are trying to see if City of Heroes or Eve works,
it can add a lot of confusion. The submission form (last time I looked)
was very hard to understand and I would bet a fair number of
rejected/removed submission came from people not being able to figure
out the form.
Thanks for the suggestions and I had considered it, but being atparker wrote:According to the howto, everyone can become a maintainer.abb4 wrote:I don't know that this has anything to do with install directionsI see a lot of programs tested in the database without any reference
how it
was installed. One has to reinvent the wheel once again.
specifically, but there are several people who stopped trying to
contribute to the appdb quite a while ago. The form was set up in a
non-intuitive way, especially for non-techie users. Very often people
would slog through getting the info put in and submit it then have it
never show up in the db or show up breifly and be removed with no
reason given, just an email saying it was removed. With no feedback
on why it was removed it got discouraging since the people assumed
they had done something wrong but didn't know how to improve their
submissions, so they stopped trying. I know that is why I stopped
submitting for the programs I use well over a year ago and have
spoken in person and on distribution forums with others that did the
same.
Why not become a maintainer..then you have it all in your own hands.
maintainer is not for everyone. It comes with responsibilities and
someone should not sign up to maintain a program if they know they can
not do the job. I do not keep up-to-date with all the releases. I need
my programs to be stable so I update my wine in fits and spurts to keep
it so. I would not always be grabbing the newest version as it comes
out. I have tried to keep a separate wine-git of the newest version and
test programs in that to help out, but I am not a programmer and was not
able to figure out how to keep it current. Also, the programs I use
already have maintainers, in some cases several of them.
When I posted I wasn't meaning it as a criticism to people. You had said
you would like to see more information on installation, and I was just
wondering if some of the people who got scared off from using the db
might have been ones who would have provided that information in their
submissions.
Right now the db is the first place new people are sent, but it is
fairly new user unfriendly. The first hit that shows up when searching
for an app is often for an old/obsolete version. This works fine once
you've been around a while and understand the site layout and can worm
your way over to the page for the current version. If you just did your
first wine install and are trying to see if City of Heroes or Eve works,
it can add a lot of confusion. The submission form (last time I looked)
was very hard to understand and I would bet a fair number of
rejected/removed submission came from people not being able to figure
out the form.
-
Frédéric Delanoy
Improve application database
On 07/26/2009 06:40 PM, tparker wrote:
When you try a new version, you can either
- backup your ~/.wine and test
- use another wine dir by setting WINEPREFIX environment variable before launching wine
(see http://wiki.winehq.org/FAQ#head-f2f5f3b ... 15657ad552)
As for compiling and staying up to date with git, it's not that hard: you need basically
- install git with your package manager then checkout latest version e.g. in ~/wine-git
git clone git://source.winehq.org/git/wine.git ~/wine-git
cd ~/wine-git
(http://wiki.winehq.org/GitWine?action=s ... 1128bb8a64)
- install all required development libraries (details varies upon distribution) & compile Wine
ex: sudo apt-get build-dep wine for Debian and derived distribs (like Ubuntu)
see Wine compilation: http://wiki.winehq.org/FAQ#head-7ed3c31 ... 53dc41817b
[Note: the "make install" step is not necessary if you run wine from local dir]
- to update wine, just go to ~/wine-git (or whatever dir you choose), and go a "git pull"
then "make depend"
Then you can test the latest wine using another wineprefix, sthg like
cd ~/wine-git
WINEPREFIX=~/.wine-latest ./wine program_path
Hope that helps,
Frédéric
By default, the ~/.wine is used when launching wine.Adri wrote:Thanks for the suggestions and I had considered it, but being atparker wrote:According to the howto, everyone can become a maintainer.abb4 wrote: I don't know that this has anything to do with install directions
specifically, but there are several people who stopped trying to
contribute to the appdb quite a while ago. The form was set up in a
non-intuitive way, especially for non-techie users. Very often people
would slog through getting the info put in and submit it then have it
never show up in the db or show up breifly and be removed with no
reason given, just an email saying it was removed. With no feedback
on why it was removed it got discouraging since the people assumed
they had done something wrong but didn't know how to improve their
submissions, so they stopped trying. I know that is why I stopped
submitting for the programs I use well over a year ago and have
spoken in person and on distribution forums with others that did the
same.
Why not become a maintainer..then you have it all in your own hands.
maintainer is not for everyone. It comes with responsibilities and
someone should not sign up to maintain a program if they know they can
not do the job. I do not keep up-to-date with all the releases. I need
my programs to be stable so I update my wine in fits and spurts to keep
it so. I would not always be grabbing the newest version as it comes
out. I have tried to keep a separate wine-git of the newest version and
test programs in that to help out, but I am not a programmer and was not
able to figure out how to keep it current. Also, the programs I use
already have maintainers, in some cases several of them.
When I posted I wasn't meaning it as a criticism to people. You had said
you would like to see more information on installation, and I was just
wondering if some of the people who got scared off from using the db
might have been ones who would have provided that information in their
submissions.
Right now the db is the first place new people are sent, but it is
fairly new user unfriendly. The first hit that shows up when searching
for an app is often for an old/obsolete version. This works fine once
you've been around a while and understand the site layout and can worm
your way over to the page for the current version. If you just did your
first wine install and are trying to see if City of Heroes or Eve works,
it can add a lot of confusion. The submission form (last time I looked)
was very hard to understand and I would bet a fair number of
rejected/removed submission came from people not being able to figure
out the form.
When you try a new version, you can either
- backup your ~/.wine and test
- use another wine dir by setting WINEPREFIX environment variable before launching wine
(see http://wiki.winehq.org/FAQ#head-f2f5f3b ... 15657ad552)
As for compiling and staying up to date with git, it's not that hard: you need basically
- install git with your package manager then checkout latest version e.g. in ~/wine-git
git clone git://source.winehq.org/git/wine.git ~/wine-git
cd ~/wine-git
(http://wiki.winehq.org/GitWine?action=s ... 1128bb8a64)
- install all required development libraries (details varies upon distribution) & compile Wine
ex: sudo apt-get build-dep wine for Debian and derived distribs (like Ubuntu)
see Wine compilation: http://wiki.winehq.org/FAQ#head-7ed3c31 ... 53dc41817b
[Note: the "make install" step is not necessary if you run wine from local dir]
- to update wine, just go to ~/wine-git (or whatever dir you choose), and go a "git pull"
then "make depend"
Then you can test the latest wine using another wineprefix, sthg like
cd ~/wine-git
WINEPREFIX=~/.wine-latest ./wine program_path
Hope that helps,
Frédéric
