Re: new packages freeze policy
On 2007-08-31 00:12:41 -0700, Scott Ritchie wrote: On this note, I got completely confused by the deadline. I read that the upstream version freeze deadline was August 30th, so I planned to upload my packages on the 30th. I guess you mixed up UpstreamVersionFreeze and NewPackage for Universe Freeze. The first was already on August 16th. In other words, my package (Wine) is a day late and I'd like it reviewed anyway. Although, Wine has gotten about 3 UVF exceptions for the past three releases, so I'm not particularly worried. It's in REVU now anyway. You are already two weeks late (for UVF) as wine is not a new package. Regards, Michael -- 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: Non-critical bug fixes/new hardware drivers in stable releases?
Tim, While I can see the merit of keeping changes to stable to a minimum, it seems like the existing policy of Ubuntu (and many distributions - I'm not blaming Ubuntu in particular) is leaving many users out in the cold with regards to their issues until the next release. Backporting changes is risky. Ubuntu makes the decision that security fixes are worth the risk of backporting. If you are talking about changes that are available in later releases, then the affected users are able to upgrade. In my opinion, it is more important that we don't break the machines of people for whom everything is currently fine. I would love to see Ubuntu backport all new features to past versions, but that would leave little point in having releases at all. It would make it nearly impossible to check quality as the system would be in continual flux. In order to backport non-critical/security updates, we would need people testing those updates - people who could be working to make the next releases better. With limited resources, I think system stability on past versions would suffer. Aaron -- 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
Should we split codec files?
Hello all, I am using Gutsy Tribe 5. I was just sent a wmv file from somebody and was finally able to try the fancy Gnome-app-install multimedia codec installer. The list showed me two entries, both of which apparently contain codecs for large numbers of formats. It occurred to me that, to play my one file, I was going to have to install codecs for far more formats than I wanted to play. More importantly, I was going to have to install far more patent-breaching files than I theoretically had to. In addition, I have cruft installed that I don't need. In the past, it wouldn't have been a great idea to have numerous packages, as it would make installing them more difficult. Now that the process is automatic, it makes sense to me that we should enable the user to install (and infringe patents) to the minimum extent necessary. Splitting codecs would also have the advantage that a dedicated codec package (this is an example, please don't shoot me for inaccuracy) like fluendo's mp3 decoder would get a fair run in the popularity contest against the composite packages. At the moment, everyone has to install Gstreamer-ugly for so many types of file. This means that the (more legal, as I understand it) fluendo codec never gets installed. That, in turn, skews the popularity contest results when somebody is deciding which codec to install when their mp3 doesn't play. We could always create meta-packages with the same names as the old packages. Does anybody else think that this would be worth the effort? Am I better to create a spec or to post bugs against gstreamer-ugly etc.? Thanks in advance, Aaron -- 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: Non-critical bug fixes/new hardware drivers in stable releases?
Backporting changes is risky. Ubuntu makes the decision that security fixes are worth the risk of backporting. If you are talking about changes that are available in later releases, then the affected users are able to upgrade. In my opinion, it is more important that we don't break the machines of people for whom everything is currently fine. I'm not talking about new features (aside from possibly new drivers). I'm mainly talking about bugs that, while not security/data loss bugs, are still significant annoyances. The HAL bug I mentioned earlier in the thread is the perfect illustration of what I mean. -- 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: Default option for volume hotkeys (speakers/headphones)
4) Alter the kernel so that it binds the headphone and master channel together. That's how it's handled on various pieces of hardware. A bug suggesting that this be done can be found at: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/124662 I assume that, seeing as nobody suggested a better solution, Matthew's method is the best way to proceed. Thanks for the assistance, Aaron -- 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
