Re: Bug#31581: project: Time between releases is too long
Cesar.Barros@web4u.com.br wrote:
> I've seen recently at slashdot complaints about the slow release cycle
>that Debian has.
Keep in mind that you'll never please 100% of the slashdot readerbase on any
issue whatsoever. Debian does not exist to please slashdot.
> However, the freezing process takes too long.
This I fully agree with.
>For example, since autoconf 2.13 has been recently released, it will take
>another full year until it gets on frozen, and then another year and a half
>until it gets on stable - and the whole process is delayed because of some
>easily broken packages - like xfree86 (that seems to break once every two
>releases).
This is somewhere between an exaggeration and a lie.
6 months is more like it. 9 months is about the maximum (and only if a
package is uploaded to unstable right after a fresh unstable is created,
or if the maintainer is lazy, in which case you should file bugs on an
individual package basis). frozen does not take a year to be released. It
never has and it never will. We don't take a year and a half to pump out
releases either. There was a pretty embarrasing delay between bo and hamm
but I think that won't happen again for a while.
BTW, there's already a bug against autoconf about 2.13 being out. It was
filed by Jim Pick last night.
When it is packaged (I'm not the maintainer of autoconf so I can't say what
the delay will be), it'll be available in unstable. You will be able to
install that package on your hamm or slink system.
>This make packages with unimportant but neat bugfixes and new
>features be released slowly - thus making Debian lose its technical
>superiority when compared with some other distributions that release buggy
>packages but release often.
I agree to an extent. However I think releasing month-old or two-month-old
software is fine, and one month can be done with a normal "freeze" - we have
to actively prepare for such a freeze though. We need working documentation,
working bootdisks, and most of all, we have to completely avoid the
last-minute-upload problem. This can be done by freezing at an unannounced
date.
[another "let's move to a package pool" proposal snipped - you should know
I'm personally against such a thing.]
> A user then faces a dillema: use the stable but outdated software or
>the more recent (and generally better) software mixed with totally broken
>packages? Some might consider using a mixed setup, but not only this is hard
>but has some sutble problems since the unstable packages are misdesigned to
>the 'unstable' dist, and even harder if you like dselect.
This choice exists currently. For example, a user like you who is complaining
about the up-to-dateness of debian software should run unstable.
> We need to move from the present setup (too CD-based) to one based in
>multiple dists, using fully the potential power of the Internet.
You never have used apt, have you?
Debian uses the Internet to get software to the users more than any other
distribution.
However, the CD's must go out the door. People need them.
> And with a faster development cycle (release early, release often), we
>can have even less bug and more cool features due to Linus's Law (read The
>Cathedral and the Bazaar).
Linus doesn't manage the kernel with a "source code pool" either. :P
You'll find "released early, released often" software in unstable, where it
belongs.
> I know nobody is perfect, and I may have missed something. This is
>intendend to cause comment, discussion (and the ocasional flame war) and help
>to improve Debian (and beacause it's cool to install a new version of your
>favorite software knowing it will work ;-) ).
You completely missed all the previous discussions regarding the package
pool idea. :)
--
Robert Woodcock - rcw@debian.org
"Unix and C are the ultimate computer viruses" -- Richard Gabriel
Reply to: