[vlc-devel] Debian/Ubuntu VLC

[Moritz Muehlenhoff]

On Sun, Jul 18, 2010 at 09:15:20PM +0200, Reinhard Tartler wrote:

> I don't think it is a practical problem to point than more than one diff
> in the announcement and/or changelog. Do you?

For the Debian Security Team is pointer to an upload commit is usually
sufficient. Adding one would be much appreciated.
 
> >> >> > But even then, how do you plan to upgrade from 1.0.2 to 1.0.6?
> >> >> 
> >> >> I don't understand the question. Of course by preparing an upload and
> >> >> uploading it!
> >> > 
> >> > Waouw, since when has this changed?
> >> > 'we cannot update because this release change functionnalities' is what
> >> > we usually had...
> >> 
> >> This has not changed, but AFAIUI, there are only very focused and
> >> documented changes in bugfix branches. Maybe I'm wrong here? If yes,
> >> then a stable release update needs to cherry-pick the relevant changes.
> >
> > Generally, it mostly contains bug fixes. But as long as the source and binary 
> > interfaces remain compatible, and regression are perceived as very unlikely, 
> > new features can and do go in.
> 
> This then may qualify for an ubuntu stable release update[1], but probably
> not for a debian one. We could however try, I've seen that there has
> been formed a stable release manager team and opinions may have changed
> with that.
> 
> [1] https://wiki.ubuntu.com/StableReleaseUpdates

There are some exceptions for well-tested point updates. We do that for
Postgres, e.g.


> >> >> > Or from 1.1.x in final Maverick, to 1.1.x+{1,2,...} ? VideoLAN won't
> >> >> > provide one stable tree per release! We can't afford the kernel's
> >> >> > luxury time-wise.
> >> >> 
> >> >> I guess 1.0-bugfix and 1.1-bugfix branches do exist, yes?  What's the
> >> >> problem?
> >> > 
> >> > You don't understand him. He is speaking about 1.1.0-bugfix,
> >> > 1.1.1-bugfix, etc...
> >> 
> >> I think the misunderstanding is about the 1.0-bugfix and 1.1-bugfix
> >> branches. Can you perhaps explain me the update/commit policy in the
> >> 1.0-bufix branch? what patches qualify and what don't? Is there a wiki
> >> page or something I can read about?
> >
> > In 1.0-bugfix the current policy is that it is DEAD. It just happens that 
> > there have been no security advisories since 1.0.6, and so 1.0-bugfix happens 
> > to be up-to-date w.r.t. security matters.
> >
> > But for 1.1-bugfix, there will be select low-risk new features probably until 
> > shortly before 1.2.0 is out. And 1.2.0 will probably be out long after 
> > Maverick. So that does not work in the medium term.
> 
> I see. Well, my point still stands, a clearer identification of
> important issues (including but not strictly limited to security issues)
> would help packagers to identify patches that qualify for backporting.
> This backporting itself does not need to be done by upstream, I think,
> this means that I certainly don't expect you to actively maintain
> 1.x.y-bugfix branches, but I imagine that a little help with VSAs or a
> detailed ChangeLog or perhaps some wiki page to list and classify such
> patches would be probably little effort for you and help us immensly
> with preparing patches for released distro versions.

I've discussed this with Reinhard in person at the currently holding
Debian conference (DebConf); we'lÃl send an end of life announcement
for the ancient VLC version in Lenny.

Cheers,
        Moritz