Bjorn Stenberg wrote: > been looking at the "excuses" page[0] and was struck by how very old some > packages are in testing, yet only the very latest bleeding edge version > from unstable appears to be considered for inclusion. > > Am I misunderstanding something, or does this approach not "punish" > projects that adhere to the Open Source motto "release early, release > often"? It all depends upon your goal. If your goal is to have the latest developer versions of code then you might be happier running linux from scratch and polling the developer sites often. You might find that a significant effort, however. Things are often incompatible with other project software and those details need to be worked out. If your goal is a reliable and robust distribution of working software then the daily change of developer versions works against you. Something is always broken. At any given moment the snapshot may be either working or broken and it is impossible to determine which at that momement. In that case you need a staging area in which to work through the problems and prepare for the next release. The entire process of moving packages through Debian's 'ustable' to 'testing' to 'stable' release areas is an attempt to make the process of getting software into a releasable state work as well as it can be made to work. Which means that Debian Developers need to know how the software release process works so that they can drive the system to release. If the DD misunderstands this system then they might be "punished" by it as you refer in your note. But it is well documented and available on the debian.org web site. I suggest reading through the developer manuals here http://www.debian.org/doc/. Many consumers of the Debian distribution are not desiring the daily build model of software. That causes them thrash as well. Their own internal software is broken daily by those changes too. Would you want your bank to run the daily snapshot? Probably not. You don't really care if the payroll is running with the latest KDE bits but you do want your paycheck to be correct. How about doing VLSI chip design of the next killer IC? Again probably not as in that case you would only want to update between projects. Once committed to doing the work you want to know that you won't be distracted by your infrastructure changing out from under you. Customers like it if you can deliver your work on the schedule to which you committed. If you are using free software in your business then the stability of the software affects your business and your ability to do your work. Therefore updating your operating system from stable release to next stable release works best since you can focus on your business and avoid needing to concern yourself with tracking the daily snapshots. This maturity level is one of the things differentiating Debian from hobby systems. The release early and release often model still works for the development cycle. A core set of users and developers tend to adopt specific packages. For example I help mother over the coreutils package. When new versions are posted I compile and test it on my systems and report back trouble. This is completely outside of even Debian unstable. This would be pre-experimental! An upstream release is not the same as a Debian release. Think of one as the research lab and the other as manufacturing and you would have a better picture. > Hypothetical example: > > Project X makes an effort to prepare a solid release, squashing all RC bugs > and making sure each target builds flawlessly. They bag it, label it "3.0" > or whatever and release it. The package goes into unstable and, being a > non-critical update, needs 10 days to become a "Valid Candidate"[1] for > testing. > > During the release effort, a number of patches were submitted to the > project but were delayed until post-3.0. This is pretty normal. Now that > 3.0 is out the door and the users have a stable version to work with, these > new patches go in and a new unstable version 3.1 is released. This version > has some RC bugs, or doesn't build on all platforms, or otherwise breaks > one of the five rules for inclusion in testing. > > Since the testing scripts only check the latest version, testing will never > consider the stable and working 3.0 version but will reject the unstable > 3.1 version and instead keep the old and outdated 2.0 version. I recommend reading this reference specifically. http://www.debian.org/doc/developers-reference/ch-resources#s-experimental This basically says that unstable is the staging area for getting to a new stable release. Don't put software there that you think might not work as a release cadidate. Those packages should go into the experimental area instead. Your words specifically were that 3.0 was the stable version of your hypothetical software. The DD wants that to release and therefore must keep that package stable. By immediately patching to the new 3.1 version and introducing experimental features they are setting themselves up for problems. They are not working toward getting the package into stable. They are misunderstanding the release process. They are no longer driving it but being driven by it instead. No one is claiming that the current release process is perfect. Far from it. On debian-devel there are often heated^Hlively discussions of problems and improvements to the process. It has been evolving and will continue to do so. I encourage you to monitor and participate in the discussions there. > [...] why does it work like this? Would it not be better to track > all versions and merge the latest version that fulfills all > requirements? That is an interesting idea. However, I can't envision a way in which that would fully work to handle the problems. Keep cooking that idea. However, your note does raise the issue that it might be best to have a development track for Debian which is separate from the stable release track. That way the "today's build" model for a development distribution would not negatively impact the process of getting Debian's 10,000 packages simultaneously ready for release in the stable distribution. And sometimes you don't know a version was a good version until a later version has broken things. Bob
Attachment:
pgpcWgFLS7zFM.pgp
Description: PGP signature