Re: Debian home page -> Download link broken:
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
Reply to: