10 Aug 2007 15:11
Re: New kernel & GNOME backports
Hi Tim, |--==> tim hall writes: th> Free Ekanayaka wrote: >>Hi Daniel, >> >>|--==> Daniel James writes: >> DJ> Hi Free, >>>>We could try to >>>>backport individual applications (e.g. synaptic) instead of the whole >>>>suite. >> DJ> Alternatively, we could plan to backport the whole of Gnome 2.20 when DJ> it becomes available, with 64 Studio 3.0 in mind. >> DJ> However I think we have to be careful not to go 'release crazy'>> DJ> People sometimes say Debian has a long release cycle, but if you look DJ> at what Microsoft does, they put out a major version of Windows every DJ> 3-5 DJ> years and a bugfix/security update every 1-2 years. This gives the DJ> Windows application developers, hardware vendors and everyone else a DJ> realistic amount of time to adjust to the new version. Even then, some DJ> people feel like they *have* to upgrade Windows too often. >> >>You're right, but compared to Windows the Linux desktop environments a >>relatively young, and sometimes it can make the difference which >>version of GNOME or KDE you are using. Anyway, according to the report >>we received, the changes between GNOME 2.14 and 2.18 are not so >>terrific, that we absolutely want them. >> th> I confess there are few improvements in 2.18 that I can be objective th> about. It's little things that I like, like the theme manager no th> longer requesting confirmation when you drop a new version of a theme th> on it, it has saved me a bag full of mouse clicks and widget th> redrawings while I'm theme designing. Which application/package is that exactly? Maybe we could backport it while leaving the rest untouched. th> It does _seem_ a bit shinier and th> cleaner, but that is my highly subjective opinion at the moment. It th> would look good in publicity to keep a more recent version number, but th> the critical issue is really whether users can continue recording th> their album or whatever without having to get under the bonnet and fix th> things. As Hector Centeno suggested in an earlier thread, improvements th> and fixes may come to light through extended use. However, unless that th> does prove to be the case, the work involved in Free maintaining a th> backported version of GNOME is probably not the best use of time and th> energy. =| Exactly :) th> I would like to keep Synaptic 0.60, I'll have a look at it later and th> check whether the bug reports on earlier versions are reproduceable th> for me. Ok we can keep that then. th> The argument as to whether to stick with etch or move up to lenny will th> be entirely pragmatic, we know that studios require utter system th> stability, but multimedia software for Linux is still young and th> support for new hardware (like firewire, USB and wireless) and th> realtime capabilities are particularly important, this is more a th> kernel issue than anything else, but the need for kernel compatibility th> with the rest of the Operating System has forced adoption of the th> testing branch in the past, fairly soon after changes in the base th> system have settled down. This may slow down with increased software th> stability, but we will always need to keep up with new hardware. You're right, hardware compatibility is most of the times a kernel issue, you don't have to replace the whole system just to support a new video card. th> I guess our primary concerns are: functionality relating to multimedia th> use; hardware support; and fixing known bugs. In short, maintaining a th> productive usable system, which oddly enough is what we already th> have. We'd be better off consolidating 64studio-2.x with a new kernel th> and bugfixes for the rest of the summer (and enjoy a bit of sun while th> it lasts) and investigate feature upgrades in the Autumn with a view th> to 3.0. I might be able to come up with some objective arguments about th> GNOME by then. ;) That's a good plan. I think we can sport a couple more releases of the 2.x series, to make it really solid and complete. Then we think about the 3.0, with big changes like GNOME etc.. Ciao! Free
>>
DJ> People sometimes say Debian has a long release cycle, but if you look
DJ> at what Microsoft does, they put out a major version of Windows every
DJ> 3-5
DJ> years and a bugfix/security update every 1-2 years. This gives the
DJ> Windows application developers, hardware vendors and everyone else a
DJ> realistic amount of time to adjust to the new version. Even then, some
DJ> people feel like they *have* to upgrade Windows too often.
>>
>>You're right, but compared to Windows the Linux desktop environments a
>>relatively young, and sometimes it can make the difference which
>>version of GNOME or KDE you are using. Anyway, according to the report
>>we received, the changes between GNOME 2.14 and 2.18 are not so
>>terrific, that we absolutely want them.
>>
th> I confess there are few improvements in 2.18 that I can be objective
th> about. It's little things that I like, like the theme manager no
th> longer requesting confirmation when you drop a new version of a theme
th> on it, it has saved me a bag full of mouse clicks and widget
th> redrawings while I'm theme designing.
Which application/package is that exactly? Maybe we could backport it
while leaving the rest untouched.
th> It does _seem_ a bit shinier and
th> cleaner, but that is my highly subjective opinion at the moment. It
th> would look good in publicity to keep a more recent version number, but
th> the critical issue is really whether users can continue recording
th> their album or whatever without having to get under the bonnet and fix
th> things. As Hector Centeno suggested in an earlier thread, improvements
th> and fixes may come to light through extended use. However, unless that
th> does prove to be the case, the work involved in Free maintaining a
th> backported version of GNOME is probably not the best use of time and
th> energy. =|
Exactly :)
th> I would like to keep Synaptic 0.60, I'll have a look at it later and
th> check whether the bug reports on earlier versions are reproduceable
th> for me.
Ok we can keep that then.
th> The argument as to whether to stick with etch or move up to lenny will
th> be entirely pragmatic, we know that studios require utter system
th> stability, but multimedia software for Linux is still young and
th> support for new hardware (like firewire, USB and wireless) and
th> realtime capabilities are particularly important, this is more a
th> kernel issue than anything else, but the need for kernel compatibility
th> with the rest of the Operating System has forced adoption of the
th> testing branch in the past, fairly soon after changes in the base
th> system have settled down. This may slow down with increased software
th> stability, but we will always need to keep up with new hardware.
You're right, hardware compatibility is most of the times a kernel
issue, you don't have to replace the whole system just to support a
new video card.
th> I guess our primary concerns are: functionality relating to multimedia
th> use; hardware support; and fixing known bugs. In short, maintaining a
th> productive usable system, which oddly enough is what we already
th> have. We'd be better off consolidating 64studio-2.x with a new kernel
th> and bugfixes for the rest of the summer (and enjoy a bit of sun while
th> it lasts) and investigate feature upgrades in the Autumn with a view
th> to 3.0. I might be able to come up with some objective arguments about
th> GNOME by then. ;)
That's a good plan. I think we can sport a couple more releases of the
2.x series, to make it really solid and complete. Then we think about
the 3.0, with big changes like GNOME etc..
Ciao!
Free
RSS Feed