[vlc-devel] Debian/Ubuntu VLC

[Reinhard Tartler]

On Sun, Jul 18, 2010 at 20:37:59 (CEST), Rémi Denis-Courmont wrote:

> Le dimanche 18 juillet 2010 21:02:50 Reinhard Tartler, vous avez écrit :
>> On Sun, Jul 18, 2010 at 19:41:46 (CEST), Jean-Baptiste Kempf wrote:
>> > On Sun, Jul 18, 2010 at 06:14:26PM +0200, Reinhard Tartler wrote :
>> >> I think the biggest problem we face here is communication. It is totally
>> >> unreasonable to expect everyone to read and follow vlc. Can you please
>> >> either be more explicit with your VSAs or perhaps create a more
>> >> specialized mailing list for such issues?
>> > 
>> > http://www.videolan.org/security/ is not enough for you?
>> 
>> It's not, and I've elaborated why in the paragraph you've killed in
>> your reply.
>
> Sure. But as nice as it would be, we simply can't put CVE identifiers in 
> commit logs, as they are allocated afterwards. We can and often do point at 
> commits in the advisory. In the last occurence though, this was not possible 
> since they were not self-contained individual commits.

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

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

>> Nothing really surprising, IMHO.
>
> It's not surprising. What's surprising is that you seem to expect the VideoLAN 
> project to do that.  Different distros have different policies w.r.t. what can 
> go in and when. With no fewer than 20 VLC releases published since Lenny, 
> there is no way in hell that the VideoLAN project could maintain security 
> patches/branches for every releases. And I don't think any other open-source 
> project does that either.

I see, it seems that I was wrong here.

> I could understand a statement that you don't buy in the computer security 
> theater, and so don't need security updates. But that would be another 
> discussion, and that does not seem to be the case.

Let me make the statement that I'm interested in improving the situation
for the vlc package in stable distro releases.

>> >> > 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.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4