David Wright wrote: > songbird wrote: ... > I can't understand that paragraph. Too many "this", "that" > and "it"s to know what refers to what.
haha, that's ok, just let it go. >> release notes may not be written and some cases may >> even be forgotten about. > > Which release doesn't have any Notes? Forgotten about > by whom? it isn't the release which happens in testing, when a package is updated in testing there are no release notes for that event. if you are wondering what is going on you look at the changelogs and/or read up on the package itself via whatever means you can. it's sometimes been the case that the only way i've found out about some changes is by doing full downloads of all the source code and doing line-by-line comparisons between versions - not everything that changes is always documented. >> with testing, stuff can happen, like sid, stuff can >> break. that is just how it goes and i'm quite ok with >> that because i also do keep a stable partition (which >> is currently not upgraded yet and won't be until a >> point release or two down the line). my stable is even >> more stable than the released stable. there's nobody >> to force me to upgrade or mysterious software controlled >> by someone else running to mess with my machine (as i do >> not run auto updates). > > That's very conservative, and most people don't have twin > installations as you and I do. You also have years of Debian > experience, and a degree in computing, I believe. Probably > a good candidate for running testing. i've always been willing to take the chance, with only a few significant headaches over the years because of a maintainer making a mistake with a package or me doing something boneheaded. it also helps that what i'm doing with my computer is not very extensive in terms of running some sort of production system. yes, my background is computer science and i spent a fair number of years running mainframes, minis, pcs, etc. i retired at a young age to avoid further years of sitting at deskjobs being essentially an electronic janitor and babysitter. right about when the internet was becoming popular was when i got away from some things so my viewpoint is skewed and some web technologies i pretty much skipped. like currently the cloud is not something i know too much about. ... >> i consider the release process as a whole which >> includes at some point making copies of symlinks to >> the package pool and renaming various pathways or >> copying things as the whole point of making a >> release and then building images and such which do >> include the codename and not using things such as >> "testing", "sid", "experimental" or "rc-buggy" or >> ... > > More nonsense. They don't add/include a codename. > What they do add upon release is the release number. > The codename is the primary collection that is being > built be Debian. The way in which it is built and > maintained depends on its current status, and that > status is reflected, not defined, by the symlinks > pointing to it. So, a few days ago, bookworm became > a Release, obtained the number 12, had the stable > symlink moved to point at it, and now has a policy > for its modification that differs from what it was > before. yes, it could be another way. i realize this. so i could be wrong in other statements. :) >> i don't really think my viewpoint is far from >> the reality of what does happen, but if anyone >> from the release team cares to pipe up i'd listen. > > They shouldn't need to. It's all been documented in > the Debian reference/policy manuals, should you care > to read them. i have at various times, since the terminology is not always consistent you can chase definitions down all sorts of rabbit holes. to me and in the end the release team's interpretation of those documents and their specific tools as written and used are more defining and useful than many policy documents (policy documents are at times out of date and not updated until there is consensus established through practice). my own experiences in doing support systems work was to read the code and see what it was doing and then going back and seeing if the comments or the rest of the framework built around that code were accurate. i'd find a lot of mistakes (which isn't something i ever wanted to run into during something critical). > Cheers, > David. songbird
