Re: Desktop user: Etch or the next testing?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Apr 03, 2007 at 06:51:02AM +0000, Joe Hart wrote:
> Greg Folkert wrote:
> > On Tue, 2007-04-03 at 00:45 +0200, Sven Arvidsson wrote:
> >> There have been a lot of talk and suggestions, for example, Joey Hess
> >> described Constantly Usable Testing, it sounds a bit like your
> >> suggestion.
> >> http://kitenet.net/~joey/code/debian/cut.html
> >>
> >> Also, there seems to be some interest of making official backports to
> >> support new hardware and new releases for typical desktop users. I would
> >> be surprised if this didn't happen for the Lenny release, or even
> >> sooner.
> >
> > CUT was exactly what testing was supposed to be, in the beginning.
> > Period. It hasn't become that. It has gotten to the point that sometimes
> > testing is borkdened for long periods of time... in small areas mind
> > you, but still broken.
> >
> > I think it would be good to have the Sidux group latch onto this. They
> > could really improve the whole process. It would make Testing usable at
> > any one moment. And make something you could always point to and say:
> >
> > try that
> >
> > And then watch problems melt. It would be a good thing, as it would make
> > Debian able to release a new version at nearly any time. In other words,
> > 1 month between releases, 2 months, 4 months, 6 months, 2 years...
> > whatever they want.
>
> I agree that something needs to be done so that Sid doesn't have to
> freeze when Testing freezes. Right now there are loads of packages
> waiting in experimental for Etch to release so they can enter Sid. It's
> kind of hard claiming to be running a bleeding edge distro when some of
> your apps are 2 releases behind upstream.
>
> I can understand the reasoning behind the current situation, but that
> doesn't mean I have to agree with it.
>
The developers are focusing on fixing the bugs in testing, if Sid
wasn't frozen the developers would have to split resources to fix bugs
in Sid and testing at the same time. That would mean that stable
releases would take MUCH longer.
In my opinion it's nice to have some downtime from bugs every once in
a while. Gives us time to discuss OT stuff on the list, although it
does piss off a lot of people. What else are we supposed to do in the
downtime? :)
> Also, the snippet about Debian on this weeks distrowatch weekly
>
> http://distrowatch.com/weekly.php?issue=20070402
>
> mentions that we run a very old glibc to keep compatibilty with so many
> architectures. I understand that, but doesn't that make us less
> appealing to the x86 crowd, and offer potential problems with newer
> software based on newer libraries?
>
Depends who you're aiming to appeal. I run a x86 machine, and I really
see no problem with an old glibc. I'd rather have Debian stay the
stable distro it is than worry about having everything "up to date".
It's not the computer you're aiming to please, it's the end user. And
it's up to the end user to decide what he/she wants out of a
distribution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGEnHK/o7Q/FCvPe0RAiUPAKCwwH742PNSGGGTwxI83yKfF+YyMgCgjBNu
PpNtAepeyWfCKwpyKxQ1vIU=
=97h+
-----END PGP SIGNATURE-----
Reply to: