Proposal for future releases.

[shadowking]

I would like to hear from people why or why not :

- In addition to 'main' , Create an extra section(s) : desktop, kde , gnome, firefox
- Move what is considered desktop apps/tools to 'desktop' section. The core system will remain in 'main'
- Testing / Sid remain unchanged - the apps are developed with the OS as usual
- Stable 'main' remains frozen as usual , But: 'desktop' is updated where it is possible.

The ideal result should be a stable release that is reasonably up to date, Suitable for desktop users. Stability will still be better than testing or Bi-Annual updates Ubuntu style. Integration will be more seamless than stable+backports. Point updates like squeeze n half can incorporate updated apps, security fixes and maybe a new kernel.

[saulgoode]

My gut instinct is that very few "desktop" applications would be able to update without requiring that updates also be made to components in "main". It has been my experience that upstream developers do not constrain themselves to older versions of dependencies, instead making use of the latest stable releases.

While in theory there should be no significant API changes between major releases (e.g., 2.x --> 2.y), if your "desktop" maintainers choose to ignore the dependencies laid out by the upstream developers then you can not expect to receive much attention from them (of the good kind, anyway) should you encounter problems.

'desktop' maintainer: Dear devs, I am running FOO 2.6 built against BARLIB version 2.12 and ...

FOO devs: Version 2.6 requires BARLIB 2.16; how did you even get it to compile?

'desktop' maintainer: I edited ./configure to lower the BARLIB requirement...

FOO devs: Go away and never return!

[julian67]

.....Suitable for desktop users.

This makes the assumption that all people using a graphical environment are much the same. It isn't the case. Desktop applications are not only used by home users. Businesses run desktop systems, as do schools, universities, government bodies, NGOs etc etc.

Outside of regular desktop/workstations graphical/desktop applications are widely used by thin clients, another area where you really value stability and easy maintenance far above having the latest version.

You can also consider that graphical applications, even entire desktop environments, are run on headless machines with no xorg xserver, thanks to VNC.

Your idea of distinguishing graphical and non-graphical applications is perhaps not as easily done as it first seems. I suspect that the only way to accomplish it would be to reduce Debian to the standard system and put the burden of assembling, securing and maintaining everything else on to the end user community. You can see this with some of the BSDs.

A very big issue would be the quality of the packages. Most applications are not stand alone; as well as depending on other packages to build they also have to work well with other applications, both graphical and cli. Upstream there is a huge variation in the quality of releases, the release policy, the standard of documentation (if it exists at all) and so on. One of the biggest benefits of a managed distribution (when done well as in Debian) is that it ensures that the various components work well together. Documentation is written if it doesn't exist, and is improved where needed. I've been doing a lot of video encoding and transcoding recently. This is an area where multiple upstream projects feel quite happy to make barely tested releases, some being badly broken, to pay no regard at all to dependent or co-dependent packages, to introduce major revisions and changes in functionality and use, sometimes with nothing referenced in the documentation and so on. When they get it wrong they tend to claim that the other guy's project is broken. Some of this might be attributed to relentless and fast paced development and some to unfortunate policy/attitude/habit. At some point someone has to assemble a coherent collection of the related tools and ensure they all work together, don't break stuff which depends on them, and are reasonably well documented, at least to the point that the end user has a chance of successfully using them. How would it be possible to separate out the cli decoders/encoders/muxers from the graphical players/converters etc? How to make sure the latest version of the graphical MyCoolApp actually works with the stable cli version of SomeEncoderDecoder, even though the spiffy graphical app requires something much newer or perhaps even a single specific version? What to do when another just-released GUI app also requires a single specific version of the dependency...but not the same one. I promise you this will happen. Where do you document the breakage? Is the breakage now acceptable?

The way Debian models the releases actually makes more sense the more you examine it. The stable version is well tested and as close as possible to being free of release critical bugs. It's a no brainer for the end user to maintain and everything works and is documented, even stuff from upstream which in vanilla form is often broken or undocumented. Important packages with significant improvements upstream make it into backports. Meanwhile development and testing of newer versions continues and any end user willing to read some docs and explore the packaging tools can usually have their cake and eat it.

There will always be some gotchas and the distribution model (or any other) is never going to please everyone all the time. But there are choices and alternatives. As previously mentioned the BSDs are closer to the approach you suggest, with the ports system offering something like that model. But it has its downsides as well. Upgrading from release to release means a re-install, and release cycles tend to be shorter than with Debian so you might find yourself on a re-install treadmill. Only the base system gets the full benefit of security support and auditing, so instead of depending on the distro security team to handle all security issues you now depend on multiple third parties who may all be thoroughly competent and conscientious but how will you know? Another possibility is to look at Slackware but it has rather smaller repositories, doesn't handle dependency management, and you will be building a lot of stuff yourself which means you get to be your own bugtracker, security auditor, package manager, apply the patches yourself etc. Perhaps subscribing to 10, 20, or 30 different devel and security mailing lists would offer an insight into the huge burden of tedious and time consuming work a good distribution handles, allowing the end users to just run an apt-get update and get all the benefits without the labour, knowledge or experience.

[llivv]

.

[gusnan]

Also, see this:

http://wiki.debian.org/ReleaseProposals

[snowpine]

Use Ubuntu?

[nadir]

A lot of people get frustrated because they perceive the Debian stable release to be "too old", sometimes because they bought some crazy new hardware gadget which needs a very recent kernel to support, and sometimes just because they've been brainwashed to think that if they aren't running the "newest version" of package foo, then they're somehow inadequate. So they start running unstable (sid).

Use Ubuntu?

ubuntu? well, i think shadowking has explained in plain words that he doesn't like it neither.
i tried ubuntu and ubuntu-based-green-one and got to say: whatever you may say of it, but the sources.list is a mess.

go for squeeze/sid and be done with it (in the advice to use sidux i can see no sense, but the both of us seem to be different, so give it a try)
or: since you seem to have got the idea from suse, just use suse (or mandriva, pclinux, sabayon, or whatever)

This makes the assumption that all people using a graphical environment are much the same. It isn't the case.

yep.

I hope Debian doesn't change anything in the way they release stable ( just so it can be more up
to date...)

yep

[shadowking]

Right. A much more subtle approach that preserves full compatibility with existing system:

Keep everything the same as it is. Create an additional section 'stable-unofficial' that will be OFF by default. The installer will give you the option to enable or not - it will stress that for server / enterprise / max stability recommended: OFF and for traditional desktop use you may turn it ON.

What should be in this new section ?

Lets start with popular in demand apps: FF/iceweasel, OO, gimp, VLC ...

Essentially these backport packages will have a higher version number than the same packages in 'main'