Re: etch's upgrades during life cycle
Qui, 2007-01-04 às 16:43 -0500, Matthias Julius escreveu:
> Luis Matos <firstname.lastname@example.org> writes:
> > Qui, 2007-01-04 às 11:10 +0000, Dominic Hargreaves escreveu:
> >> backports.org is, to my mind, a perfect solution to this problem; it
> >> allows you to selectively upgrade your favourite/important packages that
> >> you need, whilst retaining the stable base on which to run them.
> > here i agree that backports.org is the way out and that should be
> > official so maintainers could upload backports in a easier and have a
> > better security support. (and gives users other view for it if
> > backports.org is indeed in debian and recommended by debian.)
> Maybe backports.org is too much and changing to frequently to provide
> security support for and to be really stable.
backports use testing as base for the packages.
setting up security for backports is a bit easier than for testing. Lot
My point is, for example, when the security team lauches a DSA, it
always sees if both unstable and testing are afected. They already
monitor testing and unstable too ... it's just a question of applying
patches. (maybe a apt-patch package. in which he rebuilds the package
with the selected patch).
The same would do for backports, security team would patch the package
and send it to the buildd.
I know ... it's more and more work for the security team ...
> There could be another archive called updates.debian.org where
> selected packages go in in coordination with the security and stable
> release teams.
that would be nicier ... but that's a bit of volatile's purpose.
Although it is not very used.
at a certain point several packages could be updated, because mainstream
releases an important release. Like mysql-5.0, or ooo 2.0 ... and they
could be addressed to backports or volatile or updates (volatile, for
me, means critical updates for debian stable ... because stable must
remain ... stable).
We definitly need something to make debian stable move while it is
Someone talked about the release cycles ... i think debian should not
move to less than one year ... we already have ubuntu and see what is
going there with the 6 months. The main problem for the year release is
desktop, because linux has suffered lots of evolution in this field in
so little time. Companies that deploy linux on desktop seem to seek for
updating contantly the desktop (or others let them to rott).
I think what debian needs is a lift in the desktop part, and the desktop
team is moving. (the desktop team needs designers or people in the
I always compared debian stable with RHEL. They both target the same, i