Hi all, It's quite some time before the last release. There are some critical security fixes in SVN now. I guess it should be time for a new release. Also, if possible, can someone back port changes in the VideoLAN's fork to the official one? Thanks. Timothy
Dear Timothy, Am Sonntag, den 27.10.2013, 18:06 -0700 schrieb Timothy Gu:
It's quite some time before the last release. There are some critical security fixes in SVN now. I guess it should be time for a new release.
before sending a message next time, please take the time to at least look through the list archives of the last two months. Then you would have found the thread [1] [DVDnav-discuss] new release, call for patches and you would have known that a release is indeed.
Also, if possible, can someone back port changes in the VideoLAN's fork to the official one?
Not until somebody sends the patches to the list for review. It would be great if you could do it. `git format-patch` and `git send-email` should help with this. Thanks, Paul [1] http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/2013-October/thread.html#...
On 10/29/13, Paul Menzel <paulepanter@users.sourceforge.net> wrote:
Dear Timothy,
Am Sonntag, den 27.10.2013, 18:06 -0700 schrieb Timothy Gu:
It's quite some time before the last release. There are some critical security fixes in SVN now. I guess it should be time for a new release.
before sending a message next time, please take the time to at least look through the list archives of the last two months. Then you would have found the thread [1]
[DVDnav-discuss] new release, call for patches
and you would have known that a release is indeed.
Also, if possible, can someone back port changes in the VideoLAN's fork to the official one?
Not until somebody sends the patches to the list for review. It would be great if you could do it. `git format-patch` and `git send-email` should help with this.
The main repo is subversion, isn't it, though? -roger-
On Thu, Oct 31, 2013 at 12:48 PM, Roger Pack <rogerdpack2@gmail.com> wrote:
On 10/29/13, Paul Menzel <paulepanter@users.sourceforge.net> wrote:
Dear Timothy,
Am Sonntag, den 27.10.2013, 18:06 -0700 schrieb Timothy Gu:
It's quite some time before the last release. There are some critical security fixes in SVN now. I guess it should be time for a new release.
before sending a message next time, please take the time to at least look through the list archives of the last two months. Then you would have found the thread [1]
[DVDnav-discuss] new release, call for patches
and you would have known that a release is indeed.
Also, if possible, can someone back port changes in the VideoLAN's fork to the official one?
Not until somebody sends the patches to the list for review. It would be great if you could do it. `git format-patch` and `git send-email` should help with this.
The main repo is subversion, isn't it, though?
It is. But our development trees will gladly accept patches from git sent by email. Is anyone using straight subversion for their day-to-day development? I have been using git-svn for some time now. E -- Erik Hovland erik@hovland.org http://hovland.org/
On 10/31/13, Erik Hovland <erik@hovland.org> wrote:
On Thu, Oct 31, 2013 at 12:48 PM, Roger Pack <rogerdpack2@gmail.com> wrote:
On 10/29/13, Paul Menzel <paulepanter@users.sourceforge.net> wrote:
Dear Timothy,
Am Sonntag, den 27.10.2013, 18:06 -0700 schrieb Timothy Gu:
It's quite some time before the last release. There are some critical security fixes in SVN now. I guess it should be time for a new release.
before sending a message next time, please take the time to at least look through the list archives of the last two months. Then you would have found the thread [1]
[DVDnav-discuss] new release, call for patches
and you would have known that a release is indeed.
Also, if possible, can someone back port changes in the VideoLAN's fork to the official one?
Not until somebody sends the patches to the list for review. It would be great if you could do it. `git format-patch` and `git send-email` should help with this.
The main repo is subversion, isn't it, though?
It is. But our development trees will gladly accept patches from git sent by email. Is anyone using straight subversion for their day-to-day development? I have been using git-svn for some time now.
(of course, as previously stated, my personal preference would be to have the main repo in git/github as well, as stated before...)
On Nov 4, 2013 11:20 AM, "Roger Pack" <rogerdpack2@gmail.com> wrote:
On 10/31/13, Erik Hovland <erik@hovland.org> wrote:
On Thu, Oct 31, 2013 at 12:48 PM, Roger Pack <rogerdpack2@gmail.com>
wrote:
On 10/29/13, Paul Menzel <paulepanter@users.sourceforge.net> wrote:
Dear Timothy,
Am Sonntag, den 27.10.2013, 18:06 -0700 schrieb Timothy Gu:
It's quite some time before the last release. There are some critical security fixes in SVN now. I guess it should be time for a new release.
before sending a message next time, please take the time to at least look through the list archives of the last two months. Then you would have found the thread [1]
[DVDnav-discuss] new release, call for patches
and you would have known that a release is indeed.
Also, if possible, can someone back port changes in the VideoLAN's fork to the official one?
Not until somebody sends the patches to the list for review. It would be great if you could do it. `git format-patch` and `git send-email` should help with this.
The main repo is subversion, isn't it, though?
It is. But our development trees will gladly accept patches from git sent by email. Is anyone using straight subversion for their day-to-day development? I have been using git-svn for some time now.
(of course, as previously stated, my personal preference would be to have the main repo in git/github as well, as stated before...)
Yes, preferably have the repo in GitHub. GitHub now is the de facto standard for FOSS development (like several years earlier SourceForge was), and Git is a really nice VCS that is a generation ahead of SVN. GitHub pull request is a really convenient way to send patches. With that in mind, it would also be easier for other projects to integrate libdvdread/nav to their own application through submodules and things like that, and also easier for us to merge VLC changes if we will. Timothy
On 04 Nov, Timothy Gu wrote :
would also be easier for other projects to integrate libdvdread/nav to their own application through submodules and things like that, and also easier for us to merge VLC changes if we will.
The thing is that our forks will be mandatory to build VLC in the very near future. So, if distributions want to package VLC, they will have to use that ones... -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
On Tuesday, 05 November 2013 at 11:00, Jean-Baptiste Kempf wrote:
On 04 Nov, Timothy Gu wrote :
would also be easier for other projects to integrate libdvdread/nav to their own application through submodules and things like that, and also easier for us to merge VLC changes if we will.
The thing is that our forks will be mandatory to build VLC in the very near future. So, if distributions want to package VLC, they will have to use that ones...
Are you planning to make incompatible changes? Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
On 05 Nov, Dominik 'Rathann' Mierzejewski wrote :
On Tuesday, 05 November 2013 at 11:00, Jean-Baptiste Kempf wrote:
On 04 Nov, Timothy Gu wrote :
would also be easier for other projects to integrate libdvdread/nav to their own application through submodules and things like that, and also easier for us to merge VLC changes if we will.
The thing is that our forks will be mandatory to build VLC in the very near future. So, if distributions want to package VLC, they will have to use that ones...
Are you planning to make incompatible changes?
I might. So far, no plans. -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
On Nov 5, 2013 4:41 AM, "Jean-Baptiste Kempf" <jb@videolan.org> wrote:
On 05 Nov, Dominik 'Rathann' Mierzejewski wrote :
On Tuesday, 05 November 2013 at 11:00, Jean-Baptiste Kempf wrote:
On 04 Nov, Timothy Gu wrote :
would also be easier for other projects to integrate libdvdread/nav
to
their own application through submodules and things like that, and also easier for us to merge VLC changes if we will.
The thing is that our forks will be mandatory to build VLC in the very near future. So, if distributions want to package VLC, they will have to use that ones...
Are you planning to make incompatible changes?
I might. So far, no plans.
So it's ff/lav all over again? What about MPlayer? Do distros wanting to packages both MPlayer can VLC have to choose one fork or the other? Of course you would say that somebody will send a patch to MPlayer to use VLC fork, but what about all the other programs using dvdread/nav out there? The only way out of this would be adding API/ABI compatibility, but as I see there is an 80% chance that there are not enough people to maintain that. Thus the ultimate solution would be the abandonment of this project in favor of yours. Timothy
On 05 Nov, Timothy Gu wrote :
On Nov 5, 2013 4:41 AM, "Jean-Baptiste Kempf" <jb@videolan.org> wrote:
On 05 Nov, Dominik 'Rathann' Mierzejewski wrote :
On Tuesday, 05 November 2013 at 11:00, Jean-Baptiste Kempf wrote:
On 04 Nov, Timothy Gu wrote :
would also be easier for other projects to integrate libdvdread/nav
to
their own application through submodules and things like that, and also easier for us to merge VLC changes if we will.
The thing is that our forks will be mandatory to build VLC in the very near future. So, if distributions want to package VLC, they will have to use that ones...
Are you planning to make incompatible changes?
I might. So far, no plans.
So it's ff/lav all over again? What about MPlayer? Do distros wanting to
No it's not. I don't plan to break anything. I might deprecate some things, like I did with libdvdcss 1.3.0. I compile MPlayer, xine, handbrake and VLC regularly enough to not break things. I just plan to have a correctly managed project to fix the numerous segfaults and issues and have a correctly copyrighted project (aka not SVN).
The only way out of this would be adding API/ABI compatibility, but as I see there is an 80% chance that there are not enough people to maintain that. Thus the ultimate solution would be the abandonment of this project in favor of yours.
Sorry, but that's not my problem anymore. I've complained enough about the old repo. You are very welcome to get commit access to our repo. (The dvdread one is done, the dvdnav is under history-rewrite). With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
On 11/6/13, Jean-Baptiste Kempf <jb@videolan.org> wrote:
On 05 Nov, Timothy Gu wrote :
On Nov 5, 2013 4:41 AM, "Jean-Baptiste Kempf" <jb@videolan.org> wrote:
On 05 Nov, Dominik 'Rathann' Mierzejewski wrote :
On Tuesday, 05 November 2013 at 11:00, Jean-Baptiste Kempf wrote:
On 04 Nov, Timothy Gu wrote :
would also be easier for other projects to integrate libdvdread/nav
to
their own application through submodules and things like that, and also easier for us to merge VLC changes if we will.
The thing is that our forks will be mandatory to build VLC in the very near future. So, if distributions want to package VLC, they will have to use that ones...
Are you planning to make incompatible changes?
I might. So far, no plans.
So it's ff/lav all over again? What about MPlayer? Do distros wanting to
No it's not. I don't plan to break anything. I might deprecate some things, like I did with libdvdcss 1.3.0. I compile MPlayer, xine, handbrake and VLC regularly enough to not break things.
I just plan to have a correctly managed project to fix the numerous segfaults and issues and have a correctly copyrighted project (aka not SVN).
The only way out of this would be adding API/ABI compatibility, but as I see there is an 80% chance that there are not enough people to maintain that. Thus the ultimate solution would be the abandonment of this project in favor of yours.
Sorry, but that's not my problem anymore. I've complained enough about the old repo.
You are very welcome to get commit access to our repo. (The dvdread one is done, the dvdnav is under history-rewrite).
Just throwing out a thought here.. My thought had been to request that jb be given commit rights to the mainline subversion (if he doesn't have it already?), so he can fix the segfaults there, and the two branches can possibly merge back into one. I trust him enough, even to add deprecations :) Plus that would increase the number of active maintainers by 1...it's extremely frustrating to see patches like [1] not be merged. Or if it were moved to github would that encourage you [jb] to not branch? I fear the branch might cause confusion here among developers... -roger- [1] http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/2013-July/001938.html
On 06 Nov, Roger Pack wrote :
My thought had been to request that jb be given commit rights to the mainline subversion (if he doesn't have it already?), so he can fix the segfaults there, and the two branches can possibly merge back into one. I trust him enough, even to add deprecations :)
No. There is no way I continue to work on such a crappy VCS. Especially seeing the amount of time it took to rewrite the history...
Or if it were moved to github would that encourage you [jb] to not branch? I fear the branch might cause confusion here among developers...
It is already on git.v.o, like libdvdcss. With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
Hi, On Wednesday, 06 November 2013 at 14:35, Jean-Baptiste Kempf wrote:
On 06 Nov, Roger Pack wrote :
My thought had been to request that jb be given commit rights to the mainline subversion (if he doesn't have it already?), so he can fix the segfaults there, and the two branches can possibly merge back into one. I trust him enough, even to add deprecations :)
No. There is no way I continue to work on such a crappy VCS. Especially seeing the amount of time it took to rewrite the history...
I'd support moving the SVN repo to Git provided that we start with the current state of SVN. Or, if you could explain the differences between your tree and current SVN, I'd consider pointing to your tree as the official one and start making releases out of that (but then I'd ask you for commit access). If moving to Git is what's necessary to revive this project, then I'm all for it. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
On 06 Nov, Dominik 'Rathann' Mierzejewski wrote :
I'd support moving the SVN repo to Git provided that we start with the current state of SVN.
http://git.videolan.org/?p=libdvdread.git;a=shortlog
Or, if you could explain the differences between your tree and current SVN, I'd consider pointing to your tree as the official one and start making releases out of that (but then I'd ask you for commit access).
There is not much there above the git-svn header. There are around 30 commits that are mostly from Erik and John's forks. Most of them are cleaning and crash fixes. The dvdnav one is still on-going rewrite, because of some old authors not found. With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
On 11/6/13, Jean-Baptiste Kempf <jb@videolan.org> wrote:
On 06 Nov, Dominik 'Rathann' Mierzejewski wrote :
I'd support moving the SVN repo to Git provided that we start with the current state of SVN.
http://git.videolan.org/?p=libdvdread.git;a=shortlog
Or, if you could explain the differences between your tree and current SVN, I'd consider pointing to your tree as the official one and start making releases out of that (but then I'd ask you for commit access).
There is not much there above the git-svn header.
There are around 30 commits that are mostly from Erik and John's forks. Most of them are cleaning and crash fixes.
The dvdnav one is still on-going rewrite, because of some old authors not found.
I'm ok with moving main dev. there if it lets patches like the gnosygnu one *finally* make it in. Yikes! The question mark is who will keep it updated with the svn stuff if this ends up just being a fork? jb? -roger-
On 28 Nov, Roger Pack wrote :
On 11/6/13, Jean-Baptiste Kempf <jb@videolan.org> wrote:
On 06 Nov, Dominik 'Rathann' Mierzejewski wrote :
I'd support moving the SVN repo to Git provided that we start with the current state of SVN.
http://git.videolan.org/?p=libdvdread.git;a=shortlog
Or, if you could explain the differences between your tree and current SVN, I'd consider pointing to your tree as the official one and start making releases out of that (but then I'd ask you for commit access).
There is not much there above the git-svn header.
There are around 30 commits that are mostly from Erik and John's forks. Most of them are cleaning and crash fixes.
The dvdnav one is still on-going rewrite, because of some old authors not found.
I'm ok with moving main dev. there if it lets patches like the gnosygnu one *finally* make it in. Yikes! The question mark is who will keep it updated with the svn stuff if this ends up just being a fork? jb?
Yep. I already maintain libdvdcss, and quite active in other BD libraries. With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
I'm ok with moving main dev. there if it lets patches like the gnosygnu one *finally* make it in
I'd also like to see the patch included. I don't know if the size of the patch is intimidating, or if there are other issues. However, with regards to the situation, please keep in mind the following: - The current jump_to_time code is inaccurate.[1] - The proposed jump_to_time code only adds new code, and does not alter existing one. If a program does not want to use the new functionality, it can choose not to call "dvdnav_jump_to_sector_by_time" and be otherwise unaffected - The solution really needs to be complicated. [2] Let me know if I can provide anything to help it along. Thanks. [1]: The current code interpolates the time based on logical block size. For a 20 minute cell with 50,000 sectors, the 10 minute mark is assumed to be 25,000, which will rarely be the case. Note that the current code is marked with a "FIXME: right now, this function does not use the time tables but interpolates only the cell times" [2]: The IFO files do not have a simple way of mapping time to sector. The only way to get this data is to go through the time maps and the sector maps, and even this is not straightforward On Thu, Nov 28, 2013 at 9:23 AM, Roger Pack <rogerdpack2@gmail.com> wrote:
On 11/6/13, Jean-Baptiste Kempf <jb@videolan.org> wrote:
On 06 Nov, Dominik 'Rathann' Mierzejewski wrote :
I'd support moving the SVN repo to Git provided that we start with the current state of SVN.
http://git.videolan.org/?p=libdvdread.git;a=shortlog
Or, if you could explain the differences between your tree and current SVN, I'd consider pointing to your tree as the official one and start making releases out of that (but then I'd ask you for commit access).
There is not much there above the git-svn header.
There are around 30 commits that are mostly from Erik and John's forks. Most of them are cleaning and crash fixes.
The dvdnav one is still on-going rewrite, because of some old authors not found.
I'm ok with moving main dev. there if it lets patches like the gnosygnu one *finally* make it in. Yikes! The question mark is who will keep it updated with the svn stuff if this ends up just being a fork? jb? -roger- _______________________________________________ DVDnav-discuss mailing list DVDnav-discuss@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
On 11/6/13, Jean-Baptiste Kempf <jb@videolan.org> wrote:
On 06 Nov, Dominik 'Rathann' Mierzejewski wrote :
I'd support moving the SVN repo to Git provided that we start with the current state of SVN.
http://git.videolan.org/?p=libdvdread.git;a=shortlog
Or, if you could explain the differences between your tree and current SVN, I'd consider pointing to your tree as the official one and start making releases out of that (but then I'd ask you for commit access).
There is not much there above the git-svn header.
There are around 30 commits that are mostly from Erik and John's forks. Most of them are cleaning and crash fixes.
The dvdnav one is still on-going rewrite, because of some old authors not found.
So the rewrite has been finished now, then? Do you have some url's for the new repository? -roger-
On 13 Feb, Roger Pack wrote :
On 11/6/13, Jean-Baptiste Kempf <jb@videolan.org> wrote:
On 06 Nov, Dominik 'Rathann' Mierzejewski wrote :
I'd support moving the SVN repo to Git provided that we start with the current state of SVN.
http://git.videolan.org/?p=libdvdread.git;a=shortlog
Or, if you could explain the differences between your tree and current SVN, I'd consider pointing to your tree as the official one and start making releases out of that (but then I'd ask you for commit access).
There is not much there above the git-svn header.
There are around 30 commits that are mostly from Erik and John's forks. Most of them are cleaning and crash fixes.
The dvdnav one is still on-going rewrite, because of some old authors not found.
So the rewrite has been finished now, then? Do you have some url's for the new repository?
git://git.videolan.org/libdvdnav.git like all the projects hosted at videolan.org -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
Hi Timothy, On Monday, 28 October 2013 at 02:06, Timothy Gu wrote:
It's quite some time before the last release. There are some critical security fixes in SVN now. I guess it should be time for a new release.
It is, it's just that I'm still very busy these days. I can't promise anything, but I should be able to spare some time this weekend.
Also, if possible, can someone back port changes in the VideoLAN's fork to the official one?
I'd do that happily if I had more time. As it is, they would have much better chance of being included in SVN if: 1. someone posted them as well-formed patches to this mailing list 2. someone reviewed them Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
participants (7)
-
Dominik 'Rathann' Mierzejewski -
Erik Hovland -
gnosygnu -
Jean-Baptiste Kempf -
Paul Menzel -
Roger Pack -
Timothy Gu