Merging OSX Extended
Hello OSX List, 10 months and 10 revisions ago I started the MPlayer OSX Extended branch, initially to add two options to the preferences but soon to add features and to fix things where they nagged me. I received various questions about merging my branch back to the main one. Branching ever really was only a way for me to get to know the project and to steadily advance on the way to keep my motivation. I think now would be a good time to merge Extended back into the main branch and I would like to get some feedback on this. What would be the preferred way to undertake this merge? My SVN history goes back to revision 5 but individual commits are quite big at the beginning. Should I just merge Extended in one go or merge individual releases? On a separate note, the sourceforge project page of the original MPlayer OSX project is confusing a lot of people. Does anybody have access to the project to add a message that it's dead and been taken over by mplayerhq.hu? Greetings Adrian
Hi, On Thu, May 7, 2009 at 11:54 PM, Adrian Stutz <adrian@sttz.ch> wrote:
Hello OSX List,
10 months and 10 revisions ago I started the MPlayer OSX Extended branch, initially to add two options to the preferences but soon to add features and to fix things where they nagged me.
I received various questions about merging my branch back to the main one. Branching ever really was only a way for me to get to know the project and to steadily advance on the way to keep my motivation.
I think now would be a good time to merge Extended back into the main branch and I would like to get some feedback on this.
What would be the preferred way to undertake this merge? My SVN history goes back to revision 5 but individual commits are quite big at the beginning. Should I just merge Extended in one go or merge individual releases?
MPlayer and FFmpeg developement rules require to commit changes in a way that makes them as much readable and reviewable as possible. So big changes are frown upon. However, MPlayerOSX has been a one-man project so far (Nicolas Plourde), and I'm not sure what rule he followed so far. It may be a good idea to drop him a mail to has his that.
On a separate note, the sourceforge project page of the original MPlayer OSX project is confusing a lot of people. Does anybody have access to the project to add a message that it's dead and been taken over by mplayerhq.hu?
Did you try using the contact page of sourceforge? Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Emma Goldman - "If voting changed anything, they'd make it illegal."
On Sat, May 9, 2009 at 12:19 PM, Guillaume POIRIER <poirierg@gmail.com> wrote:
MPlayer and FFmpeg developement rules require to commit changes in a way that makes them as much readable and reviewable as possible.
So big changes are frown upon.
However, MPlayerOSX has been a one-man project so far (Nicolas Plourde), and I'm not sure what rule he followed so far. It may be a good idea to drop him a mail to has his that.
I did write him some time ago and he told me I could go ahead with the merge, though we didn't discuss any specifics. I do know the MPlayer rules and that's mostly why I want to discuss it here first. I've been steadily increasing the organization of the development, separating changes, tracking bugs or gathering feedback. I hope to continue this as part of the official MPlayer OSX project and to hopefully improve quality with more people looking at my changes. Though going back and breaking down all changes would be a huge effort and IMO not worth the time, which can be invested into advancing development instead. I can imagine doing either: * Merging Extended in one go, just like an initial import * Merging all ten revisions individually * Moving the Extended repo and disuse the current one
Did you try using the contact page of sourceforge?
I did try to find any info on the sourceforge page but wanted to ask here first before I contact them directly. Greetings Adrian
Hello, On Mon, May 11, 2009 at 10:53 PM, Adrian Stutz <adrian@sttz.ch> wrote:
On Sat, May 9, 2009 at 12:19 PM, Guillaume POIRIER <poirierg@gmail.com> wrote:
MPlayer and FFmpeg developement rules require to commit changes in a way that makes them as much readable and reviewable as possible.
So big changes are frown upon.
However, MPlayerOSX has been a one-man project so far (Nicolas Plourde), and I'm not sure what rule he followed so far. It may be a good idea to drop him a mail to has his that.
I did write him some time ago and he told me I could go ahead with the merge, though we didn't discuss any specifics.
I put him in CC in case he wants to take part to the discussion.
I do know the MPlayer rules and that's mostly why I want to discuss it here first. I've been steadily increasing the organization of the development, separating changes, tracking bugs or gathering feedback. I hope to continue this as part of the official MPlayer OSX project and to hopefully improve quality with more people looking at my changes.
Hopefully yes, but I don't think there are that may people who have much knowledge about OSX's API! :-(
Though going back and breaking down all changes would be a huge effort and IMO not worth the time, which can be invested into advancing development instead.
I know the feeling. I know that if the rules of development are too tough, they scare people away, and people end-up working on their own fork... which is a terrible waste of time! Please consider this: Pulling small, self-contained changes from your fork may be a chance to "proofread" your own code, giving your a chance to improve the overall quality of the code that you pull.... I don't know how much code/work you've put towards your fork, but this "merging" method may be worthwhile after all....
I can imagine doing either: * Merging Extended in one go, just like an initial import.
Certainly not.
* Merging all ten revisions individually
If each of these revisions make sense individually, that the solution I dislike the least.
* Moving the Extended repo and disuse the current one
Well, you can hardly call that merging OSX Extended, can you? (which is the title of the mailing list thread!) In the end, I'm not the one making decisions, I'm just trying to help you conform to how things are done on MPlayer and FFmpeg projects. I'm happier if you ignore my advices and work heavily on MPlayerOSX to make it a lot better than having you run away because of the rules are too hard to work with. But I'd be much happier if you could do "small enough" incremental changes instead! :-)
Did you try using the contact page of sourceforge?
I did try to find any info on the sourceforge page but wanted to ask here first before I contact them directly.
IFAIR, the people from this project have never been part of MPlayer's dev team, and Nico took over maintainer ship on mplayer's svn... Cheers! Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Don Marquis - "Procrastination is the art of keeping up with yesterday." - http://www.brainyquote.com/quotes/authors/d/don_marquis.html
On Mon, May 11, 2009 at 11:29 PM, Guillaume POIRIER <poirierg@gmail.com> wrote:
I put him in CC in case he wants to take part to the discussion.
Mailman tells me Nicolas is subscribed to the list, I hope he doesn't have it on an ignore filter. :)
Pulling small, self-contained changes from your fork may be a chance to "proofread" your own code, giving your a chance to improve the overall quality of the code that you pull....
I definitely see the benefits of merging small changes. It's just quite a lot of changes, including inter-dependent ones that won't be straight forward to merge independently.
I don't know how much code/work you've put towards your fork, but this "merging" method may be worthwhile after all....
I just tried to use diffstat: $ svn diff -r 1:HEAD | diffstat 57 files changed, 17819 insertions(+), 1367 deletions(-) As comparison, MPlayer's last month: $ svn diff -r {2009-04-11}:{2009-05-11} | diffstat 170 files changed, 5231 insertions(+), 3969 deletions(-) As a rough estimate, Extended has 28.8% insertions and 2.9% deletions of the MPlayer volume.
Well, you can hardly call that merging OSX Extended, can you? (which is the title of the mailing list thread!)
Well, sure. I just wanted to get responses on the different options, even alternatives to merging.
In the end, I'm not the one making decisions, I'm just trying to help you conform to how things are done on MPlayer and FFmpeg projects. I'm happier if you ignore my advices and work heavily on MPlayerOSX to make it a lot better than having you run away because of the rules are too hard to work with.
Well, I'm not planning to run away. :) I'm just trying to figure out what the best way could be and appreciate any input. Greetings Adrian
On Mon, May 11, 2009 at 11:55:24PM +0200, Adrian Stutz wrote:
On Mon, May 11, 2009 at 11:29 PM, Guillaume POIRIER <poirierg@gmail.com> wrote:
I put him in CC in case he wants to take part to the discussion.
Mailman tells me Nicolas is subscribed to the list, I hope he doesn't have it on an ignore filter. :)
Better CC him or ask him in private, I doubt he is following this list. I don't mind what you do with MPlayer OS X as long as Nicolas is OK with it, but AFAIU he already gave you carte blanche. Do whatever allows you to get started with productive work quickly. Diego
hi, sorry for not following the thread earlier I have limited Internet acces at the moment (in Paris on vacation) you can start merging the code in the main branch I have no objection but keep it clean. On 2009-05-12, at 22:20, Diego Biurrun <diego@biurrun.de> wrote:
On Mon, May 11, 2009 at 11:55:24PM +0200, Adrian Stutz wrote:
On Mon, May 11, 2009 at 11:29 PM, Guillaume POIRIER <poirierg@gmail.com
wrote: I put him in CC in case he wants to take part to the discussion.
Mailman tells me Nicolas is subscribed to the list, I hope he doesn't have it on an ignore filter. :)
Better CC him or ask him in private, I doubt he is following this list.
I don't mind what you do with MPlayer OS X as long as Nicolas is OK with it, but AFAIU he already gave you carte blanche. Do whatever allows you to get started with productive work quickly.
Diego _______________________________________________ mplayerosx-devel mailing list mplayerosx-devel@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayerosx-devel
participants (4)
-
Adrian Stutz -
Diego Biurrun -
Guillaume POIRIER -
Nicolas Plourde