Re: etch or later?
Micha Lenk wrote:
> 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.
Paul Cupis wrote:
> >>> Again, we're the only distro that can't provide 2.0.2. I also wonder
> >>> what makes it an exception.
> >> Incorrect:
> >>
> >> # apt-cache policy openoffice.org
> >> 2.0.2-3 999
> >> 500 http://tclgs001 unstable/main Packages
> >
> > In this thread we're talking about Sarge and packages (re)built
> > for Sarge :)
> >
> > As pointed out we won't use sid as a end-user product because
> > packages can get broken deps.
>
> But as a distro, Debian is providing 2.0.2, just not in a stable
> release. Sarge will never have OOo 2.0.2, though backports will probably
> have it once it passes into 'testing'.
>
> There is nothing stopping you or anyone else backporting it to sarge and
> making it available, but bpo will not do it until it passes to 'testing'.
It may be in sid, but not acceptable in backports. There's no
structure at the moment to foster, host and/or build such a
recompilation.
It will be acceptable when it will hit testing, but it's been around 2
months already. And why is it held in sid? As Micha pointed out,
because of dependencies checks, which I don't care about for backports
because I'll change those very dependencies to meet Sarge's.
All of this introduces lots of delays that I feel we need to get rid
of to produce a more reactive distro.
> >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.
(s/1.3.4/1.4.0/ btw, sorry for the confusion)
The _main git branch_ is the bleeding edge. 1.4.0 is the latest
_release_ and went through 2 release candidates. When upstream does
its job and makes stable releases, I fail to see why we should
duplicate that work and introduce more delays, in addition to the
unavoidable packaging one.
> 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... :-)
>
> >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.
On the contrary, I argue that when upstream makes a bug-fix release
such as OOo2.0.2 or git-1.3.3 or anything else, not switching to it
asap lowers the quality of the packages set.
> 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. :-)
I got that, but it is not that easy to get the bandwidth and the
auto-builders for various architectures. Bpo already lacks the
auto-builders because it's separate from Debian itself - and that's a
shame, I currently cannot find a way to install OOo, be it v2.0.1, on
Debian Sarge PPC :/ (besides borrowing the mac for the day or spending
the week cross-compiling using qemu...)
It would be a waste if each packager would have to recreate all the
physical architecture needed to distribute Debian packages. And those
who do, tend not to give back changes to Debian...
I wish we find a way share all our tools as easily as possible. If
among all of us backporters, some don't share my views on placebo
security delays, then I wish we can at least introduce a new more
permissive backport section.
--
Sylvain
Reply to: