25 Feb
2009
25 Feb
'09
7:31 p.m.
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
26 Feb
26 Feb
12:31 a.m.
2009/2/26 Dan Kegel <dank(a)kegel.com>om>:
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.
2:30 a.m.
Ben Klein wrote:
2009/2/26 Dan Kegel <dank(a)kegel.com>om>:
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
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.
3:01 a.m.
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
27 Feb
27 Feb
9:25 p.m.
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>om>:
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
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.
9:46 p.m.
2009/2/28 Dan Kegel <dank(a)kegel.com>om>:
On Wed, Feb 25, 2009 at 4:31 PM, Ben Klein
<shacklein(a)gmail.com> wrote:
No more than any other distro, to be honest.
2009/2/26 Dan Kegel <dank(a)kegel.com>om>:
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. 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. 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
9:52 p.m.
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>om>:
Anyone coming from Vista would be used to UAC for program installs...
On Wed, Feb 25, 2009 at 4:31 PM, Ben Klein
<shacklein(a)gmail.com> wrote:
No more than any other distro, to be honest.
2009/2/26 Dan Kegel <dank(a)kegel.com>om>:
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. 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. 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.
10:06 p.m.
On Fri, Feb 27, 2009 at 1:46 PM, Ben Klein <shacklein(a)gmail.com> wrote:
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.
Their reply is probably "well, then do another stable release.
Our policy is that we prefer to bundle only stable releases."
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.
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. 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 ...
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
10:30 p.m.
2009/2/28 Dan Kegel <dank(a)kegel.com>om>:
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?
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.
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.
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.
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. 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 ...
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.
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".
28 Feb
28 Feb
1:50 a.m.
On Fri, Feb 27, 2009 at 2:30 PM, Ben Klein <shacklein(a)gmail.com> wrote:
Scott, that's you, right? Can you speak to that?
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? 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
2:07 a.m.
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:
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
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.
27 Feb
27 Feb
10:37 p.m.
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
10:41 p.m.
2009/2/28 Remco <remco47(a)gmail.com>om>:
On Fri, Feb 27, 2009 at 11:06 PM, Dan Kegel
<dank(a)kegel.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.
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.
10:57 p.m.
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
11:01 p.m.
2009/2/28 Remco <remco47(a)gmail.com>om>:
On Fri, Feb 27, 2009 at 11:41 PM, 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.
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.
11:08 p.m.
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
11:11 p.m.
2009/2/28 Remco <remco47(a)gmail.com>om>:
On Sat, Feb 28, 2009 at 12:01 AM, Ben Klein
<shacklein(a)gmail.com> wrote:
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!
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
11:24 p.m.
On Sat, Feb 28, 2009 at 12:11 AM, Ben Klein <shacklein(a)gmail.com> wrote:
2009/2/28 Remco <remco47(a)gmail.com>om>:
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
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!
28 Feb
28 Feb
1:43 a.m.
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:
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
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. 
27 Feb
27 Feb
10:17 p.m.
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
10:34 p.m.
2009/2/28 Alexandre Julliard <julliard(a)winehq.org>rg>:
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. 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.
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.
11:01 p.m.
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
11:05 p.m.
2009/2/28 Alexandre Julliard <julliard(a)winehq.org>rg>:
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. The following quotes are from
the start of this thread:
2009/2/26 Ben Klein <shacklein(a)gmail.com>om>:
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. 2009/2/26 Dan Kegel <dank(a)kegel.com>om>:
Maybe I'm wrong here, but that's what it looks like from current AppDB
and bugzilla status.
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.
28 Feb
28 Feb
8:47 a.m.
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
2 Mar
2 Mar
9:25 a.m.
On Sat, Feb 28, 2009 at 10:47 AM, Alexandre Julliard
<julliard(a)winehq.org> wrote:
Ben Klein <shacklein(a)gmail.com> writes:
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>om>:
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).
On Sat, Feb 28, 2009 at 12:11 AM, Ben Klein
<shacklein(a)gmail.com> wrote:
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/2/28 Remco <remco47(a)gmail.com>om>:
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. 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!
9:36 a.m.
2009/3/2 Pauli Nieminen <suokkos(a)gmail.com>om>:
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.
5578
days inactive
5583
days old
25 comments
8 participants
participants (8)
-
Alexandre Julliard -
Austin English -
Ben Klein -
Branan Riley -
Dan Kegel -
Pauli Nieminen -
Remco -
Scott Ritchie