A proposal for an always-releasable Debian
lwn.net
lwn.net
"International Space Station Goes Open Source, Dumps Windows XP for Debian"
"Google's cloud dumps custom Linux, switches to Debian"There are such issues as which version of libxml, libopenssl and even glibc certain packages work with (or especially, do not work with).
So, eg nginx upstream might test (mostly) against an upstream release of openssl and some libc, while the apache web server might be more conservative (this is a made up example, tomcat, especially legacy versions such as 6, might be a better example than apache httpd).
The testing issue is a big problem as up streams often have poor tests but that is an upstream issue really. Maybe the best solution is to provide CI frameworks for upstream to use that support current and future Debian versions easily (something like Travis but with more OS versions).
Even so, 10 months is a bit much. If the freeze were shorter, then Debian would have newer software. Fortunately, Debian releases are made roughly every 2 years, but even when Debian ships, it's already several months behind.
This isn't a problem for most servers, but it's a definite pain for developers like myself who use newer versions of software (extreme example, I use Arch) then try to backport to whatever's in the Debian repository. Sure, newer versions of software can be installed, but that kind of defeats the purpose of running Debian in the first place.
A shorter freeze means newer software in a release, which may reduce the need/temptation to use a package not in the stable repository, which is better for everyone.
In long form: I think Debian should focus on getting the slowest-moving targets and major package-management design and minimally necessary policies well before, and above, faster-moving targets like UI and experimental features, etc... This means rethinking repos with an eye towards community division of labour along lines like turnover time (some tools simply haven't changed much in 20 years), popularity/necessity (kernel support, bootloaders, libraries), and bleeding-edge version expectations (desktop). In practice, Debian is pretty monolithic. People mostly install what's in their primary repo (the walled garden problem).
In practice, IMHO, this would mostly boil down to making it easier to pull in separate repositories under one install, layering them on those provided by stable and it's official installer, and other special-purpose repositories (for example, with an distro-specific virtual package to articulate the dependencies and make upgrades/downgrades/sidegrades clear and easy). I recognize a lot of motion in related areas (blends, debian live, stuff outlined in the article, etc - and a technically savy user can modify their sources), but I think that there is more than necessary being attempted under the name "Debian Stable" and this has been distracting from "stability" (and costing effectiveness). Specifically, the fastest-moving targets should not be considered part of Debian at all, IMHO, but separate distributions along lines that maximize stakeholder ownership and improve turnover time. It then becomes necessary to allow seamless distribution (repository) layering and interdependence (something the package manager can already do, but is difficult in practice for more than a few sources, even to experienced users). In essence, the package+repo system does not currently help much with forks and merges at that level - even though it is one of the most common problems in open software development. (Git has spoiled me.)
Ideally, IMHO, all Debian-based distributions should be installable from the same installer, even if they may want to provide their own (like Ubuntu), something that would be made possible because the packaging standards would have solidified to the point that other distro-builders (repo, and special-purpose package maintainers) can rely on them (my hope for "stable").
That said, I am just another "user" who prefers things not break over them looking brand new.
The one thing though that I count on getting replaced on that stack is MySQL, though the M might stay. If Debian hasn't done that already.
This simply isn't true. Web development is done in many languages, and while the P in there stands for several of them, it's entirely inaccurate to suggest that any or all of them are somehow a default value deployment or development.
Web development deployment environments are not the sole purpose of Debian, and the purpose of non-'P' development languages is not to serve as potential but perpetually-sidelined alternatives to this arbitrary default.
The fact that Debian has a "task" for LAMP is really a reflection of how simple the architecture is: you can press a button to install LAMP and then you can install any one of the applications I mentioned on top of it. LAMP is not a "default" by any means, it's just something easy to stick in the package manager, something that a lot of people use.
Sure, you can also press a button to install Rails or Django, but those are more self-contained and don't need to be packaged separately as tasks.
The reason LAMP is mentioned as important is because a lot of people do use it and do depend on it. In an ideal world, every application would work on Debian. But with finite resources, you make a list of the things you want to test the most.
Having a LAMP stack that works up and running in one command is great for people who just want to FTP up a bunch of folders and be done with it.
People developing on Rails etc are probably developing against some specific version rather than "whatever happens to be in the repo" and are more likely to be either using a specialist environment like heroku or bring their own puppet setup to the party.
You can write awful code with php or you can write great code with php or something in-between, it's up to the developer.
The fact that you go so out of your way to trash php going to the lengths to question "why lamp is treated as a first class citizen", actually just goes to show your own utter dependency on development environment and existing code base.
So if there is crappy code out there, suddenly you become incapable of writing good code? No, so why sit around on sites and trash a programming language that the final product completely depends on the skill level of the person writing it.
You touch php and all you write is shit code? Maybe you are just shitty at programming? You don't "have" to use ruby or python to write clean, well thought out code. Please get off your high horse and understand that people get shit done using the lamp stack, and give it a rest.
Do you berate any other programmer anytime you see them writing perl as well? You are not superior to anyone because of the technology stack you use.
edit: how about you downvoters, actually come up with a coherent response and tell me why I'm wrong instead of treating this site like reddit and downvoting what you don't understand.
eddit2: I've noticed you have a nice github repo, which includes https://github.com/radiosilence/Ham All of your code looks clean and very decent, I'm just pointing out that php is obviously a good enough language for you to waste your own time developing in it!
There is nothing to stop Debian users from using Rails, Django, Node.js, or any of the other alternatives to LAMP. SOme of them are even packaged in Debian.
This is lecturing: "If you are anything close to hacker do yourself a favor and use something else."
Packages needing newer versions of glibc, automake/autoconf, gcc/clang/ruby/python/perl etc are still tricky though.
Debian guys should really do something like OpenBSD package flavors. Sometimes you just don't need X,Y or Z support and it's pain to do this kind of stuff with Debian. I'm not sure if that is even possible in such rigid package managemenet system. Other thing would be to allow files/libs as dependencies. Those two things would give people more freedom and flexibility, but they are from start trying really hard to be anal with packages (even given the fact that .deb system is , at the same time, best and worst thing about Debian). So, guess, just forget about it.