Congelamiento Lenny
segun lo comunicado por debian-devel-announce@lists.debian.org estamos cerca de la llegada de Debian Lenny 5.0 Stable.
Proxima semana : Full freeze
Setiembre 2008 : Release Lenny !!!!!
aca el mail original :
Freeze status
~~~~~~~~~~~~~
Since the last update, the following steps in the timeline have been
taken:
Freeze of the non-essential toolchain
The “non-essential toolchain” means things like debhelper, cdbs
and a big chunk of other things usually needed to produce binary
packages.
Freeze of all library packages
This will affect all packages that produce library packages used
by other packaged software. Packages without r-deps won’t be
frozen at this point.
I’ll point out once again, that maintainers should look at the timeline
and realise that next week we *FREEZE*.
Architecture status
~~~~~~~~~~~~~~~~~~~
The architecture qualification pages on wiki.debian.org are still
missing a LOT of information.
Of the current 12 architectures, 8 are still at risk of being dropped
unless their issues can be solved. Check the [ARCH:QUAL] pages for more
information as to the current issues. In some cases, these arches are
not being considered because we may not have enough information in the
wiki pages to make an informed judgement.
Release goals
~~~~~~~~~~~~~
* Switch /bin/sh to dash
There are still quite a few bugs open about bashisms, but most of those
have a patch included. Please NMU. This goal doesn’t mean we’d switch to
dash as a global default, but if people do so on their system, there
shouldn’t be any issue after the last bugs have been finished off.
* piuparts-clean archive
Over 50 bugs remaining, many with little activity. Since these are
problems that affect all users and are usually fixed by little changes
to the maintainer scripts, more attention to this goal would be very
welcome.
* double compilation support
Most of the double compilation problems have been fixed since the last
release update and there are only about three dozen bugs left. Please
note that many of the packages still affected are in bad general shape,
so each NMUer should consider if the package in question shouldn’t be
removed instead.
* Prepare init.d-Scripts for dependency-based init systems
Wider testing of dependency-based init systems has lead to some new bugs
for this goal, but the current state looks quite well. We are confident
that we will have full support for dep-based init system in lenny.
BSP Marathon
~~~~~~~~~~~~
At time of writing, we have 360 open RC bugs affecting lenny, which is
360 too many. A coordinated effort is needed to reduce this number, so
we’ve decided to resurrect last year’s very successful BSP marathons. As
a reminder, we still have a 0-day NMU policy in effect.
Please note that in a BSP, you shouldn’t just NMU every RC bug you see.
While you are working on a package, check for other low-hanging fruits
(like translation updates, typos that can easily be fixed, ...) and fix
them in your NMU. On the other hand, if you notice that a package looks
unmaintained, refrain from fixing the bugs for now and try to find out
if the package should be removed or adopted by another maintainer
instead.
In case you want to organise a BSP, don’t hesitate to contact the
Release Team to coordinate efforts.
Release schedule
~~~~~~~~~~~~~~~~
If you’ve managed to miss my (ok, cowsay’s) wonderful artwork, please
see the following:
Next week
Full freeze
Please don’t wait with uploads for the last day before the freeze,
thanks.
September 2008
Release lenny!
Tricks from the Release Team
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Curious as to why your package isn’t getting into testing? Have a look
at the [MIG] Migration Tracker page. Although if it’s a library, or
you’re reading this mail after next week, it’s because we’ve frozen. Did I
mention that already?
--
http://release.debian.org
Debian Release Team
saludos
Yo solo se que no se Java.
- Inicie sesión o regístrese para enviar comentarios
- 715 lecturas


lenny congelado en septiembre !!!
Me parece mas apropiado lenny congelado en 2009 (fecha por determinar)
si se congela lenny... significa una desincronizacion entre los repositorios lenny y los repositorios testing?
"Si Dios hubiera querido que el hombre volara, le hubiera dado billetes de avión"
-Terry Pratchett, "El color de la Magia"
Si lenny se va a congelar y deseo seguir en la rama testing ¿debería cambiar mis los repositorios de "lenny" a "testing" para seguir estando en esta rama?
Geek by nature, Linux by choice, Debian of course.
Si lenny se va a congelar y deseo seguir en la rama testing ¿debería cambiar mis los repositorios de "lenny" a "testing" para seguir estando en esta rama?
por supuesto!!!!!!!
si los apuntas a lenny usaras la nueva estable y si los apuntas a testing siempre estarás en la rama testing...que dicho sea de paso no se como se llamara!!!!!
saludos
Yo solo se que no se Java.
Sí, pero... normalmente en un primer momento no es recomendable tener una testing, justo después de que se ha liberado la nueva estable; en ese momento prácticamente es como una sid; y además no contará con soporte de seguridad hasta precisamente pasado un tiempo.
Recomiendan que pase algún tiempo, tal vez un par de meses después de la liberación de la nueva versión, hasta volver a apuntar a testing.
Saludos.
A ver, hasta el momento de la liberación (no congelación), Lenny=Testing. Eso es inevitable. Justo en el momento de la liberación, Testing=Lenny=Stable y poco después, Lenny=Stable. Testing=???.
PD: Chacal, no es la primera vez que leo de la bitácora de un desarrollador que mientras Lenny está "estabilizandose", estos no quieren subir paquetes a sid para que no acaben en Lenny, manteniéndolos en experimental. Comienzo a pensar que sí hay cierta relación, y que extraoficialmente, Sid también "se congela" de alguna forma (por lo menos parcialmente). Además, ahora mismo Sid se diferencia bastante poco de Lenny. No hay más que hacer un mirror de Lenny y luego hacerlo de ambos. La diferencia de paquetes es bastante pequeña.
PD2: Con tu permiso G@ucho, se puede incluir esta noticia en las "noticias del proyecto Debian" que elaboramos en esdebian.
No es más rico el que más tiene sino el que menos necesita.
lenny congelado en septiembre !!!
Me parece mas apropiado lenny congelado en 2009 (fecha por determinar)
A ver, a ver, la congelación de paquetes será este mes y se espera que la publicación como distribución estable sea en septiembre
.
Sobre la falta de sincronización que pregunta ssorgatem, la experiencia anterior (cuando se trataba de Etch) me dice que no hay tal. El movimiento de paquetes se detiene casi por completo en testing, y durante ese tiempo, de uno a dos meses, es aún exactamente lo mismo tener testing o Lenny en el sources.list . Dicho de otra manera, nunca existe una distribución o rama intermedia entre testing y stable.
Es hasta pasada la publicación de la nueva estable, que testing comienza a recibir nuevos paquetes en cascada y recibe su nuevo nombre.
si se congela lenny... significa una desincronizacion entre los repositorios lenny y los repositorios testing?
En realidad pasa justo lo contrario, se sincronizan... primero tené en cuenta la diferencia entre congelar (no ingresan nuevos paquetes desde la rama sid a testing) y liberar (el software en testing es lo suficientemente estable y se decide la liberación, para eso nunca hay una fecha fija).
En la practica lo que pasa es que justo después de liberarse la versión testing, que estaba congelada, stable=testing, en ese momento se desbloquea testing y al rato nomás lo que estaba en sid listo para ir a testing hace el traspaso.. en ese momento testing se actualiza de golpe y es un momento bastante delicado, muy propenso a dar problemas... lo recomendable es quedarse un tiempo en stable y pasarse a testing después de unas semanas y con cuidado.
EDITO:
En realidad pasa justo lo contrario, se sincronizan...
Ahora ya me cito solo... interprete mal y encima dije cualquier cosa, se sincronizan lenny, stable y testing pero eso pasa en la liberación, no cuando se congela. Cuando se congela no pasa nada, solo que testing deja de recibir nuevas versiones por lo que las actualizaciones disminuyen un poco.
Creer que algo es imposible es el primer paso para que lo sea.
Geek by nature, Linux by choice, Debian of course.
PD2: Con tu permiso G@ucho, se puede incluir esta noticia en las "noticias del proyecto Debian" que elaboramos en esdebian.
por dios hombre !!!! la noticia no es mia !!! es de la comunidad, lo único que hice fue promoverla.
Dispone de ella como mejor creas.
saludos
Yo solo se que no se Java.
Geek by nature, Linux by choice, Debian of course.
27 julio 2008: con una e-mail enviada a la lista debian-devel-announce@lists.debian.org, Marc ‘HE’ Brockschmidt anuncia el estado de congelamiento de Debian Lenny 5.0, con un dia de anticipo respecto a lo estipulado.A continuacio el texto del mensaje:
Hi,We just edited our hint files, so that all packages now need human
review in order to go to testing. Hmm, that sounds too cryptic. Let’s
try again:
Lenny is now frozen! Wheeeeeee!!!
Thanks are due to everyone who has helped get us to this point.
For those maintainers whose packages were unprepared for a freeze at
this moment (the process has, after all, been a long one), you still
have one last opportunity to get things into shape if there are any
remaining important problems. Read on.
Now to explain what, exactly, we mean by “freeze”. The freeze
upload policy of uploading changes in through unstable if possible will
be continued to apply until the release.
All package versions that are at this moment already in unstable get
an automatic freeze exception (except those that are frozen for
reasons, of course). This means that packages you’ve uploaded in the
past week will be able to go to testing (if they aren’t hit by
other problems).
Now, so as not to have everyone contact us at once about packages we
know we won’t approve, here are the guidelines for changes that will be
accepted into testing during the freeze:
- fixes for release critical bugs (i.e., bugs of severity critical,
grave, and serious) in all packages;
- changes for release goals, if they are not invasive;
- fixes for severity: important bugs in packages of priority: optional
or extra, only when this can be done via unstable;
- translation updates and
- documentation fixes.
- pre-approved fixes.
If you have such a change and want to update your package in Lenny, the
rules are as follows:
- In all cases, when preparing an upload, please do not make changes to
the package that are not related to fixing the bugs in question.
Doing so makes it more time consuming for the release team to review
and approve such requests, delaying the release. It also delays the
fix for your package, because you will be asked to reupload. Always
document every change verbosely in the changelog.
- If in doubt, first contact debian-release.
- When contacting the release team, please explain why you are
requesting an update. Bug numbers are a must. Attach the proposed
(or uploaded patch. The more we can figure out from your first email
and your changelog (if any), the more quickly we can get your update
in.
- If your package needs to be updated for Lenny, and the version in
unstable doesn’t contain extraneous changes (e.g, the version is the
same between testing and unstable), please upload your fix to
unstable and contact debian-release@lists.debian.org.
- If the version in unstable already includes significant changes not
related to the bug to be fixed, contact debian-release about
uploading to testing-proposed-updates. Changed dependencies, new
upstream versions, changed library names, and completely rewriting
the packaging are “significant changes”. So are lots of other
things.
- If the version in unstable won’t reach testing because of new
library dependencies, contact debian-release about uploading to
testing-proposed-updates.
- If you have a package that needs a freeze exception, *please* don’t
forget to contact us. *Don’t expect us to find out about it on our
own*. Putting a comment in the changelog is not contacting the
release team. :)
- If your package has been removed recently (i.e. in the last 20 days)
due to an RC bug, and you have an bugfix-only update uploaded,
you can contact the release team about letting your package back in.
Same as above: Do not expect us to find it out ourself. You need to
push that.
As always, it is the release team’s goal to get as much good software
into Lenny as possible. However, a freeze does not mean that your
package is ensured a spot in the release. Please continue to stay on
top of release-critical bugs in packages that you maintain; RC bugs in
optional or extra packages that remain unfixed after a week will still
be grounds for removal from testing, just as they have been up to this
point.
Please also note that since many updates (hopefully, the vast majority)
will still be going in through unstable, major changes in unstable right
now can disrupt efforts to get RC bugs fixed. We don’t ask you not to
make changes in unstable, but we do ask that you be aware of the effects
your changes can have -- especially if you maintain a library. Please
continue to keep disruptive changes out of unstable, and continue making
use of experimental where appropriate. Note once again that you can
stage NEW uploads in experimental to avoid disruption in unstable.
Also, in case you need release team’s help to fix RC bugs (e.g. to remove
an old package), please feel free to contact us.
For packages which missed the freeze only for reasons outside of the
control of the maintainers, we might be generous, but you need to contact
us on your own, and you need to contact us soon.
What needs to happen before release
===================================
There is a short list of things that need to happen, though.
Fixing of release critical bugs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For the release, we need to get rid of all release critical bugs. Please
don’t hesitate, pick any bug from
http://bts.turmzimmer.net/details.php?bydist=lenny and fix it. Or send in a
patch in case there is none yet. And of course, follow our permanent BSP
policy for your NMUs. Uploading works as you are used to -- just remember to
send an e-mail to debian-release@lists.debian.org to get your fix through.
Security support
~~~~~~~~~~~~~~~~
Final preparations for security support will be done during the general
freeze, that is now. We hope being able to announce start of security
support soon, but obviously, it is a pre-condition for release.
Cheers,
Marc
Yo solo se que no se Java.