Re: GIMP *final* release for Gutsy?
Aaron C. de Bruyn: > So you are saying that we should react to new versions by packaging the up on > the basis that there are probably users that could maybe be having bugs but > haven't reported them. We should react on that basis only to new, stable versions of packages where the current version in Ubuntu is an unstable, non-final version. Upstream is presumably not-final for a reason. > I'm sure by now just about every package in Gutsy has an updated version. It > would take a *TON* of development time constantly updating packages. We'd only have to do this *once* for each package of which a non-final version was released in Ubuntu final. Once the final version of the package is available, there need be no more updates (beyond what are already done). Hopefully a commitment to doing this extra packaging work after the Ubuntu release would dissuade us from including non-final package releases in final Ubuntu releases. -- Greg -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
Aaron C. de Bruyn: > It boils down to this: If users aren't running into bugs, why repackage? Because having “Release Conadidate” on the splash screen and “rc” in the About box gives users the impression that this is not a trustworthy, final version of GIMP. And because the version number the package advertises itself as is not the actual version that it is in terms of upstream bug fixes. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Password-protect grub interactive commands (was: rationale of root access from boot)
On Nov 12, 2007 2:15 PM, Scott James Remnant <[EMAIL PROTECTED]> wrote: > On Sat, 2007-11-10 at 14:06 +0800, Nicolas Deschildre wrote: [...] > > For the simplest installations, GRUB could perhaps read /etc/shadow and > accept any user's password -- but that would be error-prone, open to > exploit, and wouldn't support the kinds of installations you talk about > later in this thread: corporate environments which often use centralised > authentication. You're right, I overlooked that. And adding Jan Claeys' good remark on the keyboard layout, I'm now convinced that password protecting grub is not good by default. Thanks for your comments. This is EOT for me. Nicolas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
Greg K Nicholson: > no more updates (beyond what are > already done). By this I meant “no more updates (other than the current normal update processes)”. I certainly didn't mean freeze all updates on that package forever. That would be silly :) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: A Wine-like compatibility layer to run Mac OS X programs on Linux?
Am Montag, den 12.11.2007, 00:29 +0100 schrieb Jan Claeys: > Op vrijdag 09-11-2007 om 05:32 uur [tijdzone +0100], schreef Sebastian > Heinlein: > > AFAIK you are not allowed to virtualize MacOS. > > Which is not enforceable in how many countries...? :) Nevertheless you should respect the authors' decisions on how and under which license they want to publish their software. Nobody is forced to use it. As an Open Source developer I would also demand to do so for my software too. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Laptop touchpad configuration
Hi! Is there a simple way of configuring Ubuntu to disable the touchpad on the laptop in case it detects a usb-mouse connected to the computer? It's a nuisance to go through the preferences to disable the touchpad. I have a Fujitsu-Siemens Amilo L 1300. //Matthias Andersson -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Windows Program Support
Am Montag, den 12.11.2007, 00:21 +0100 schrieb Jan Claeys: > Op vrijdag 09-11-2007 om 02:24 uur [tijdzone +0100], schreef Sebastian > Heinlein: > > Perhaps we could perform a ClamAV scan before running a Windows > > application? > > Does that need to have a clamav daemon running (IME, it isn't very > reliable...)? No daemon would be needed. If you want you can download my "winelauncher" prototype and try it. It is already fully working. Generally detecting perhaps only the half of all viruses seems to be bettor than none. But I don't have got any data to compare anti-virus programs. > (Also, there is ClamFS for FUSE, would that be useful.) Not really. The FUSE can be used for live scanning data. You would have to copy all the files to the FUSE. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
Greg K Nicholson wrote: > We'd only have to do this *once* for each package of which a non-final > version was released in Ubuntu final. Once the final version of the > package is available, there need be no more updates (beyond what are > already done). > > Hopefully a commitment to doing this extra packaging work after the > Ubuntu release would dissuade us from including non-final package > releases in final Ubuntu releases. > I suspect that if we actually had people offering to do this (and this is quite similar to the already-existing backports), and did reasonable QA tests, etc, then this would all become more feasible. But, when you're trying to stretch already busy people, who are mostly volunteers, and will tend to work on whatever they like, and to try and fit them into your mold of what you want them to do, you're always going to meet trouble. So, anyone willing to step up to work on stable release updates? If you don't know packaging, you can learn it. Same applies to bug triaging. Don't even bother giving excuses such as "I can't program, I can't do actual development" - well, start with something simpler like bug triage, and then work your way up. How do you think the current developers got where they did? All these excuses seem to be hiding the major excuse - "I want this fixed, but I want someone else to fix it for me, and don't want to have to put in the hard work myself" Just a thought... Hobbsee -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
On Mon, 12 Nov 2007 22:47:34 +1100 Sarah Hobbs <[EMAIL PROTECTED]> wrote: > Greg K Nicholson wrote: > > We'd only have to do this *once* for each package of which a > > non-final version was released in Ubuntu final. Once the final > > version of the package is available, there need be no more updates > > (beyond what are already done). > > > > Hopefully a commitment to doing this extra packaging work after the > > Ubuntu release would dissuade us from including non-final package > > releases in final Ubuntu releases. > > > I suspect that if we actually had people offering to do this (and > this is quite similar to the already-existing backports), and did > reasonable QA tests, etc, then this would all become more feasible. > > But, when you're trying to stretch already busy people, who are > mostly volunteers, and will tend to work on whatever they like, and > to try and fit them into your mold of what you want them to do, > you're always going to meet trouble. > > So, anyone willing to step up to work on stable release updates? If Ah yes, BUT you need to be a MOTU to upload new releases and the process of becoming a MOTU or contributions by non-MOTU has been discussed before. Just see the archives here (GetDeb Project (Why I participate)) or on the MOTU list (Subject: non-MOTU Hopeful contributions (was:: GetDeb Project (Why I participate)) > you don't know packaging, you can learn it. Same applies to bug > triaging. Don't even bother giving excuses such as "I can't program, > I can't do actual development" - well, start with something simpler > like bug triage, and then work your way up. How do you think the > current developers got where they did? All these excuses seem to be > hiding the major excuse - "I want this fixed, but I want someone else > to fix it for me, and don't want to have to put in the hard work > myself" Well I package software, I'm just not a MOTU for reasons discussed in the previously mentioned threads. > > Just a thought... > > Hobbsee > -- Peter van der Does GPG key: E77E8E98 IRC: Ganseki on irc.freenode.net Blog: http://blog.avirtualhome.com Jabber ID: [EMAIL PROTECTED] GetDeb Package Builder http://www.getdeb.net - Software you want for Ubuntu signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
On Mon, 2007-11-12 at 07:13 -0500, Peter wrote: > On Mon, 12 Nov 2007 22:47:34 +1100 > Sarah Hobbs <[EMAIL PROTECTED]> wrote: > > > Greg K Nicholson wrote: > > > We'd only have to do this *once* for each package of which a > > > non-final version was released in Ubuntu final. Once the final > > > version of the package is available, there need be no more updates > > > (beyond what are already done). > > > > > > Hopefully a commitment to doing this extra packaging work after the > > > Ubuntu release would dissuade us from including non-final package > > > releases in final Ubuntu releases. > > > > > I suspect that if we actually had people offering to do this (and > > this is quite similar to the already-existing backports), and did > > reasonable QA tests, etc, then this would all become more feasible. > > > > But, when you're trying to stretch already busy people, who are > > mostly volunteers, and will tend to work on whatever they like, and > > to try and fit them into your mold of what you want them to do, > > you're always going to meet trouble. > > > > So, anyone willing to step up to work on stable release updates? If > Ah yes, BUT you need to be a MOTU to upload new releases and the > process of becoming a MOTU or contributions by non-MOTU has been > discussed before. Just see the archives here (GetDeb Project (Why I > participate)) or on the MOTU list > (Subject: non-MOTU Hopeful contributions (was:: GetDeb Project (Why I > participate)) But you don't need to be a MOTU to do the work, and since gimp is in main, it doesn't much help being a MOTU either. The uploading to the archives part is by far the quickest and simplest part of the whole process. Once you've updated the packaging, and tested it thouroughly yourself it will be much less work (read: much more likely to happen) for the core-dev to pick it up, check it for sanity, and (hopefully) upload to gutsy-proposed. Where you now get to thoroughly test it before it gets into -updates. Not helping because you don't have upload privilages to the archives seems a pretty poor excuse. You really don't need to be able to upload directly to the archives to usefully contribute! You don't have to be aiming to become a MOTU in order to usefully contribute. Chris Halse Rogers signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
On Mon, 12 Nov 2007 23:52:29 +1100 Christopher James Halse Rogers <[EMAIL PROTECTED]> wrote: > > But you don't need to be a MOTU to do the work, and since gimp is in > main, it doesn't much help being a MOTU either. The uploading to the > archives part is by far the quickest and simplest part of the whole > process. Once you've updated the packaging, and tested it thouroughly > yourself it will be much less work (read: much more likely to happen) > for the core-dev to pick it up, check it for sanity, and (hopefully) > upload to gutsy-proposed. Where you now get to thoroughly test it > before it gets into -updates. It's not as simple is that, you need a sponsor for your patches to be approved. And currently there are 45 "bugs" in the sponsorship queue, 5 are committed, 4 in progress, 3 triaged, 16 confirmed (one as late as 2006-03-03) and 17 new the oldest dating back to 2006-12-14. So it comes down to workload at the MOTU side. I won't discuss this here anymore, like I mentioned we have had this thread before on two mail listings. > > Not helping because you don't have upload privilages to the archives > seems a pretty poor excuse. You really don't need to be able to > upload directly to the archives to usefully contribute! You don't > have to be aiming to become a MOTU in order to usefully contribute. > > Chris Halse Rogers -- Peter van der Does GPG key: E77E8E98 IRC: Ganseki on irc.freenode.net Blog: http://blog.avirtualhome.com Jabber ID: [EMAIL PROTECTED] GetDeb Package Builder http://www.getdeb.net - Software you want for Ubuntu signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
I think we're only *surprised* that this isn't being done already because the Ubuntu team are usually so unreservedly awesome, and have usually figured out a way to make stuff happen and have actually made the stuff happen, before we were even aware that we *wanted* said stuff to happen. Generally. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Benefit of Compiz to audio work?
The Ubuntu Studio team is considering shipping Compiz (with a minimal config) in Ubuntu Studio-Hardy 8.08. Some have said that moving the drawing of windows off the the GFX card would help the load on the CPU and thus keep xruns to a minimum. Any thoughts/ideas on this one? -Cory \m/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Benefit of Compiz to audio work?
On Mon, 2007-11-12 at 10:25 -0500, Cory K. wrote: > The Ubuntu Studio team is considering shipping Compiz (with a minimal > config) in Ubuntu Studio-Hardy 8.08. > > Some have said that moving the drawing of windows off the the GFX card > would help the load on the CPU and thus keep xruns to a minimum. > > Any thoughts/ideas on this one? > > -Cory \m/ > I find that window management has less artifacts with Compiz (so revealing a previously covered window won't end up with empty bits of screen for a split second as it redraws). However, I do notice slight lag when moving windows and things in Compiz compared to Metacity, Kwin, E16, etc. This may just be the wobbly plugin though. I have become used to it, but a Linux using friend did comment that it seems a bit sluggish on my laptop (which is using XGL with ATI's proprietary driver, and XGL seems to like taking up CPU). For intensive workstation use I wouldn't really recommend using Compiz, just because every clock cycle Compiz uses would hinder the user's actual workflow. Since Macs are used heavily in multimedia-type situations I think it would be sensible to enable it for less intensive work, especially graphics (since it may reduce the amount of redrawing the applications need to do), as the Mac's subtle 3D is a nice touch which may be missed by people trying Ubuntu Studio. Just my thoughts on the issue, Chris Warburton -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Password-protect grub interactive commands
Chris Warburton wrote: > On Sat, 2007-11-10 at 17:41 +0100, Thilo Six wrote: >> Milan wrote the following on 10.11.2007 16:56 >> >> <<-snip->> >> >>> All in all, I'd rather suggest to activate password-locked GRUB, but I >>> understand this question is hard to decide. Does anybody see other >>> agruments on both sides? >> against: >> helping users on mailing lists or irc, with boot problems. >> > Exactly. In my opinion password protecting GRUB by default will cause > headaches for a number of people, but it won't really make the system > any more secure since physical access is gained by that point (thus > allowing live media, removing the hard drive, etc.). > > The only extra security measure I think is worth debating is full disk > encryption. Such a thing would obviously be a nightmare for tech > support, but since there are real security benefits I think it is worth > considering and at least looking into. To me there is very little to be > gained by password protecting GRUB though, so I'm against. > > Thanks, > Chris > > I understand both opinions since there is a need for security and for usability but I think there is another option than a grub password. Ubuntu handles it similar to Windows XP Home which doesn't ask for a administrator password during installation (XP Pro asks) so it was always possible to use F8 to boot to recovery mode and login without a password and to reset the user password. So it is not possible without some knowledge to gain basic security. Imagine Ubuntu is installed on PCs in sales area of a big store. A customer can just reboot the PC, choose recovery and that's it. He can make everything. Even if home is encrypted he is still able to install a kernel module or a back door program which logs the password. OK, a administrator should know how to protect Ubuntu but basic security is important I think. The standard configuration of the PCs in stores I know is Windows 2000/XP Pro., only boot on hard disk and Bios password. This would protect a standard Windows Pro installation but not an Ubuntu one. Of course you could remove the battery but you need a screwdriver and many professional PCs have a lock and/or intrusion detection (make noises after next boot). I like the way Ubuntu handles root that always sudo is needed so why we don't make it with Recovery mode too? Just don't autologin root like root has a password. Why not let the user login in with his user and then use sudo to gain root access or set the user password for root and disable the account? With this no grub password/lock is needed but there is still basic security. If you are afraid if people forget their password why not make a little program on Live CD which can make that for you? Everyone can boot a CD and reset their password but only if they have bios/boot access like every private person. Btw. atm it is much more harder to repair grub (e.g. after Windows reinstallation) then to reset a password. Administrator should know how to secure a system but we should make it as easy as possible to prevent mistakes I think. Thanks, Unggnu -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Password-protect grub interactive commands (was: rationale of root access from boot)
Nicolas Deschildre wrote the following on 12.11.2007 11:04 <<-snip->> > This is EOT for me. > > Nicolas Nicolas if i sound rude in my last mail i apologize for that. bye -- Thilo key: 0x4A411E09 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Password-protect grub interactive commands
OK, just forget the GRUB password idea, I've understood how it can become a complete mess. Sorry for the idea... But what about that? unggnu wrote: > > > I like the way Ubuntu handles root that always sudo is needed so why we > don't make it with Recovery mode too? Just don't autologin root like > root has a password. Why not let the user login in with his user and > then use sudo to gain root access or set the user password for root and > disable the account? With this no grub password/lock is needed but there > is still basic security. > If you are afraid if people forget their password why not make a little > program on Live CD which can make that for you? Everyone can boot a CD > and reset their password but only if they have bios/boot access like > every private person. > I really second this idea, doing that and locking GRUB for any modification of kernel parameters except recovery mode would be a real security improvement. We should not let Windows XP overdo Linux here. And anyway, there is the LiveCD if really needed. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Benefit of Compiz to audio work?
On Nov 13, 2007 12:25 AM, Cory K. <[EMAIL PROTECTED]> wrote: > The Ubuntu Studio team is considering shipping Compiz (with a minimal > config) in Ubuntu Studio-Hardy 8.08. > > Some have said that moving the drawing of windows off the the GFX card > would help the load on the CPU and thus keep xruns to a minimum. > > Any thoughts/ideas on this one? Speaking strictly for the audio use case: I find that enabling compiz does have an impact on local CPU usage, and that running disabled frees a few more cycles for audio processing. I suspect this is an artifact of integration between the GUI toolkits and compiz, and that as compiz use becomes the base case, and support filters down the stack, this will no longer be the case. Completely guessing about the graphics / video use case, I wonder if some of the transformation filters don't tend to be bound by the GL engine rather than the local CPU. I suppose it depends on what transformations are being applied, but it may be worth investigation. -- Emmet HIKORY -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
Dean Sas wrote: >> So we're actually getting 2.4.1 (or something very much like it), but >> labelled “2.4.0rc3”? > > Precisely. Often Ubuntu packages might include patches from upstream > that haven't yet been made part of a release. See Emmet's review for the > exact details in this case. If that is the case then the package should have had the version string "2.4.0+2.4.1-rc3" to indicate that it is the release candidate for what will be 2.4.1. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
Peter wrote: > It's not as simple is that, you need a sponsor for your patches to be > approved. And currently there are 45 "bugs" in the sponsorship queue, > 5 are committed, 4 in progress, 3 triaged, 16 confirmed (one as late as > 2006-03-03) and 17 new the oldest dating back to 2006-12-14. > > So it comes down to workload at the MOTU side. I won't discuss this > here anymore, like I mentioned we have had this thread before on two > mail listings. > Most of the main developers have been away at UDS, and then at the Canonical Company Conference (All hands), including the guy who allocates the sponsorships around, for the main queue. I'm guessing it's just a particularly busy time for them, particularly as most of them are trying to get the base system merges done (ie, priority: essential stuff, toolchain, etc). And, again, MOTU != core dev. MOTU's can not upload directly to main. Therefore, it's not a question of workload on the MOTU side at all - and so i suspect that the above arguments, which all applied to MOTU, not core dev, are null and void. Excluding the quality arguments. Hobbsee -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
> Aaron C. de Bruyn: > > It boils down to this: If users aren't running into bugs, why repackage? > > Because having “Release Conadidate” on the splash screen and “rc” in the > About box gives users the impression that this is not a trustworthy, > final version of GIMP. Kinda like how hundreds of thousands of people used the old ICQ 99b (or whatever the version was) client that was listed as a 'beta' for years. ...or how people used the beta version of gmail. I honestly didn't notice that GIMP said "Release Candidate" on the splash screen until this discussion came up, and I use it daily. My wife also uses it daily, and she's not a geek like me--just a home user. She never realized it either. Maybe we're just completely oblivious. But I think most people won't care what it says--they'll just run it. ...of course someone else pointed out that it actually says "Release Conadidate" instead of 'candidate'. Heck--I missed that too. But that's something that should be fixed. Just because it says Beta or Release Candidate or isn't a final version is not a reason to update the package. Even the final, officially approved, non release candidate version will have bugs. ...and they will have to be fixed. So why not just fix the bugs when they are reported. I'm not trying to be a jerk--I just don't see the point in updating because of the version string. I do see a point in updating due to a bug. -A -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GIMP *final* release for Gutsy?
Aaron C. de Bruyn wrote: >> Aaron C. de Bruyn: >> >>> It boils down to this: If users aren't running into bugs, why repackage? >>> >> Because having “Release Conadidate” on the splash screen and “rc” in the >> About box gives users the impression that this is not a trustworthy, >> final version of GIMP. >> > > Kinda like how hundreds of thousands of people used the old ICQ 99b (or > whatever the version was) client that was listed as a 'beta' for years. > ...or how people used the beta version of gmail. > > I honestly didn't notice that GIMP said "Release Candidate" on the splash > screen until this discussion came up, and I use it daily. > My wife also uses it daily, and she's not a geek like me--just a home user. > She never realized it either. Maybe we're just completely oblivious. > > But I think most people won't care what it says--they'll just run it. > > ...of course someone else pointed out that it actually says "Release > Conadidate" instead of 'candidate'. Heck--I missed that too. But that's > something that should be fixed. Just because it says Beta or Release > Candidate or isn't a final version is not a reason to update the package. > > Even the final, officially approved, non release candidate version will have > bugs. ...and they will have to be fixed. So why not just fix the bugs when > they are reported. > > I'm not trying to be a jerk--I just don't see the point in updating because > of the version string. > I do see a point in updating due to a bug. > > -A > > we all know that version numbers don't matter and especially in the OSS world where there is no commercial reason to bump to a .0 number just to make it look stable, and for myself i could not care less wich version it has as long as it works. (there are numerous times i had bugs and crashes in so called "stable releases") but then again, everybody on this mailing list is not the target audience for "bug #1" and if Ubuntu is aiming for allround usage by the masses, some things can be learned from the competitors by spending some more time on presentation of the product. the whole purpose of Ubuntu is to bring a polished and shining desktop experience for the non-techie end user who cares more about pretty colours then the underlying processes, otherwise they might as well run Debian. i must say that Ubuntu has come a long way in achieving this, but the "Release Conadidate" definetely shows that improves still need to be made, the appearance of a splash screen is not something to be judged by a developer but by the Canonical art commision. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
