[64studio-devel] New kernel & GNOME backports

[Free Ekanayaka]

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.

  DJ> Consider that a distro like Ubuntu is released every six months, but
  DJ> that it usually takes at least a year to produce a printed manual and
  DJ> get it into the stores.

  DJ> I think Etch is actually a pretty solid platform for the next couple
  DJ> of years on the desktop; we should be able to make any updates we need
  DJ> without changing things like gcc and glibc versions. Perhaps the next
  DJ> thing we should do is look at the open tickets and decide which things
  DJ> we should tackle for a 2.1 bugfix version, and which other things
  DJ> should be dealt with later.

Yes that would be a good thing.

  DJ> Personally, I think the sound and graphics applications are in pretty
  DJ> good shape. I believe the next step is to make video editing and
  DJ> compositing really well integrated with Jack audio, so you can have
  DJ> your whole multimedia project controlled from a single transport,
  DJ> without having to mix down or export anything until the final
  DJ> stage. Also, we need to help the LV2 developers finalise the new
  DJ> plugin standard and look at creating custom GUIs to make these plugins
  DJ> more user-friendly.

The problem with video applications are often the patents. I was
thinking about the possibility of collaborating with projects like
Marillat and try to support applications like cinerella through
third-party repositories, which the use can activate after the
installation. Of course it's not the most ethical of the solutions,
but in the mid-term is probably the only way to offer a kind of
support for such applications.

Ciao!

Free