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 _______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
