[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: etch or later?

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.

Here are other examples:
 * 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

I just realized that what I backported from sid (4.0) is already quite
 * 0.4.0 released August 2005 (migrated to testing in september)
 * 0.5.2 released 13 Mar 2006 (in ubuntu)
 * 0.5.3 released 16 May 2006 (in mandriva)

One thing is: I trust the Evince guys to make a release when the
application are stable, and I dislike introducing additional delays to
duplicate that stabilisation job again at our level. I understand that
packaging-specific bugs may be introduced and needs namely depencies
automated checks, but as far as the code is concerned, I'd trust
upstream directly. At least for a decent portions of existing

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 :)

> > Incidentally, do you think it would be good to document this bpo
> > 'policy' on the official page?
> As I wrote to the list previously, I don't have the permissions required
> to update the page myself. Therefore, and also because those backporting
> practises are 'common knowledge' to those who make backports and were
> not yet written down previously, I collected them at
> wiki.debian.org/Backports.

Hmmm, I think it would be good to add a rationale along with the
policies. It's written that it's good to stick to testing but this may
be better with justification.


Reply to: