appdb issue: can't search for apps platinum on 1.0.x!
Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!). To fix this, we should add 1.0 (or 1.0.1) back into the search box in http://appdb.winehq.org/objectManager.php?sClass=application
2009/2/26 Dan Kegel <dank(a)kegel.com>:
Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!).
To fix this, we should add 1.0 (or 1.0.1) back into the search box in http://appdb.winehq.org/objectManager.php?sClass=application
Someone mentioned on another thread (or possibly on IRC, I don't recall) that 1.0-series is too old to be of concern to us. We don't want test data for 1.0.x; we don't want bug reports for 1.0.x unless they're still apparent in the development version. Development has stopped on 1.0.x. The problem is that 1.0.1 is not actually "stable" in that it doesn't crash/runs lots of apps. It's "stable" in that the code doesn't change, kind of like Debian Stable. If a massive security issue (like a rootkit) becomes apparent in 1.0.1, I'm pretty sure we want to know about that, but in general, if it can be fixed by upgrading to 1.1.x, then that's what you should do. There have been plenty of cases in #winehq where users have some problem with 1.0.1 (Warcraft 3 appears to be a popular candidate). When they upgrade to 1.1.15, suddenly it starts working. Are there even any winehq-supplied binary packages for any distro that supply 1.0.1 by default? Scott's Ubuntu packages are the dev versions, though 1.0.1 is accessible through his archives; my Debian packages only go back to about 1.1.12 or so.
Ben Klein wrote:
2009/2/26 Dan Kegel <dank(a)kegel.com>:
Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!).
To fix this, we should add 1.0 (or 1.0.1) back into the search box in http://appdb.winehq.org/objectManager.php?sClass=application
Someone mentioned on another thread (or possibly on IRC, I don't recall) that 1.0-series is too old to be of concern to us. We don't want test data for 1.0.x; we don't want bug reports for 1.0.x unless they're still apparent in the development version. Development has stopped on 1.0.x.
The problem is that 1.0.1 is not actually "stable" in that it doesn't crash/runs lots of apps. It's "stable" in that the code doesn't change, kind of like Debian Stable. If a massive security issue (like a rootkit) becomes apparent in 1.0.1, I'm pretty sure we want to know about that, but in general, if it can be fixed by upgrading to 1.1.x, then that's what you should do.
There have been plenty of cases in #winehq where users have some problem with 1.0.1 (Warcraft 3 appears to be a popular candidate). When they upgrade to 1.1.15, suddenly it starts working. Are there even any winehq-supplied binary packages for any distro that supply 1.0.1 by default? Scott's Ubuntu packages are the dev versions, though 1.0.1 is accessible through his archives; my Debian packages only go back to about 1.1.12 or so.
What this means, quite simply, is that we need more frequent releases of a stable Wine version. I know Alexandre wants to cram in a major feature before starting the stabilization process, but unless that happens really soon we're only going to see issues like this get even worse. Thanks, Scott Ritchie
On Wed, Feb 25, 2009 at 6:31 PM, Ben Klein <shacklein(a)gmail.com> wrote:
There have been plenty of cases in #winehq where users have some problem with 1.0.1 (Warcraft 3 appears to be a popular candidate). When they upgrade to 1.1.15, suddenly it starts working. Are there even any winehq-supplied binary packages for any distro that supply 1.0.1 by default? Scott's Ubuntu packages are the dev versions, though 1.0.1 is accessible through his archives; my Debian packages only go back to about 1.1.12 or so.
The problem is many distros are shipping with 1.0.1 in _their_ repositories, so users get that. When we tell them to upgrade to current, they usually get the WineHQ repositories. -- -Austin
On Wed, Feb 25, 2009 at 4:31 PM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/2/26 Dan Kegel <dank(a)kegel.com>:
Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!).
Someone mentioned on another thread (or possibly on IRC, I don't recall) that 1.0-series is too old to be of concern to us. We don't want test data for 1.0.x; we don't want bug reports for 1.0.x unless they're still apparent in the development version. Development has stopped on 1.0.x.
That's a fine attitude from the developer's point of view, but that means that Wine *doesn't care* about Ubuntu users who expect to be able to use Wine by doing "add/remove" in the system menu. And I think we do care. Another way around this, as Scott Ritchie pointed out, is to arrange for what's in Ubuntu to be less stale. However, there are only two ways to do that: either do a stable release more often (which is difficult, and which Alexandre doesn't seem inclined to do), or get Ubuntu to accept an unstable snapshot into their stable repository (which I think they are not inclined to do). Yet another way to show that we care about Ubuntu users would be to make it drop-dead simple for the average user to add the Wine repository and get the latest wine. The current download instructions are really too complicated. We need instructions that are no more complicated than First: Click *here* to add WineHQ's repository Then: Do Applications / 'Add / Remove', and choose Wine That would compensate for the packages in Ubuntu's repo being stale. - Dan
2009/2/28 Dan Kegel <dank(a)kegel.com>:
On Wed, Feb 25, 2009 at 4:31 PM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/2/26 Dan Kegel <dank(a)kegel.com>:
Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!).
Someone mentioned on another thread (or possibly on IRC, I don't recall) that 1.0-series is too old to be of concern to us. We don't want test data for 1.0.x; we don't want bug reports for 1.0.x unless they're still apparent in the development version. Development has stopped on 1.0.x.
That's a fine attitude from the developer's point of view, but that means that Wine *doesn't care* about Ubuntu users who expect to be able to use Wine by doing "add/remove" in the system menu.
And I think we do care.
No more than any other distro, to be honest.
Another way around this, as Scott Ritchie pointed out, is to arrange for what's in Ubuntu to be less stale. However, there are only two ways to do that: either do a stable release more often (which is difficult, and which Alexandre doesn't seem inclined to do), or get Ubuntu to accept an unstable snapshot into their stable repository (which I think they are not inclined to do).
Maybe someone should tell them that 1.0.1 is "broken" compared to latest development release. This isn't untrue - 1.1.15 has better success with a lot of apps. Basically, someone should tell them that Wine's "stable" branch is just a code freeze, and has nothing to do with crash-resistant stability.
Yet another way to show that we care about Ubuntu users would be to make it drop-dead simple for the average user to add the Wine repository and get the latest wine. The current download instructions are really too complicated. We need instructions that are no more complicated than
First: Click *here* to add WineHQ's repository
Then: Do Applications / 'Add / Remove', and choose Wine
The instructions were like this at one point: download this script, run it, go to Add/Remove. Again, I think it's unproductive to hide information from the users. At least with the current instructions they can see *exactly* what's going on, and they don't have to worry about manual editing or the user-unfriendly command-line ... I'd also think the average user might be sceptical of an all-in-one script that changes the configuration of their system. "Why is this thing asking for my password? What is it doing? Can I really trust it?" etc. etc.
That would compensate for the packages in Ubuntu's repo being stale. - Dan
On Fri, Feb 27, 2009 at 1:46 PM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/2/28 Dan Kegel <dank(a)kegel.com>:
On Wed, Feb 25, 2009 at 4:31 PM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/2/26 Dan Kegel <dank(a)kegel.com>:
Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!).
Someone mentioned on another thread (or possibly on IRC, I don't recall) that 1.0-series is too old to be of concern to us. We don't want test data for 1.0.x; we don't want bug reports for 1.0.x unless they're still apparent in the development version. Development has stopped on 1.0.x.
That's a fine attitude from the developer's point of view, but that means that Wine *doesn't care* about Ubuntu users who expect to be able to use Wine by doing "add/remove" in the system menu.
And I think we do care.
No more than any other distro, to be honest.
Another way around this, as Scott Ritchie pointed out, is to arrange for what's in Ubuntu to be less stale. However, there are only two ways to do that: either do a stable release more often (which is difficult, and which Alexandre doesn't seem inclined to do), or get Ubuntu to accept an unstable snapshot into their stable repository (which I think they are not inclined to do).
Maybe someone should tell them that 1.0.1 is "broken" compared to latest development release. This isn't untrue - 1.1.15 has better success with a lot of apps.
Basically, someone should tell them that Wine's "stable" branch is just a code freeze, and has nothing to do with crash-resistant stability.
Yet another way to show that we care about Ubuntu users would be to make it drop-dead simple for the average user to add the Wine repository and get the latest wine. The current download instructions are really too complicated. We need instructions that are no more complicated than
First: Click *here* to add WineHQ's repository
Then: Do Applications / 'Add / Remove', and choose Wine
The instructions were like this at one point: download this script, run it, go to Add/Remove. Again, I think it's unproductive to hide information from the users. At least with the current instructions they can see *exactly* what's going on, and they don't have to worry about manual editing or the user-unfriendly command-line ...
I'd also think the average user might be sceptical of an all-in-one script that changes the configuration of their system. "Why is this thing asking for my password? What is it doing? Can I really trust it?" etc. etc.
Anyone coming from Vista would be used to UAC for program installs...
On Fri, Feb 27, 2009 at 1:46 PM, Ben Klein <shacklein(a)gmail.com> wrote:
That's a fine attitude from the developer's point of view, but that means that Wine *doesn't care* about Ubuntu users who expect to be able to use Wine by doing "add/remove" in the system menu.
And I think we do care.
No more than any other distro, to be honest.
What I meant was, I think we do care about users of distros that are shipping wine-1.0. I don't know how many do, but I suspect it's not just Ubuntu.
Another way around this, as Scott Ritchie pointed out, is to arrange for what's in Ubuntu to be less stale. However, there are only two ways to do that: either do a stable release more often (which is difficult, and which Alexandre doesn't seem inclined to do), or get Ubuntu to accept an unstable snapshot into their stable repository (which I think they are not inclined to do).
Maybe someone should tell them that 1.0.1 is "broken" compared to latest development release. This isn't untrue - 1.1.15 has better success with a lot of apps.
Their reply is probably "well, then do another stable release. Our policy is that we prefer to bundle only stable releases."
Yet another way to show that we care about Ubuntu users would be to make it drop-dead simple for the average user to add the Wine repository and get the latest wine. The current download instructions are really too complicated. We need instructions that are no more complicated than
First: Click *here* to add WineHQ's repository
Then: Do Applications / 'Add / Remove', and choose Wine
The instructions were like this at one point: download this script, run it, go to Add/Remove. Again, I think it's unproductive to hide information from the users.
And it's even more unproductive if your instructions are so long that users can't or won't follow them. I'm trying to introduce rank beginners to Wine, and anything beyond "Click Add/Remove, then choose Wine" is stretching it. I can see their eyes glaze over.
At least with the current instructions they can see *exactly* what's going on, and they don't have to worry about manual editing or the user-unfriendly command-line ...
The current instructions tell them to manually edit their software sources. It's too much typing for them.
I'd also think the average user might be sceptical of an all-in-one script that changes the configuration of their system. "Why is this thing asking for my password? What is it doing? Can I really trust it?" etc. etc.
In fact, it's common practice for repos like rpmfusion.org to have a tiny package that just adds themselves to your software sources. (See http://rpmfusion.org/Configuration ) Scripts are right out, though. It has to be a package, because you can't run a script with a single mouse click. I think it's important for us to focus on usability of installation. Thinking like developers has got us a long ways; now we also have to think like users. - Dan
2009/2/28 Dan Kegel <dank(a)kegel.com>:
Another way around this, as Scott Ritchie pointed out, is to arrange for what's in Ubuntu to be less stale. However, there are only two ways to do that: either do a stable release more often (which is difficult, and which Alexandre doesn't seem inclined to do), or get Ubuntu to accept an unstable snapshot into their stable repository (which I think they are not inclined to do).
Maybe someone should tell them that 1.0.1 is "broken" compared to latest development release. This isn't untrue - 1.1.15 has better success with a lot of apps.
Their reply is probably "well, then do another stable release. Our policy is that we prefer to bundle only stable releases."
We should at least try! From what I've seen, Ubuntu like bleeding-edge stuff that likes to break other things, like pulseaudio. Maybe their problem is with the 2-week release cycle. How many releases would there be between Ubuntu releases? 6 months, 13 releases of Wine. Still, isn't it worth contacting the Ubuntu Wine package maintainer to get their viewpoint?
Yet another way to show that we care about Ubuntu users would be to make it drop-dead simple for the average user to add the Wine repository and get the latest wine. The current download instructions are really too complicated. We need instructions that are no more complicated than
First: Click *here* to add WineHQ's repository
Then: Do Applications / 'Add / Remove', and choose Wine
The instructions were like this at one point: download this script, run it, go to Add/Remove. Again, I think it's unproductive to hide information from the users.
And it's even more unproductive if your instructions are so long that users can't or won't follow them.
I'm trying to introduce rank beginners to Wine, and anything beyond "Click Add/Remove, then choose Wine" is stretching it. I can see their eyes glaze over.
I think you're assuming too much of your target audience, but that's just me.
At least with the current instructions they can see *exactly* what's going on, and they don't have to worry about manual editing or the user-unfriendly command-line ...
The current instructions tell them to manually edit their software sources. It's too much typing for them.
If you can present a better way of adding Scott's repository into their list, then please do. A little copy-and-paste won't hurt them.
I'd also think the average user might be sceptical of an all-in-one script that changes the configuration of their system. "Why is this thing asking for my password? What is it doing? Can I really trust it?" etc. etc.
In fact, it's common practice for repos like rpmfusion.org to have a tiny package that just adds themselves to your software sources. (See http://rpmfusion.org/Configuration ) Scripts are right out, though. It has to be a package, because you can't run a script with a single mouse click.
Maybe this is not a bad idea: provide a package with the correctly configured /etc/apt/sources.list.d/foobar that also registers the GPG key with apt. It's certainly possible! The only problem would be for distro upgrades (say between Ubuntu 8.10 and 9.04) where the name of the repository changes. But with good instructions, this should be trivial.
I think it's important for us to focus on usability of installation. Thinking like developers has got us a long ways; now we also have to think like users.
Unfortunately, new users of Linux systems, particularly Debian-based distros, are often confused by package management in general. My brother, who really is a whiz with Windows systems, couldn't work out how to get new software into Ubuntu. He thought that because individual developers didn't provide binary packages, he had to compile everything. I tried to teach him how to use synaptic, and he said "This is stupid. It should be like MacOSX where you just download a package and it's installed." I'm sure I don't need to go into the benefits of centralised package management for Linux-like systems on this thread ... I think that properly educating new users is more valuable than telling them "click on this magic link that does it for you".
On Fri, Feb 27, 2009 at 2:30 PM, Ben Klein <shacklein(a)gmail.com> wrote:
Their reply is probably "well, then do another stable release. Our policy is that we prefer to bundle only stable releases."
We should at least try! From what I've seen, Ubuntu like bleeding-edge stuff that likes to break other things, like pulseaudio.
Maybe their problem is with the 2-week release cycle. How many releases would there be between Ubuntu releases? 6 months, 13 releases of Wine. Still, isn't it worth contacting the Ubuntu Wine package maintainer to get their viewpoint?
Scott, that's you, right? Can you speak to that?
Unfortunately, new users of Linux systems, particularly Debian-based distros, are often confused by package management in general. My brother, who really is a whiz with Windows systems, couldn't work out how to get new software into Ubuntu. He thought that because individual developers didn't provide binary packages, he had to compile everything. I tried to teach him how to use synaptic, and he said "This is stupid. It should be like MacOSX where you just download a package and it's installed."
Ubuntu tries to make this simple by putting the Add/Remove link right on the main Applications menu. New users still get tripped up by misunderstandings - see the amazing clusterf*ck at http://blogs.computerworld.com/updating_software_in_linux_three_strikes_and_... I know exactly what confused him, and most users won't run into it, but hopefully Ubuntu and Linux in general can improve to handle even that kind of user.
I think that properly educating new users is more valuable than telling them "click on this magic link that does it for you".
That only works for most users if the things you're trying to teach them are extremely simple and usable. Having to type anything beyond a single simple URL - and possibly a simple package name - is a serious roadblock. I think that clicking on a single link to add the Wine repo to the package manager strikes a good balance between simplicity and explainability. - Dan
On Sat, Feb 28, 2009 at 2:50 AM, Dan Kegel <dank(a)kegel.com> wrote:
On Fri, Feb 27, 2009 at 2:30 PM, Ben Klein <shacklein(a)gmail.com> wrote:
I think that properly educating new users is more valuable than telling them "click on this magic link that does it for you".
That only works for most users if the things you're trying to teach them are extremely simple and usable. Having to type anything beyond a single simple URL - and possibly a simple package name - is a serious roadblock.
It's also a question of usefulness. What does a user gain from learning how to add a repository manually? That's part of the installation procedure. Doing it manually serves no purpose. The rest of the installation is also a magic link to a package that puts all kinds of files on your system and runs configuration scripts. Remco
On Fri, Feb 27, 2009 at 11:06 PM, Dan Kegel <dank(a)kegel.com> wrote:
In fact, it's common practice for repos like rpmfusion.org to have a tiny package that just adds themselves to your software sources. (See http://rpmfusion.org/Configuration ) Scripts are right out, though. It has to be a package, because you can't run a script with a single mouse click.
The WineHQ-provided .deb and .rpm packages themselves could add the WineHQ repo as part of their installation routine. There is no need for a tiny separate package. That would result in the simplest installation scenario imaginable: * Click here * Enter password After that, Wine will have been installed, and updates will start coming in. Remco
2009/2/28 Remco <remco47(a)gmail.com>:
On Fri, Feb 27, 2009 at 11:06 PM, Dan Kegel <dank(a)kegel.com> wrote:
In fact, it's common practice for repos like rpmfusion.org to have a tiny package that just adds themselves to your software sources. (See http://rpmfusion.org/Configuration ) Scripts are right out, though. It has to be a package, because you can't run a script with a single mouse click.
The WineHQ-provided .deb and .rpm packages themselves could add the WineHQ repo as part of their installation routine. There is no need for a tiny separate package.
That would result in the simplest installation scenario imaginable:
* Click here * Enter password
After that, Wine will have been installed, and updates will start coming in.
Except that the first package would be technically outside of the repository, and would have the same version as the one in the repository. This COULD make the package manager think there's an update that needs to be downloaded when it doesn't.
On Fri, Feb 27, 2009 at 11:41 PM, Ben Klein <shacklein(a)gmail.com> wrote:
Except that the first package would be technically outside of the repository, and would have the same version as the one in the repository. This COULD make the package manager think there's an update that needs to be downloaded when it doesn't.
No, it's exactly the same package. The installer of every .deb package just has an additional file "winehq.list" with the following contents: deb http://wine.budgetdedicated.com/apt intrepid main Which must be installed into /etc/apt/sources.list.d/. Also, the scripting capabilities of .deb packages should make it possible to add the authentication key. The same goes for .rpm and their respective updating mechanism. It's like the packages sanitize their environment. Remco
2009/2/28 Remco <remco47(a)gmail.com>:
On Fri, Feb 27, 2009 at 11:41 PM, Ben Klein <shacklein(a)gmail.com> wrote:
Except that the first package would be technically outside of the repository, and would have the same version as the one in the repository. This COULD make the package manager think there's an update that needs to be downloaded when it doesn't.
No, it's exactly the same package. The installer of every .deb package just has an additional file "winehq.list" with the following contents:
deb http://wine.budgetdedicated.com/apt intrepid main
Which must be installed into /etc/apt/sources.list.d/. Also, the scripting capabilities of .deb packages should make it possible to add the authentication key.
The same goes for .rpm and their respective updating mechanism. It's like the packages sanitize their environment.
Sorry, but I have worked with this situation, and whether or not the packages are identical does not change what I said before. The package manager can think that the version from the repository should replace the locally-installed version.
On Sat, Feb 28, 2009 at 12:01 AM, Ben Klein <shacklein(a)gmail.com> wrote:
Sorry, but I have worked with this situation, and whether or not the packages are identical does not change what I said before. The package manager can think that the version from the repository should replace the locally-installed version.
Oh, I see. You mean that the package manager prefers the local repository if all else is equal. That's solvable by bumping the version number of the package that you download from the site. So, in 'pseudo-versions', the repository would have these: wine 1.15-0 wine 1.16-0 wine 1.17-0 While the site would provide these for download: wine 1.15-1 wine 1.16-1 wine 1.17-1 Remco
2009/2/28 Remco <remco47(a)gmail.com>:
On Sat, Feb 28, 2009 at 12:01 AM, Ben Klein <shacklein(a)gmail.com> wrote:
Sorry, but I have worked with this situation, and whether or not the packages are identical does not change what I said before. The package manager can think that the version from the repository should replace the locally-installed version.
Oh, I see. You mean that the package manager prefers the local repository if all else is equal. That's solvable by bumping the version number of the package that you download from the site. So, in 'pseudo-versions', the repository would have these:
wine 1.15-0 wine 1.16-0 wine 1.17-0
While the site would provide these for download:
wine 1.15-1 wine 1.16-1 wine 1.17-1
This would fix the problem, but would also mean twice as much space is required to store the packages. If we're willing to deal with that, go for it!
On Sat, Feb 28, 2009 at 12:11 AM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/2/28 Remco <remco47(a)gmail.com>:
Oh, I see. You mean that the package manager prefers the local repository if all else is equal. That's solvable by bumping the version number of the package that you download from the site. So, in 'pseudo-versions', the repository would have these:
wine 1.15-0 wine 1.16-0 wine 1.17-0
While the site would provide these for download:
wine 1.15-1 wine 1.16-1 wine 1.17-1
This would fix the problem, but would also mean twice as much space is required to store the packages. If we're willing to deal with that, go for it!
Well, I don't know if any package manager really does prefer a locally installed version, to the point that it actually replaces the package with exactly the same one. It would seem like a rather pointless feature. I just tested it on Ubuntu 8.10 by installing the 1.1.15 version from the site. I checked for updates, but Ubuntu tells me there are none available. So Ubuntu is cleared. ;) But if another package management system does work like that, some compromise would have to be made. It's either: * Extra space required, for the proposed solution, or * Less usability, like it is now, or * Extra CPU power required, if you were to bump the version on the server when the file is requested. Remco
On Fri, Feb 27, 2009 at 2:37 PM, Remco <remco47(a)gmail.com> wrote:
On Fri, Feb 27, 2009 at 11:06 PM, Dan Kegel <dank(a)kegel.com> wrote:
In fact, it's common practice for repos like rpmfusion.org to have a tiny package that just adds themselves to your software sources. (See http://rpmfusion.org/Configuration ) Scripts are right out, though. It has to be a package, because you can't run a script with a single mouse click.
The WineHQ-provided .deb and .rpm packages themselves could add the WineHQ repo as part of their installation routine. There is no need for a tiny separate package.
That's an attractive scenario, but I have run into violent objections from admins when I discuss it. They want the two operations separated out into separate packages; it's simply too surprising to have a simple package that installs an app *also* add a new repository. Now, maybe Wine's a special case, and admins won't complain about it. But I wouldn't bet money on that. - Dan
Ben Klein <shacklein(a)gmail.com> writes:
Maybe someone should tell them that 1.0.1 is "broken" compared to latest development release. This isn't untrue - 1.1.15 has better success with a lot of apps.
Basically, someone should tell them that Wine's "stable" branch is just a code freeze, and has nothing to do with crash-resistant stability.
That's not true, we spent a lot of time fixing regressions for 1.0, and it's clearly higher quality than many of the development snapshots. Of course some apps may work better in 1.1.15, but some are broken too. Saying 1.0.1 is too broken to be supported is silly, it was working just fine 6 months ago, and it is still working fine for many apps. -- Alexandre Julliard julliard(a)winehq.org
2009/2/28 Alexandre Julliard <julliard(a)winehq.org>:
Ben Klein <shacklein(a)gmail.com> writes:
Maybe someone should tell them that 1.0.1 is "broken" compared to latest development release. This isn't untrue - 1.1.15 has better success with a lot of apps.
Basically, someone should tell them that Wine's "stable" branch is just a code freeze, and has nothing to do with crash-resistant stability.
That's not true, we spent a lot of time fixing regressions for 1.0, and it's clearly higher quality than many of the development snapshots. Of course some apps may work better in 1.1.15, but some are broken too.
Saying 1.0.1 is too broken to be supported is silly, it was working just fine 6 months ago, and it is still working fine for many apps.
I don't see a 1.0.2 being developed though. I'm sure there are still a lot of bugs that could be fixed in 1.0.1 - correct me if I'm wrong here. But I based my statement on the fact that many users on #winehq have come in with a problem in 1.0.1, and upgrading to the latest available development version fixes their problem.
Ben Klein <shacklein(a)gmail.com> writes:
I don't see a 1.0.2 being developed though. I'm sure there are still a lot of bugs that could be fixed in 1.0.1 - correct me if I'm wrong here.
I don't see a lot of bugs that could be fixed by changes small enough to go into the stable branch. If you do, please build a list and if there are enough of them we can certainly do a 1.0.2.
But I based my statement on the fact that many users on #winehq have come in with a problem in 1.0.1, and upgrading to the latest available development version fixes their problem.
Sure, if 1.0.1 doesn't work, then trying the tip is a good idea, but that doesn't mean that everybody should do that. There are regressions in the tip, and there's no reason to push users to upgrade unless they clearly have trouble with 1.0.1. -- Alexandre Julliard julliard(a)winehq.org
2009/2/28 Alexandre Julliard <julliard(a)winehq.org>:
Ben Klein <shacklein(a)gmail.com> writes:
I don't see a 1.0.2 being developed though. I'm sure there are still a lot of bugs that could be fixed in 1.0.1 - correct me if I'm wrong here.
I don't see a lot of bugs that could be fixed by changes small enough to go into the stable branch. If you do, please build a list and if there are enough of them we can certainly do a 1.0.2.
But I based my statement on the fact that many users on #winehq have come in with a problem in 1.0.1, and upgrading to the latest available development version fixes their problem.
Sure, if 1.0.1 doesn't work, then trying the tip is a good idea, but that doesn't mean that everybody should do that. There are regressions in the tip, and there's no reason to push users to upgrade unless they clearly have trouble with 1.0.1.
Now as this is *your* project, AJ, what do you think? Should stable branch be supported better by AppDB/bugzilla etc? At the moment, 1.0.1 is considered "too old" in some cases. The following quotes are from the start of this thread: 2009/2/26 Ben Klein <shacklein(a)gmail.com>:
2009/2/26 Dan Kegel <dank(a)kegel.com>:
Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!).
To fix this, we should add 1.0 (or 1.0.1) back into the search box in http://appdb.winehq.org/objectManager.php?sClass=application
Someone mentioned on another thread (or possibly on IRC, I don't recall) that 1.0-series is too old to be of concern to us. We don't want test data for 1.0.x; we don't want bug reports for 1.0.x unless they're still apparent in the development version. Development has stopped on 1.0.x.
Maybe I'm wrong here, but that's what it looks like from current AppDB and bugzilla status.
Ben Klein <shacklein(a)gmail.com> writes:
Now as this is *your* project, AJ, what do you think? Should stable branch be supported better by AppDB/bugzilla etc? At the moment, 1.0.1 is considered "too old" in some cases.
1.0.1 should definitely be supported in AppDB and bugzilla. The whole idea of making a stable release is that it's something that should last for a while, be included in distros, and provide a base state that people can rely on. So we have to continue to support it, even if it's not being actively developed. There's no point in making stable releases if we decide that they are useless after 6 months (and no, the answer is not to make more frequent stable releases; even if we did one every 3 months we'd still have to support the old ones). -- Alexandre Julliard julliard(a)winehq.org
On Sat, Feb 28, 2009 at 10:47 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
Ben Klein <shacklein(a)gmail.com> writes:
Now as this is *your* project, AJ, what do you think? Should stable branch be supported better by AppDB/bugzilla etc? At the moment, 1.0.1 is considered "too old" in some cases.
There's no point in making stable releases if we decide that they are useless after 6 months (and no, the answer is not to make more frequent stable releases; even if we did one every 3 months we'd still have to support the old ones).
Time based stable releases that are coming about once in a year could be good idea. Making stable release should be a lot easier with passing and improving test suit. If that is considered too invasive branching could happen when the candidate for stable branch goes to RC. Another way to make everyone happy with "unstable" would be mark every 12th wine release as stable and just branching it for bug fixing. Then bug fix release could be 1.1.12.X. 2009/2/28 Remco <remco47(a)gmail.com>:
On Sat, Feb 28, 2009 at 12:11 AM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/2/28 Remco <remco47(a)gmail.com>:
Oh, I see. You mean that the package manager prefers the local repository if all else is equal. That's solvable by bumping the version number of the package that you download from the site. So, in 'pseudo-versions', the repository would have these:
wine 1.15-0 wine 1.16-0 wine 1.17-0
While the site would provide these for download:
wine 1.15-1 wine 1.16-1 wine 1.17-1
This would fix the problem, but would also mean twice as much space is required to store the packages. If we're willing to deal with that, go for it!
Well, I don't know if any package manager really does prefer a locally installed version, to the point that it actually replaces the package with exactly the same one. It would seem like a rather pointless feature.
Why not just make separate package for installing the source file. It could be named as wine-installer. Then post-install hook can download and install the real wine package. Pauli
2009/3/2 Pauli Nieminen <suokkos(a)gmail.com>:
On Sat, Feb 28, 2009 at 10:47 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: Time based stable releases that are coming about once in a year could be good idea. Making stable release should be a lot easier with passing and improving test suit. If that is considered too invasive branching could happen when the candidate for stable branch goes to RC.
Time-based stable releases aren't suitable for Wine. We need bug targets for stable to be meaningful
Another way to make everyone happy with "unstable" would be mark every 12th wine release as stable and just branching it for bug fixing. Then bug fix release could be 1.1.12.X.
12 wine releases is 6 months. This would mean 2 stable releases each year and a LOT of extra work, especially considering the release candidate stages and code freeze. Re the automagic sources.list file:
Why not just make separate package for installing the source file. It could be named as wine-installer. Then post-install hook can download and install the real wine package.
This sort of thing has been suggested already, and I would prefer to go this way IF we were to do it at all, but other people have objected to another package.
participants (8)
-
Alexandre Julliard -
Austin English -
Ben Klein -
Branan Riley -
Dan Kegel -
Pauli Nieminen -
Remco -
Scott Ritchie