Hardy: Time for sync project focus and here is how
Hi all, I'm posting this here because that is what some guy in #ubuntu-devel told me to do to get a better discussion going. Basically in the launchpad blueprints list there are a few tickets to look at for existing complete ideas: https://blueprints.launchpad.net/ubuntu/+spec/ltsp-palm-devices https://blueprints.launchpad.net/ubuntu/+spec/pim-device-sync https://blueprints.launchpad.net/ubuntu/+spec/pocket-pc-support https://blueprints.launchpad.net/ubuntu/+spec/pda-support-out-of-the-box https://blueprints.launchpad.net/ubuntu/+spec/syncintegration The new idea is to use _all_ the tools we have at our disposal to engineer a system which will be robust, functional and should be made to show how god awful syncing on other platforms is currently done. Tools: OpenSync, Python/Gtk, HAL/DBus, BluetoothTools The Plan: https://wiki.ubuntu.com/PimSyncPlan Er and yes, hit me over the head with a clue by 4 if I've done some wrong, guessing how to do this. Best Regards, Martin Owens -- 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
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: Non-"critical" bug fixes/new hardware drivers in stable releases?
On Friday 31 August 2007 20:27, Aaron Whitehouse wrote: > 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. > This is what we have *-backports for. Each package gets at least minimal testing before it's approved for packporting. I don't recommend activating the backports repository for your release and installing everything, but for selected packages it can be very useful. Scott K -- 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?
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
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: new packages freeze policy
On Thu, 2007-08-30 at 19:01 -0400, Cory K. wrote: > > Sebastien Bacher wrote: > > hi, > > The archive admin members quickly discussed this and the packages > > uploaded before the freeze will be reviewed (no need of an uvf > > exception) for this cycle. Soren has updated the wiki to clarify that > > the packages should be uploaded some time before the freezes and that > > the archive team can take some extra days to process those > > > > > > Sebastien Bacher > > > This is indeed great news for this cycle, but... > > "packages should be uploaded some time before the freezes" > > If thats going to be the policy, whats the point of the freeze date? > Maybe moving the date up would be better? "some time before the freezes" > is rather vague for people trying to work with the proper deadlines. > > -Cory K (Ubuntu Studio lead) 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. As it turns out, the deadline is at the stroke of midnight, UTC. When my boss tells me "This needs to be done by Friday," I generally don't interpret that as "I need this on my desk before midnight on Thursday." 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. Thanks, Scott Ritchie -- 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
