Quoting Bastian Venthur (email@example.com): > Is that important? Unstable is frozen for nearly 1/2 year now, that's a > problem we should try to solve if we don't want to degrade ourselves to > a server-only distribution. While I don't see such a big issues in this, there is maybe room for improvements for sure. It could be by promoting experimental a different way we are doing it right now...or by adding an intermediate stage between unstable and experimental. For that latter case, I somewhat fear the (human) resource problem we would end up with as it would need more people to take care of the whole mess^W organization. What I wanted to add also is that the "problem" pointed here does not only affect desktop environments as most contributors pointed. For instance, the samba packaging team is currently facing an interesting dilemna: - our upstream is now providing 3 different branches (3.0, 3.2, 3.3) - we have upstream 3.3.* series in experimental since upstream published the first pre-releases. This helps both our users and upstream to fiddle with brand new shiny features. As this is the version we'll want to ship with squeeze, it helps preparing the work. - we have upstream 3.2.* series in unstable/testing, as the normal path to have it in lenny. We will stop at 3.2.5, which is the version that will be shipped with lenny However, upstream released 3.2.6 a few days ago and will release more and more 3.2.* "bugfixes only" versions. Those however introduce too many changes for us to safely consider this for lenny. So, where could we upload up-to-date 3.2.* packages for the benefit of our users who prefer having the last bug fix releases? We can't do it in experimental as 3.3 is already using it. When lenny is released, backports.org is the appropriate place for this, imho. However, lenny-backports will only open when lenny is released and should indeed have packages backported from unstable at that moment. For us, that will be 3.3.* So, I had another "idea": open <foo>-backports at the moment <foo> is frozen so that maintainers can upload the latest bleeding edge versions of their packages there, when using experimental is not possible for some reasons. Hopefully, that discussion (in firstname.lastname@example.org) could lead to something....we'll see.
Description: Digital signature