<snip> >My topics were.. >1) Lets try a version of Debian Etch without the binary firmware
Go for it. If it is something you want to see, then there is nothing stopping you from trying. <snip> >3) Lets try a medium ground between stable and testing. Why? I don't really see your point. >From my perspective on what you have said in your email, I think this is a really bad idea. We all know how it works right now, but let's just go and follow the logic of the current release method. The journey begins in Sid (Unstable). After a predefined and well regulated set of criteria are matched we get Testing. When testing has gotten to the point of a good release, the code base is frozen and we get Release Candidates. After the kinks are worked out in the RC's we move on to Stable and when the life cycle runs again we end up in oldstable. What you are proposing is that packages move from Unstable, to a Testing alpha package, then to Testing which would be the basis of the RC's, and then onward to Stable. But what has that gotten us besides an extra layer of hassle for the developers? What new criteria and standards will be required to make the move from testing alpha to testing beta? You say "no major block/crash-like problems", but isn't that what Testing is for already? >From my understanding, Testing was and is never meant to be an 'always usable always working' OS. Testing is for /testing/ purposes. Stable is for production. If you want to run /Testing/ on a "production" system then you are on your own. If you want a stable environment, use stable! If you need packages in testing, then risk having things in a bit of turmoil. I understand completely the need for packages that are in testing and may not be in stable. I have a certain server that I was unable to build with Debian Stable as there were too many conflicts with the 64bit drivers in Stable. So I built the server with Testing. I have to be much more careful with that system when I do upgrades because I can't afford to be happy-go-lucky with it. However, I have another system that was explicitly built for upgrading and updating Testing to /test packages before deploying them/. Quite the idea, I know. Too bad I can't claim credit for it. :-) Trust me, I understand how frustrating things can be when Testing breaks. Yet, I just don't see the solution in maintaining another level of packages that may or may not break within testing. From your email it sounds like you think it will be a simple extra package layer, but from my understanding of how things work in Debian...I think it is going to be a lot of work to implement and maintain. Then again, I am not one of the big developers who knows the complete ins and outs of the process so maybe I am wrong. Personally, I would feel bad for the developers who would be forced to upkeep an unstable, a testing alpha (may or may not break), a testing (may or may not break), and a stable release version. It would be like having a version of testing as a perpetual Release Candidate. I don't really care to wish that on the developers. I would like to see a well standardized release system. I think that is one thing that Mark Shuttleworth is doing right over at Ubuntu. I personally think that a 6mo release cycle is a bit much, however, would it be really difficult to pick a date once a year and just state something like "Every August 1rst testing is frozen and a release will be made by the end of September!"? That way the time frame between stable releases isn't absurd and everyone knows when they need to have their code in place. It isn't an arbitrary date that developers may or may not be aware of. Again, this is my opinion, but I think that would be much easier on the developers then a perpetual RC and I am all in favor of making the lives easier for the developers. If I completely misunderstood you, please correct me. I just don't see your suggestion as just a simple extra package to maintain. Just MHO. Chris Stackpole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
