Vincent Ladeuil v.ladeuil+lp at free.fr
Mon Dec 14 09:45:36 GMT 2009

>>>>> "martin" == Martin Pool <mbp at canonical.com> writes:

    martin> that, at least looking at the description, really are
    martin> genuine bug fixes (as opposed to performance or
    martin> testing) and that could qualify for 2.0.  I wonder
    martin> why they weren't proposed for it?  Like the
    martin> following:

Generally speaking if a bug fix is *not* explicitly targeted at
2.0 we shouldn't backport it.

The same rule can apply to bugs landed on trunk where the one
fixing it said it may be worth backporting but nobody came asking
for it to be backported.

In short, backporting to the stable branch requires work and
careful testing.

Careful testing requires exposure and we don't have the
infrastructure for that...

I realize that makes it hard to backport any bug since by
definition there will be no packages nor installers built with a
fix to be tested before the actual release. It follows that
introducing regressions at that point is possible and will defeat
the purpose of the stable branch.

In the end, it means we can rely only on expertise to decide
whether or not a bug can be backported.

That being said, here are my comments:


    martin> * ``osutils.terminal_width()`` obeys the BZR_COLUMNS
    martin> environment variable but returns None if the terminal
    martin> is not a tty (when output is redirected for
    martin> example). Also fixes its usage under OSes that
    martin> doesn't provide termios.TIOCGWINSZ. Make sure the
    martin> corresponding tests runs on windows too.

    martin>   (Joke de Buhr, Vincent Ladeuil, #353370, #62539)
    martin>   (John Arbash Meinel, Vincent Ladeuil, #492561)

This one is potentially highly controversial, hard to test (more
precisely, the behavior change needs to be observed in a lot of
various configurations, some of which I have no idea) and as such
deserve exposure through the beta/rc releases.


    martin> I think there is some risk developers and active
    martin> users will be on trunk or betas and therefore not
    martin> motivated to merge to 2.0.x.  We should probably ask
    martin> for bug fixes into 2.0.  I don't feel strongly
    martin> inclined to go back and cherrypick things without
    martin> being requested to.


Unless vocally requested, I don't think fixes should be

In the end, I think it means that the only fixes that should land
on the stable branches should be identified from the start and
land there or be critical enough to be backported. I don't think
we have (yet) encountered such bugs for the 2.0 release series.

We have other means than the stable branches to distribute new
releases (ppas, etc) and that can be used when people are
interested in new features or bug fixes.

I think our actual scheme (stable, betas, ppas, trunk) addresses
various populations, people that don't want to take any risk at
all should be able to use the stable release.


More information about the bazaar mailing list