Re: etch or later?
On Fri, 2006-06-16 at 20:19, Micha Lenk wrote:
> Hi,
>
> Sylvain Beucler schrieb:
> > On Fri, Jun 16, 2006 at 01:28:47PM +0200, Daniel Baumann wrote:
> >> Sylvain Beucler wrote:
> >>> When I needed to install OOo2.0.2 [...]
> >> Again, ooo is a special case in any situation. Don't use exceptions to
> >> consolidate your argumentation.
> >
> > Again, we're the only distro that can't provide 2.0.2. I also wonder
> > what makes it an exception.
>
> There is a reason why OpenOffice 2.0.2 isn't in testing yet: Have a look
> at http://bjorn.haxx.se/debian/testing.pl?package=openoffice.org for a
> quick impression what prevents it from entering Etch. If you want
> OpenOffice 2.0.2 to enter Etch faster dig into the details and help
> fixing the bugs.
>
So, what prevents recompiling this package with a newer version of gcj?
And from my point of view, dependencies on libraries should be version
specific, at least in the major number. The minor number is a fix
without an API change. If not, then it is a major bug.
Showing only the first platform of all supported platforms which
prevents the next step could be improved to count and show all
platforms.
And what prevents some platforms from being faster than others?
As far as I understand, the build dependencies are paltform specific.
Or, another idea, if it suffers on x% of platforms, then go forward.
Thus, tha majority counts and not the minority. I think debian is
democratic and there, votes depend in general on majorities, the EU may
be an exception, which does not count.
> > Here are other examples:
> > git-core:
> > * 1.3.3 released 16 May 2006
> > * accepted in unstable 25 May 2006
> > * migrated to testing 6 June 2006
> > * uploaded to backports 7 June 2006
> > * but 1.3.4 released 10 June 2006
> > so we're about ~1 release / 1 month late
>
> So what?
> Do we prefer a bleeding edge system having every software at the latest
> blinky release or a sound, well tested and stable system? AFAIK Debian
> aims for the latter. And I appreciate it for this attitude.
> Nevertheless I think it's very nice to have backports.org providing
> newer packages as the current stable release gets older. Some years ago
> we didn't even have backports.org... :-)
>
When backports come alive officially, I hoped, the goal was to organize
the "wild backports".
And to have the major gap to much more recent SW versions closed.
Having a stable release which makes mostly only full time sys admins
happy, the server does not crash and they don't care much about end user
whishes as long as "their" system does not crash.
I speak here from real life in my job. There trhe admins also make
stone old "stable" SW releases available for end users which makes me
crazy. I know there is an improved (bug fixes, new features) version
which would help a lot to save time of making work arounds to achieve
the goal.
OK, these new versions may have other bugs, but that's life.
And finally, look at the latest Debian Weekly News where Joey Hess
reports about Debian being a "supermarket".
I think this goes exactly in the same direction. Debian Stable makes
sys admins happy but no one else.
If Debian wants to get accepted by end users using single/two user
computers, scientists, ..., then Debian has to deliver SW much more neer
to the bleeding edge. This SW may have the one or other bug, but much
more bugs are closed and the usage, usability and usefulnes is also
improved.
There are lots of users who are faced with the sys admin when looking
into a mirror. They want to have a more recent SW version as far as I
understand.
Bugs introduced by faulty packaging are something else. That's not SW
fault by upstream and can easily fixed by rebuild by the
maintainer(group). Then followed by a simple update. Bingo.
> > I don't blame backports or Debian or anybody in particular. I just
> > witness that however you try, there's no up-to-date .debs for Sarge
> > while other distros do -- so exceptions or not, there is a problem to
> > solve. Generalizing backports.org is one way, and I would welcome
> > other suggestions to get rid of delays :)
>
> I fear you can't get rid of delays without loosing the current level of
> quality too. Quality work simply needs time.
>
> If Debian adopts new software releases to slow, well, nobody forces you
> to stick with the officially supported packages nor with packages from
> Backports.org. You can simply look for unofficial APT repositories or
> even build your own and register it at apt-get.org and announcing it for
> the public. You wouldn't be the first. :-)
>
See my long reply above. In brief:
I hoped this would be improved when backports come alive in organizing
"wild and incompatible" backports.
Finaly,
it is really interesting to see that these kinds of improvement/change
requests pops up once per year 8-))).
And are also rejected once per year 8-(((.
Kind Regards,
Thomas
Reply to: