Re: updated debian development diagram -- comments?
On Sun, 09 Jan 2005 15:42:36 -0600, Ron Johnson <ron.l.johnson@cox.net> wrote:
> On Sun, 2005-01-09 at 16:20 -0500, Tom Allison wrote:
> > Ron Johnson wrote:
> > > On Sun, 2005-01-09 at 15:04 +0100, Olaf Conradi wrote:
> > >>Most of the development work that is done in Debian, is uploaded to
> > >>this distribution. This distribution will never get released; instead,
> > >>packages from it will propagate into testing and then into a real
> > >>release. Security updates for "unstable" distribution are not managed
> > >>by the security team.
> > >
> > > That is misleading. Yes, the Security Team doesn't manage Sid,
> > > but the maintainers themselves either patch or push thru new versions
> > > from upstream.
> >
> > There's nothing misleading about it.
>
> mislead != wrong
>
> The statement "Security Team doesn't manage Sid" is true, but
> someone who doesn't know Debian wouldn't know that Sid packages
> get fixed, too.
Well, just add a line describing it's the package maintainers decision
on the timeliness of updates in unstable. The point was that security
updates in unstable aren't done at high priority.
> > It merely states the the Security Team doesn't manage the security
> > updates for -unstable. If there are major security holes in the Sid,
> > there isn't anything which would require a short track security update.
> > If I were a developer managing a package which was found to have a
> > security problem in all version, it stands to reason that Sid would be
> > the lowest priority of the three.
> >
> > And as such there's no hard requirements that I do anything on a
> > security fix basis to Sid. For example, given a choice between a
> > current version patch or a new version that's fixed, you would expect
> > Stable and Testing to have the patches and Sid to have whatever I feel
> > like putting into it.
>
> That's wrong.
>
> Packages filter into testing after being in Sid for some time.
> Thus, Sid's versions will always get the patches first.
That's not always true. If testing is already frozen and unstable
contains newer development versions, then RC and security related bugs
can go to testing-proposed-updates and bypass unstable.
Or if unstable contains a higher version, one can upload the new
testing version to unstable with a high priority. People tracking
unstable will never see the update, because it has a lower upstream
version.
So updates to testing can happen before updates to unstable.
> > Probably the new version, but that might take a
> > considerable amount of time to develope.
>
> Bull. I'm always seeing new "dash-versions" in Sid.
>
> Here are some examples from this command that I just ran:
> # apt-get update && apt-show-versions -u | sort
[snip - long list of unstable updates]
> Guess I'd better do an "apt-get upgrade" now...
Those aren't all security related fixes, most of them fix a packaging
mistake or a RC bug. A RC bug doesn't necessarily mean security fix.
It's just a show-stopper for a release, whatever the reason.
Some of the packages you listed have a higher upstream version in
unstable, so that fix for testing might or might not be in unstable
(usually it is, but not per definition).
-Olaf
Reply to: