From: Barry S. <bar...@on...> - 2006-03-23 10:08:46
|
I'm seeing a lot of patches being sent to this list. Are they being reviewed and committed? I would hope that with the level of bug fixing that the patches imply a xinelib 1.1.2 should be released soon. Barry |
From: Michael R. <mr...@us...> - 2006-03-23 19:51:13
|
Hi, > I'm seeing a lot of patches being sent to this list. Are they being > reviewed and committed? Good question. The problem is, at least for me, far too little time. I am currently in the middle of my diploma thesis (roughly equivalent to a master's degree) and although I am trying, I just don't get much done besides that. Other core members of the team seem to be equally short on free time. I might get around to do something on the coming weekend, but obviously we need a more stable solution. I am open to any suggestions. Michael |
From: Barry S. <bar...@on...> - 2006-03-24 11:39:38
|
Michael Roitzsch wrote: > Hi, > >> I'm seeing a lot of patches being sent to this list. Are they being >> reviewed and committed? > > Good question. The problem is, at least for me, far too little time. I > am currently in the middle of my diploma thesis (roughly equivalent to > a master's degree) and although I am trying, I just don't get much > done besides that. Other core members of the team seem to be equally > short on free time. > > I might get around to do something on the coming weekend, but > obviously we need a more stable solution. I am open to any suggestions. I guess there are three problems: 1. Review of patches - Is the patch useful? Does it work? 2. Testing of patches - does the patch introduce any instablilty? 3. Getting the code into CVS - new patches on a branch maybe? Merge after positive reports to trunk? I can help with (2) for the input's that we use here all the time. input_v4l, input_dvb, input_rtp and xv output. For (1) I can comment on the areas that I've dug into, but there is a lot of xine that is still magic. I've not got much time to do (3), as you point out this needs some one with time to help. Barry |
From: Marcel J. <ko...@ho...> - 2006-03-24 19:04:40
|
On Thursday 23 March 2006 20:51, Michael Roitzsch wrote: > I am open to any suggestions. I think sourceforge has a "Patches" facility besides the one for bugs. Perhaps it's a good idea to use that ? This way the patches are not forgotten and it's possible to assign it to a person for testing. Anyone can check out a patch and comment whether they work well or not (for whatever that's worth to the developers). I'm not a core developer and will never be I think. I have two full time jobs, so it's quite easy to understand that I also have a serious lack of time. It's already quite difficult for me to get a simple patch done but when I finish a patch I hope it's not forgotten of course ;-) Best of luck with your thesis, Marcel |
From: Hans-Dieter K. <hd...@t-...> - 2006-03-25 02:00:58
|
Marcel Janssen wrote: > > I think sourceforge has a "Patches" facility besides the one for bugs. Perhaps > it's a good idea to use that ? > This way the patches are not forgotten and it's possible to assign it to a > person for testing. Anyone can check out a patch and comment whether they > work well or not (for whatever that's worth to the developers). > I never had a look at this but it sounds quite reasonable. However, it only seems useful to me if people have enough time to work out all the patches. I've recognized in the past that lack of time is more and more an issue (maybe we can open a separate thread for discussion about reasons and solutions, but this again takes time...). For my part, it takes me long time to commit a patch to be sure that there are no regressions nor side effects (and even then I feel not sure ;-) ). > I'm not a core developer and will never be I think. I have two full time jobs, > so it's quite easy to understand that I also have a serious lack of time. > It's already quite difficult for me to get a simple patch done but when I > finish a patch I hope it's not forgotten of course ;-) > I understand what you mean. I have a full time job too. Nevertheless, be ensured: Your last patch (xine-ui save/auto load...) is not forgotten. I have it in my personal private archive (my alternative to sourceforge's facility ;-) ). Please be patient, I honestly promise to review and commit :-) Cheers, Hans-Dieter |
From: Vincent M. <Vin...@ne...> - 2006-03-26 09:36:48
Attachments:
freebox-rtsp.patch.gz
|
Hi Here is a patch which allow support for the rtsp mrl provided by the freebox. In France we have an Internet Provider (Free : http://www.free.fr) whose DSL modem (freebox) act as an RTSP/RTP/AVP server, to watch television MPEG2 Transport Stream (http://adsl.free.fr/tv/multiposte/ - in French sorry). My patch is based on the input_rtp plugin and the work from the freesdp project (from which I copied some files). AVP profile is number 33 (Transport Stream); stream is multiplexed and can be demultiplexed with demux_ts (there are not both stream, one with audio and the other with video). It works, but there are still problems : - As I understand nothing to autoconf/automake/etc... you have to compile it by hand. Files in librtp directory => librtp.a and input_rtsp should be linked too with librtp.a. And to compile files in librtsp you have now to add an -I../librtp. If someone can help me (I modified Makefile.am but after that running automake doesn't produce something correct), I will greatly appreciate :) - I tried to integrate freebox support as much as possible with the current real support, and tried not to break real support, but I am not sure, as I didn't test real mrl. - One channel has Dolby Digital (all the other are MPEG audio), and with the current version of demux_ts, this audio is not read. By changing this (around line 1720) : ------------------------ } else if ((pes_stream_id >= AUDIO_STREAM_S) && (pes_stream_id <= AUDIO_STREAM_E)) { ------------------------ with this : ------------------------ } else if (((pes_stream_id >= AUDIO_STREAM_S) && (pes_stream_id <= AUDIO_STREAM_E)) || pes_stream_id == PRIVATE_STREAM1) { ------------------------ it works. But I am not sure it is a good solution. Thank you, and sorry for my bad english... Vincent |
From: Barry S. <bar...@on...> - 2006-03-27 10:46:51
|
Hans-Dieter Kosch wrote: > Marcel Janssen wrote: >> >> I think sourceforge has a "Patches" facility besides the one for >> bugs. Perhaps it's a good idea to use that ? >> This way the patches are not forgotten and it's possible to assign it >> to a person for testing. Anyone can check out a patch and comment >> whether they work well or not (for whatever that's worth to the >> developers). >> > I never had a look at this but it sounds quite reasonable. However, it > only seems useful to me if people have enough time to work out all the > patches. What do you mean by "work out the patches"? Test them or create and file them? The patches are being created and filing them on source forge with a email here to discuss them is close to what is already happening except the SF will do the book keeping. > I've recognized in the past that lack of time is more and more an > issue (maybe we can open a separate thread for discussion about > reasons and solutions, but this again takes time...). For my part, it > takes me long time to commit a patch to be sure that there are no > regressions nor side effects (and even then I feel not sure ;-) ). If there was an integration/up-for-testing branch the load of testing can be spread amongst the community. I would also help to migrate to subversion so that patches can be committed as change sets. Barry |
From: Hans-Dieter K. <hd...@t-...> - 2006-03-31 00:04:07
|
Hi Barry, Barry Scott wrote: > Hans-Dieter Kosch wrote: > >> Marcel Janssen wrote: >> >>> >>> I think sourceforge has a "Patches" facility besides the one for >>> bugs. Perhaps it's a good idea to use that ? >>> This way the patches are not forgotten and it's possible to assign it >>> to a person for testing. Anyone can check out a patch and comment >>> whether they work well or not (for whatever that's worth to the >>> developers). >>> >> I never had a look at this but it sounds quite reasonable. However, it >> only seems useful to me if people have enough time to work out all the >> patches. > > What do you mean by "work out the patches"? Test them or create and file > them? I mean the whole work of reviewing, testing and committing. > The patches are being created and filing them on > source forge with a email here to discuss them is close to what is > already happening except the SF will do the book keeping. I agree. > If there was an integration/up-for-testing branch the load of testing > can be spread amongst the community. Probably good idea, worth discussing, I think. Cheers, Hans-Dieter |
From: Darren S. <li...@yo...> - 2006-04-04 22:51:27
|
I demand that Barry Scott may or may not have written... [snip] > I would also help to migrate to subversion so that patches can be > committed as change sets. FWIW, I've been using mercurial while Sourceforge developer CVS was down; it seems to be working well, though I gave it a limited change set to work with. I may yet give it the whole of the gxine source; tags, branches and all. This will require the use of certain cvs admin commands since tailor doesn't handle tags and branches; also, I don'tso that I can set the tags and do the branches too. I don't, however, have anywhere to host it, so I'm not going to bother right now. (I should probably have used tailor's repository sync function to commit the changes to CVS, though.) -- | Darren Salt | d @ youmustbejoking,demon,co,uk | nr. Ashington, | Toon | RISC OS, Linux | s zap,tartarus,org | Northumberland | Army | Kill all extremists! You say that now, but try chewing a child the next time you're car sick. |
From: Barry S. <bar...@on...> - 2006-04-10 12:20:12
|
Darren Salt wrote: > I demand that Barry Scott may or may not have written... > > [snip] > >> I would also help to migrate to subversion so that patches can be >> committed as change sets. >> > > FWIW, I've been using mercurial while Sourceforge developer CVS was down; it > seems to be working well, though I gave it a limited change set to work with. > There are lots of source control systems, but only a few are well supported. I've not heard of mercurial until your message and don't want to have to learn it for one project. Subversion works well, is scriptable, has lots of tools built on top of it and is understood by a large community of users. Barry |
From: Alien <ali...@us...> - 2006-04-10 13:01:25
|
On Monday 10 April 2006 14:19, Barry Scott wrote: > Darren Salt wrote: > > I demand that Barry Scott may or may not have written... > > > > [snip] > > > >> I would also help to migrate to subversion so that patches can be > >> committed as change sets. > > > > FWIW, I've been using mercurial while Sourceforge developer CVS was down; > > it seems to be working well, though I gave it a limited change set to > > work with. > > There are lots of source control systems, but only a few are well > supported. I've not > heard of mercurial until your message and don't want to have to learn it > for one > project. Subversion works well, is scriptable, has lots of tools built > on top of it and > is understood by a large community of users. and it's been online for a while at SF... I myself have registered for it recently (my own project) (when dev CVS was down) and also put a ciabot hook on it. -- Alien is my name and head-biting is my game |
From: Michael R. <mr...@us...> - 2006-04-10 13:13:00
|
Hi, >> Subversion works well, is scriptable, has lots of tools built on >> top of it and is understood by a large community of users. > > and it's been online for a while at SF... > > I myself have registered for it recently (my own project) (when dev > CVS was down) and also put a ciabot hook on it. What are your experiences with it? If the SVN service is stable, we should seriously consider moving xine over to SVN, which would allow for some badly needed reorganization of some directory structures. Michael |
From: Alien <ali...@us...> - 2006-04-10 13:48:26
|
On Monday 10 April 2006 15:12, Michael Roitzsch wrote: > Hi, > > >> Subversion works well, is scriptable, has lots of tools built on > >> top of it and is understood by a large community of users. > > > > and it's been online for a while at SF... > > > > I myself have registered for it recently (my own project) (when dev > > CVS was down) and also put a ciabot hook on it. > > What are your experiences with it? > > If the SVN service is stable, we should seriously consider moving > xine over to SVN, which would allow for some badly needed > reorganization of some directory structures. > > Michael my experience is short ( about 3 days) but it works well, is fast, simple and has no delay between anonymous and developer BY DESIGN. there is only one svn server and when you commit, it will require your authentication, but not before that. this has quite some advantages: if there is a person who uses it and has put patches out and you're giving him access to it, he can still use the same repository. there are a few things you need to consider, there are quite some people who have migrated from cvs without reading the subversion website on how it works and how you should organize it. as a result of that, they have poor support for branching etc... myself i chose the following scheme: https://svn.sourceforge.net/svnroot/oriongame you'll see that i have first put all modules (in xine this would mean the following): svnroot/xine - xine-lib - trunk - branches - tags - private - xine-ui - trunk - branches - tags - private - website - trunk - branches - tags - private the trunk is where you put the CVS HEAD branches and tags are the same system: you just copy the whole repos under a new directory: branches/branch_branchname/ (this is similar to hardlinking and keeps full history from all files). I added a private subdir and this allows people to put a directory under it with their own name: xine-lib/private/mrio/... this is for when you are working on something, it's not finished, but you would like to commit frequently anyway, even though it would break and not compile and definately not run... every person can have an on-server backup this way... be sure to read the subversion reasoning documentation on their site before you create your repos. also: - remove the CVS directories from the svn-repository, they don't belong there. - .cvsignore also is not required, you can use the svn:ignore property for that. I found the following things very nice: - atomic commits (first it registers what it will do, and then it sends all data) - nicer directory handling - binary files are handled quite nicely - i like the properties and its system - once you get the hang of the branches/tags its nice about SF subversion, i cannot tell you much, but it's not been down yet and it's quite fast... -- Alien is my name and head-biting is my game |
From: Barry S. <bar...@on...> - 2006-04-10 16:43:12
|
Michael Roitzsch wrote: > Hi, > >>> Subversion works well, is scriptable, has lots of tools built on top >>> of it and is understood by a large community of users. >> >> and it's been online for a while at SF... >> >> I myself have registered for it recently (my own project) (when dev >> CVS was down) and also put a ciabot hook on it. > > What are your experiences with it? > > If the SVN service is stable, we should seriously consider moving xine > over to SVN, which would allow for some badly needed reorganization of > some directory structures. > I converted my SF project (cxx.sf.net) to SVN a couple of weeks ago and was impressed that all the CVS history made it over into the SVN repos. I have not done a lot with it but I did some work over the weekend and its just worked. I also have a project (pysvn.tigris.org) hosted by tigris.org (home of subversion) and the sf.net seemed to be faster then accessing tigris.org. At work we have been using svn for 2 years and I have been using it at home for a bit longer. SVN is very stable and robust. Barry |
From: Darren S. <li...@yo...> - 2006-04-10 18:01:39
|
I demand that Barry Scott may or may not have written... > Darren Salt wrote: [snip] >> FWIW, I've been using mercurial while Sourceforge developer CVS was down; >> it seems to be working well, though I gave it a limited change set to work >> with. > There are lots of source control systems, but only a few are well > supported. I've not heard of mercurial until your message and don't want to > have to learn it for one project. Similarly, I don't want to have to learn to use svn. (Actually, I've needed to use it for another project, but I've done next to nothing there because of svn...) -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | <URL:http://www.youmustbejoking.demon.co.uk/progs.packages.html> May the fleas of a thousand camels infest your armpits. |
From: Maarten V. <su...@ba...> - 2006-04-10 12:53:41
|
On Monday 10 April 2006 14:19, Barry Scott wrote: > Darren Salt wrote: > > I demand that Barry Scott may or may not have written... > > > > [snip] > > > >> I would also help to migrate to subversion so that patches can be > >> committed as change sets. > > > > FWIW, I've been using mercurial while Sourceforge developer CVS was down; > > it seems to be working well, though I gave it a limited change set to > > work with. > > There are lots of source control systems, but only a few are well > supported. I've not > heard of mercurial until your message and don't want to have to learn it > for one > project. Subversion works well, is scriptable, has lots of tools built > on top of it and > is understood by a large community of users. and it's been online for a while at SF... I myself have registered for it recently (my own project) (when dev CVS was down) and also put a ciabot hook on it. -- Maarten Vanraes BA NV infosecurity: inschrijven via http://www.ba.be/infosecurity/ |
From: Mike M. <mi...@mu...> - 2006-04-10 18:06:26
|
Darren Salt wrote: > Similarly, I don't want to have to learn to use svn. (Actually, I've needed > to use it for another project, but I've done next to nothing there because of > svn...) Are you serious? A good rule of thumb is: If you can use cvs, you can use svn. "svn co svn://..."; "svn update"; "svn diff" (you don't even need to specify '-u' for unified format diff); "svn commit". That's really all there is to it from the client's perspective. -- -Mike Melanson |
From: Darren S. <li...@yo...> - 2006-04-10 18:52:44
|
I demand that Mike Melanson may or may not have written... > Darren Salt wrote: >> Similarly, I don't want to have to learn to use svn. (Actually, I've >> needed to use it for another project, but I've done next to nothing there >> because of svn...) > Are you serious? A good rule of thumb is: If you can use cvs, you can use > svn. "svn co svn://..."; "svn update"; "svn diff" (you don't even need to > specify '-u' for unified format diff); "svn commit". That's really all > there is to it from the client's perspective. It's more the way in which it handles branching and tagging. I just don't like it... -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | Say NO to UK ID cards. http://www.no2id.net/ Steer clear of incorrect forms of verbs that have snuck in the language. |
From: Alien <ali...@us...> - 2006-04-10 19:53:22
|
Op maandag 10 april 2006 20:29, schreef Darren Salt: > I demand that Mike Melanson may or may not have written... > > > Darren Salt wrote: > >> Similarly, I don't want to have to learn to use svn. (Actually, I've > >> needed to use it for another project, but I've done next to nothing > >> there because of svn...) > > > > Are you serious? A good rule of thumb is: If you can use cvs, you can u= se > > svn. "svn co svn://..."; "svn update"; "svn diff" (you don't even need = to > > specify '-u' for unified format diff); "svn commit". That's really all > > there is to it from the client's perspective. > > It's more the way in which it handles branching and tagging. I just don't > like it... just read the short documentation of svn and their reasoning, you'll notice= =20 how they addressed the concerns people have over cvs quite properly, and i= =20 promise you after you read it, you'll become impressed at how simple and=20 efficient it is... |
From: Ed W <li...@wi...> - 2006-04-15 16:26:59
|
Also, I have used Trac a little on a couple of projects and it's an excellent utility for tracking projects, opening tickets, tracking patches, etc. Very, very impressive. You can see it in action on the Mythtv project at http://svn.mythtv.org I won't suggest that any of these changes are trivial to make, but the SVN + Trac combo seems excellent to me... Ed W |
From: Brian J. T. <bj...@co...> - 2006-04-15 19:21:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed W wrote: > Also, I have used Trac a little on a couple of projects and it's an > excellent utility for tracking projects, opening tickets, tracking > patches, etc. Very, very impressive. > > You can see it in action on the Mythtv project at http://svn.mythtv.org > > I won't suggest that any of these changes are trivial to make, but the > SVN + Trac combo seems excellent to me... One of the projects on a server I help admin was using Trac for something not too long ago, but the Trac process would constantly jump to 100% CPU and start consuming RAM like crazy. As you might guess, we ditched Trac. Not saying this will be/is everyone's experience; just saying it's possible. -brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEQUfF6XyW6VEeAnsRAi/xAJ0VZ1aGmLKJSQdyS3G3mTVycfur2QCgtvve 0kxfcuSr/OCJL6/m44Tn6hg= =LFDT -----END PGP SIGNATURE----- |