From: Stephen t. <st...@to...> - 2004-08-31 02:49:47
|
Since this is my first release I will be looking to the domain experts for various parts of xine to help out with suppling the status of things. As it stands by the TODO the xine-lib library should be almost ready for the famous 1.0 release. At this point no new features should have crept into the CVS repository. We should be looking at the remaining bugs that need to be fixed. ------------- Admin Stuff ------------- To start things out I have a few administrative question: 1) Why is the ChangeLog used to list items version need to support? Why is the TODO file not used? The reason I ask is that the ChangeLog does not read like things that have changed but future things to change. I would like to : - move all future things to be in TODO - have ChangeLog say was has been done. 2) Have we resolved the best way for user to report bugs? Is the sourceforge bug tracker used? ------------ Cool things to add ------------ Here is a list of things that I gleaned from the TODO and the ChangeLog that we are trying to provide. I need help distinguishing which are doable for this release and what should be put off for 1-rc7 or 1.0. For each one I am trying to understand what their status is, how much longer it will take (education guess) to complete and whether its a show-stopper for 1-rc6. xine-lib (1-rc6) * move win32 frontend into separate module Status: COMPLETED Time required: None 1-rc6 Stopper: No - As it stands I believe this complete. Is that right? * fix Xv initialization to enable multiple instances of the Xv plugin Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * remove XInitThreads() call from some video out plugins, because it might lead to undefined behaviour; calling XInitThreads() is entirely the frontend's job Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * include goom2k4-dev18 Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * make sure the streams are played till their very end Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * support for Annodex files Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN NOTE: This is the first time I heard of the file type. I tried a link http://www.annodex.net/media/sciweb/index.anx and xine appeared to do nothing. I could not detect if anything was happening beyond seeing that I had a connection with the server via netstat. * VobSub-in-Matroska support Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * guess and use Windows encoding as default for external subtitles Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * quality improvements for full frame rate deinterlacing modes Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * Add support for 44100Hz DTS in .wav files. Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * restore initial xv port attributes on exit [bugs #965572, #957599] Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * fix brightness drift problem (loss of color) [bugs #947520, #963587] Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * fix rare heap overflow with some DVD subpictures [bug #923843] Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * fix stack overflows in the VCD plugin Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * experimental time stretching plugin: play stream faster or slower than original speed, optionally preserving pitch Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * another win32 dll crash fix (after playing several files) Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * configure option for building xine with external ffmpeg library Status: COMPLETED Time required: None 1-rc6 Stopper: No * added api for finer playback speed control (requires frontend support) Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * support QuickTime 6.3 DLLs Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * improved response time on video grabber ports Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * support mp3 audio in mp4 files Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * use utf-8 for matroska subtitles Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * next stage of MINGW port - engine library compiles now Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * Improve DVD MRL handling. Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * Improve Transport stream handling. Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN * Compiler warnings fixed: Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN NOTE: I would like to introduce a flag to be added to the configure script that would add the -Werror to the CFLAGS in order to flush out warnings. I have done this in another project and called the flag "enable-fatal-warnings". * Translations are done: Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN Languages supported and translator: Czech: Frantisek Dvorak German: Philip Hahn Spanish: Juan Manuel GarcA a Molina French: Daniel Caujolle-Bert Italian: Giovanni Venturi Polish: Bartaomiej Muryn Portuguese (Brazilian): Marcelo Roberto Jimenez Slovak: ? NOTE: I would appreciate to know what the status of their respective translations is. xine engine structure review and resorting/reorganizing has been done: Status: UNKNOWN Time required: UNKNOWN 1-rc6 Stopper: UNKNOWN ----------- BUGS: (As gleaned from the SF site) ----------- Which bugs are still valid problems? Those that are invalid will need to be removed from the bug tracker if that is our suggested means for reporting bugs. 1018193 brightness sets very high when doing menu choice 2004-08-28 1015803 Some real stream aren't recognized 2004-08-24 1014449 Cannot compile xine-ui-0.99.2 2004-08-23 1013454 xine-check invalid msg 2004-08-21 1001508 Does not crop MPEG-2 TS correctly (1088->1080) 2004-08-01 999633 Xine avi playback problem 2004-07-28 995961 Incorrect timeout when using pthread_cond_timedwait 2004-07-22 989089 mkv problems with AC3 and vobsub 2004-07-11 987852 Codec not found -> boom 2004-07-09 986594 Problems with WM and RM streams 2004-07-07 984766 libGL.la missing during make, easy fix 2004-07-03 980250 Particulat video only starts video after jiggling timing 2004-06-26 978692 stacking Bug 2004-06-23 976423 Quitting whilst paused plays burst of audio (using ALSA) 2004-06-20 976406 Bad A/V sync with High Definition WMV 2004-06-20 976344 3:2 pulldown detection fails with bottom field first 2004-06-20 976231 crash with fb output, zero_copy disabled 2004-06-20 973678 <linux/config.h> linux-2.6.x could be empty 2004-06-15 972100 MP4 Problems 2004-06-13 961456 gxine crash 2004-05-27 955234 configure script fails to find Xv extension 2004-05-17 952909 AAC audio missing from NSV stream/xine-ui crash 2004-05-12 944773 Xine-plugin doesn't handle player controls in webpage 2004-04-29 940013 Error compiling limpeg2 on ppc/altivec 2004-04-22 939631 mozilla and mozilla-firefox may not start under xfce when x 2004-04-21 937284 well, this is a very nasty stream 2004-04-18 937011 xine-ui-0.99.1 item text too big in keymap editor 2004-04-17 936977 Xine locks up if DVB card won't get a lock on signal 2004-04-17 929041 xine doesn't properly handle quicktime vr 2004-04-03 928823 WMA9 Voice problems 2004-04-03 908698 DVD Snapshot in FS mode makes gxine unresponsive 2004-03-02 906455 LFE disappears when downmixing to 2.0 2004-02-28 897430 xine-lib-1-rc3a won't link 2004-02-15 895766 nForce 2, Slack 9.1, Alsa 0.96+, SPDIF fail 2004-02-12 879228 in rc3a; wmv ends 40seconds before it's end 2004-01-18 868255 deinterlacing not working correctly 2003-12-30 865233 xine + alsa + alii5451 = libmad: ALERT input buffer too sma 2003-12-23 858304 xine-lib-1-rc2 won't compile on FreeBSD (GENERAL_REGS) 2003-12-11 851189 seeking over Real streams 2003-11-29 843786 No 24-bit LPCM DVD support 2003-11-17 842244 choppy real audio playback 2003-11-14 838766 xine locks up during buffering DVB 2003-11-09 838751 Error: suffix or operands invalid for `paddusb' 2003-11-09 827846 emu10k1 oss: AFMT_AC3 workaround breaks soundoutput 2003-10-21 781774 WMA9P problems 2003-08-01 781532 setting system time crashes libxine 2003-08-01 740591 Xine should respect max Xv size 2003-05-20 739433 xine-ui shuts down when switching resolution 2003-05-18 704783 gcc-3.2 build broken 2003-03-16 675461 Strange OSD rendering 2003-01-27 As soon as I have this information I can begin to see what to give as a release date. Thanks ahead of time for helping me to learn how to do a release. :) Stephen -- Email: st...@to... |
From: Miguel F. <mfr...@gm...> - 2004-08-31 13:26:50
|
Hi Stephen, On Mon, 30 Aug 2004 22:49:53 -0400, Stephen torri <st...@to...> wrote: > ------------- > Admin Stuff > ------------- > To start things out I have a few administrative question: > > 1) Why is the ChangeLog used to list items version need to support? > Why is the TODO file not used? The reason I ask is that the ChangeLog > does not read like things that have changed but future things to > change. hey, no! ChangeLog things HAVE been implemented! most of them were discussed on xine-devel, and you surely can read about all of them on the xine-cvs archives. > 2) Have we resolved the best way for user to report bugs? Is the > sourceforge bug tracker used? yes. we just need to add a link to our home page. btw, still talking about admin stuff... do you know php? i'm asking because there have been some discussion on xine-docs (i can forward it to you if you want) about planned changes to our home page. basically, it was a matter of reworking the main entries, like adding a "developers corner" with all information regarding developing with/for libxine, making the testsuite public and linking to the bug tracker and xine-users as means of reporting bugs and getting support. imho you already fulfill two important requirements for the job: you are a native english speaker and you have time (?)... so, do you want this job too? ;-) there is one show-stopper bug i'd like to fix before rc6: the blue window problem. unfortunately i cannot reproduce it here, at first i thought it was specific to intel video cards but now it seems matrox is affected too when running new x.org xserver. i have no x.org to test, but i have a G450 at home. it is difficult to debug this problem, i will try to compile x.org but i don't want to mess with my working system... about the release process, you should definitely read xine-lib/doc/internal/HOWTO.release. this file contains about everything one need to know to make a release (thanks Siggi!) regards, Miguel |
From: Stephen t. <st...@to...> - 2004-08-31 16:26:18
|
On Tue, 2004-08-31 at 09:26, Miguel Freitas wrote: > Hi Stephen, > > On Mon, 30 Aug 2004 22:49:53 -0400, Stephen torri <st...@to...> wrote: > > ------------- > > Admin Stuff > > ------------- > > To start things out I have a few administrative question: > > > > 1) Why is the ChangeLog used to list items version need to support? > > Why is the TODO file not used? The reason I ask is that the ChangeLog > > does not read like things that have changed but future things to > > change. > > hey, no! ChangeLog things HAVE been implemented! > most of them were discussed on xine-devel, and you surely can read > about all of them on the xine-cvs archives. Well the chose in words makes it read that they are to be done are not completed. The grammar of the words should be different. For example as it reading now for one line: * include goom2k4-dev18 Should be: * included goom2k4-dev18 I know its a small arguably irrelevant change but its makes all the world in how it reads. I will change those. I am particular interested in why we use the format we have. I cannot tell from this file who did what. The only way to guess is to check cvs status for the file if I can find it. CVS will keep track of who made microscopic changes to various files. I would like to suggest that the Changelog keep track of who did what when. For example: Sat Jul 31 03:16:23 2004 Stephen Torri <st...@to...> * Released 1-RC6. * - included goom2k4-dev18 support * ... more entries ... Sat Jul 31 03:15:39 2004 Stephen Torri <st...@to...> * Fixed major bug in widget #5 that cause newspapers to fly out at 80 miles/hour at a customer [SF BUG 3049509] > > 2) Have we resolved the best way for user to report bugs? Is the > > sourceforge bug tracker used? > > yes. we just need to add a link to our home page. > > btw, still talking about admin stuff... do you know php? Yes. > i'm asking because there have been some discussion on xine-docs (i can > forward it to you if you want) about planned changes to our home page. > basically, it was a matter of reworking the main entries, like adding > a "developers corner" with all information regarding developing > with/for libxine, making the testsuite public and linking to the bug > tracker and xine-users as means of reporting bugs and getting support. > imho you already fulfill two important requirements for the job: you > are a native english speaker and you have time (?)... so, do you want > this job too? ;-) I will write this down but from the sounds of things this is not a thing which will hinder the release of 1-RC6. It would certainly be helpful. To itemize your list: - "developer corner" - Documentation specific to developers. - Testsuite - Link to SF bug tracker In order for the bug tracker to be useful people will need to be reviewing it. In particular I suggest we define what are the major and minor areas of xine-lib and elect domain experts to be responsible for them. This would allow people to be the first person bugs can be assigned. > there is one show-stopper bug i'd like to fix before rc6: the blue > window problem. unfortunately i cannot reproduce it here, at first i > thought it was specific to intel video cards but now it seems matrox > is affected too when running new x.org xserver. i have no x.org to > test, but i have a G450 at home. it is difficult to debug this > problem, i will try to compile x.org but i don't want to mess with my > working system... Is it listed on the SF bug tracker? > about the release process, you should definitely read > xine-lib/doc/internal/HOWTO.release. this file contains about > everything one need to know to make a release (thanks Siggi!) I have and I am extremely thankful Siggi wrote this down. It may seem obvious to people but it helps me when my brain strips a few gears while working. I don't want to miss anything. Stephen -- Email: st...@to... |
From: Michael R. <mr...@us...> - 2004-08-31 19:24:48
|
Hi Stephen, > Well the chose in words makes it read that they are to be done are not > completed. The grammar of the words should be different. > > For example as it reading now for one line: > > * include goom2k4-dev18 > > Should be: > > * included goom2k4-dev18 Yeah, my mistake. You are right. > I know its a small arguably irrelevant change but its makes all the > world in how it reads. I will change those. Good idea. The changelog has always jumped between past and present tense. I think using past consistently makes it more clear. > I am particular interested in why we use the format we have. I cannot tell > from this file who did what. The only way to guess is to check cvs status > for the file if I can find it. > > CVS will keep track of who made microscopic changes to various files. I > would like to suggest that the Changelog keep track of who did what > when. For example: > > Sat Jul 31 03:16:23 2004 Stephen Torri <st...@to...> > > * Released 1-RC6. > * - included goom2k4-dev18 support > * ... more entries ... > > Sat Jul 31 03:15:39 2004 Stephen Torri <st...@to...> > > * Fixed major bug in widget #5 that cause newspapers to fly out > at 80 miles/hour at a customer [SF BUG 3049509] Is that really necessary? Sometimes you cannot assign a single person or a single date to these items because they are a collective effort. And I would not want the ChangeLog to report every little change that has been made but keep it as user-readable as possible. Reason: I am always scared when I look at the Linux kernel ChangeLogs... > I will write this down but from the sounds of things this is not a thing > which will hinder the release of 1-RC6. It would certainly be helpful. > > To itemize your list: > - "developer corner" > - Documentation specific to developers. > - Testsuite > - Link to SF bug tracker You can get some detail here: http://sourceforge.net/mailarchive/forum.php?thread_id=4947206&forum_id=24060 It would be really cool if you could do something about these PHP wishes. (I have some more in the queue should you get bored. ;) But I don't know any PHP unfortunately.) > In order for the bug tracker to be useful people will need to be > reviewing it. The bug tracker is already under constant surveillance. Although some bugs take some time to be nailed down, there is a falling tendency for the number of open bugs right now. This might change if we link to the tracker from xinehq, though. > In particular I suggest we define what are the major and > minor areas of xine-lib and elect domain experts to be responsible for > them. This would allow people to be the first person bugs can be > assigned. The current organization is to subscribe to xine-bugs if someone wants to help fixing bugs. This pretty much makes sure no bug gets overlooked, because you are notified there for any change to the tracker. I don't think the SF tracker allows automatic assigment of bugs. > > there is one show-stopper bug i'd like to fix before rc6: the blue > > window problem. unfortunately i cannot reproduce it here, at first i > > thought it was specific to intel video cards but now it seems matrox > > is affected too when running new x.org xserver. i have no x.org to > > test, but i have a G450 at home. it is difficult to debug this > > problem, i will try to compile x.org but i don't want to mess with my > > working system... > > Is it listed on the SF bug tracker? I don't think so, but there is plenty of material on xine-user. Just search the archive for "blue screen" if you want details. But I am confident Miguel will eventually find the cause and will give you the green light for the release. Michael -- /* Fuck me gently with a chainsaw... */ 2.0.38 /usr/src/linux/arch/sparc/kernel/ptrace.c |
From: Stephen t. <st...@to...> - 2004-08-31 20:37:31
|
On Tue, 2004-08-31 at 15:24, Michael Roitzsch wrote: > Hi Stephen, > > > Well the chose in words makes it read that they are to be done are not > > completed. The grammar of the words should be different. > > > > For example as it reading now for one line: > > > > * include goom2k4-dev18 > > > > Should be: > > > > * included goom2k4-dev18 > > Yeah, my mistake. You are right. Fixed. The changes have been applied in CVS > > I am particular interested in why we use the format we have. I cannot tell > > from this file who did what. The only way to guess is to check cvs status > > for the file if I can find it. > > > > CVS will keep track of who made microscopic changes to various files. I > > would like to suggest that the Changelog keep track of who did what > > when. For example: > > > > Sat Jul 31 03:16:23 2004 Stephen Torri <st...@to...> > > > > * Released 1-RC6. > > * - included goom2k4-dev18 support > > * ... more entries ... > > > > Sat Jul 31 03:15:39 2004 Stephen Torri <st...@to...> > > > > * Fixed major bug in widget #5 that cause newspapers to fly out > > at 80 miles/hour at a customer [SF BUG 3049509] > > Is that really necessary? Sometimes you cannot assign a single person or a > single date to these items because they are a collective effort. And I would > not want the ChangeLog to report every little change that has been made but > keep it as user-readable as possible. Reason: I am always scared when I look > at the Linux kernel ChangeLogs... Good question. How detailed should a ChangeLog file be? What I can say in an answer depends on how usable this file would be and who the user of it will be. If I am a developer with CVS access I can tell who change what file by access CVS using cvs log <filename>. Given how we use ChangeLog at present I have to hunt down which files may have been affected by a particular change. I have no guarantee unless I am intimately familiar with the fix. If I am a user considering getting involved with development and I don't have any CVS access then I am sunk. I have to hunt through the code and hope I learn what how things fit together. So I think a file that maintains the overall changes of the release should be maintained. Perhaps we can make the NEWS file contain that? While the intimate details might be considered a burdensome effort I consider it a helpful aide. For example Miguel goes rock climbing for a few weeks in Tibet to climb Everest (He might some day). He made a changes to a set of files to fix something. A user comes along and says feature X suddenly doesn't work on their system. Now I am listen on irc or xine-devl and figure I will try to help out. If I noticed that the feature was completed by reading the line in the ChangeLog I don't know who did let alone which files to start using CVS to figure what happened. I have a harder time looking at the code to help determine if a value used for a const integer was wrong. It might need be 8 instead of the 9 cause by late night programming (I've been there. A macro value is define without using its associate macro. The compiler freaks out.). So I believe a detailed set should be in the ChangeLog while the overall changes between releases could be in NEWS or RELEASE_NOTES. > > I will write this down but from the sounds of things this is not a thing > > which will hinder the release of 1-RC6. It would certainly be helpful. > > > > To itemize your list: > > - "developer corner" > > - Documentation specific to developers. > > - Testsuite > > - Link to SF bug tracker > > You can get some detail here: > http://sourceforge.net/mailarchive/forum.php?thread_id=4947206&forum_id=24060 > > It would be really cool if you could do something about these PHP wishes. > (I have some more in the queue should you get bored. ;) But I don't know any > PHP unfortunately.) I will write this into my notes. So far I see this as a "should get done" but nothing that should block 1-RC6. > > In order for the bug tracker to be useful people will need to be > > reviewing it. > > The bug tracker is already under constant surveillance. Although some bugs > take some time to be nailed down, there is a falling tendency for the number > of open bugs right now. This might change if we link to the tracker from > xinehq, though. Thanks for the information. I am human and not psyhic. Alas I cannot read minds. > > In particular I suggest we define what are the major and > > minor areas of xine-lib and elect domain experts to be responsible for > > them. This would allow people to be the first person bugs can be > > assigned. > > The current organization is to subscribe to xine-bugs if someone wants to help > fixing bugs. This pretty much makes sure no bug gets overlooked, because you > are notified there for any change to the tracker. I don't think the SF > tracker allows automatic assigment of bugs. I did know this. Thanks. I will subscribe to this list. > > > there is one show-stopper bug i'd like to fix before rc6: the blue > > > window problem. unfortunately i cannot reproduce it here, at first i > > > thought it was specific to intel video cards but now it seems matrox > > > is affected too when running new x.org xserver. i have no x.org to > > > test, but i have a G450 at home. it is difficult to debug this > > > problem, i will try to compile x.org but i don't want to mess with my > > > working system... > > > > Is it listed on the SF bug tracker? > > I don't think so, but there is plenty of material on xine-user. Just search > the archive for "blue screen" if you want details. > But I am confident Miguel will eventually find the cause and will give you the > green light for the release. I have asked Miguel when he suspects to be done. So I will await his answer. Are there any other "show stopper" bugs besides the blue screen problem? I have one janitorial duty I would like people to do. Can people double check their code and remove any compiler warnings? I got a nice long this when I did a build last night. I collected them by doing "make | grep warn". This item was on the list of things to be done for this release in the TODO file. Stephen Email: st...@to... |
From: James S. <jst...@us...> - 2004-08-31 21:35:36
|
Hi Stephen, On Tuesday 31 Aug 2004 21:37, Stephen torri wrote: > Given how we use ChangeLog at > present I have to hunt down which files may have been affected by a > particular change. I have no guarantee unless I am intimately familiar > with the fix. No, one can simply look at the archive for xine-cvslog. > If I am a user considering getting involved with development and I don't > have any CVS access then I am sunk. You could argue that a prospective developer without CVS access is sunk anyway... Besides, there is the web based cvs viewer which is actually very useful for following changes. > So I think a file that maintains the overall changes of the release > should be maintained. Perhaps we can make the NEWS file contain that? > While the intimate details might be considered a burdensome effort I > consider it a helpful aide. I think maintaining such a file will indeed be a significant burden. I for one have very little time for hacking xine these days, I'd get essentially get nothing done if I had to document every little change. > I have a harder time looking at the code to help determine if > a value used for a const integer was wrong. It might need be 8 instead > of the 9 cause by late night programming So you want this "super changelog" to document any constant values used in the code too?! Just my 2 euro-cent-pennies, James. |
From: James S. <jst...@fa...> - 2004-08-31 21:32:26
|
Hi Stephen, On Tuesday 31 Aug 2004 21:37, Stephen torri wrote: > Given how we use ChangeLog at > present I have to hunt down which files may have been affected by a > particular change. I have no guarantee unless I am intimately familiar > with the fix. No, one can simply look at the archive for xine-cvslog. > If I am a user considering getting involved with development and I don't > have any CVS access then I am sunk. You could argue that a prospective developer without CVS access is sunk anyway... Besides, there is the web based cvs viewer which is actually very useful for following changes. > So I think a file that maintains the overall changes of the release > should be maintained. Perhaps we can make the NEWS file contain that? > While the intimate details might be considered a burdensome effort I > consider it a helpful aide. I think maintaining such a file will indeed be a significant burden. I for one have very little time for hacking xine these days, I'd get essentially get nothing done if I had to document every little change. > I have a harder time looking at the code to help determine if > a value used for a const integer was wrong. It might need be 8 instead > of the 9 cause by late night programming So you want this "super changelog" to document any constant values used in the code too?! Just my 2 euro-cent-pennies, James. |
From: Stephen t. <st...@to...> - 2004-08-31 23:53:11
|
On Tue, 2004-08-31 at 17:32, James Stembridge wrote: > > So I think a file that maintains the overall changes of the release > > should be maintained. Perhaps we can make the NEWS file contain that? > > While the intimate details might be considered a burdensome effort I > > consider it a helpful aide. > > I think maintaining such a file will indeed be a significant burden. I for one > have very little time for hacking xine these days, I'd get essentially get > nothing done if I had to document every little change. There certainly is a trade off here. Too little of documented changes its hard to follow what changes. Too much and people spend more time documenting than developing. > > I have a harder time looking at the code to help determine if > > a value used for a const integer was wrong. It might need be 8 instead > > of the 9 cause by late night programming > > So you want this "super changelog" to document any constant values used in the > code too?! No. I gave the numbers as an example of things that would not stop a program compiling but would hinder its operation. The example was given to as an example of a possible (alright imaginary) example of how little information one developer of xine has from others. I just don't want to have a situation where if one person is a way no can fix a problem. Also I desire to empower new programmers. Stephen -- Email: st...@to... |
From: Miguel F. <mfr...@gm...> - 2004-09-01 18:53:22
|
Hi Stephen, On Tue, 31 Aug 2004 19:53:23 -0400, Stephen torri <st...@to...> wrote: > No. I gave the numbers as an example of things that would not stop a > program compiling but would hinder its operation. The example was given > to as an example of a possible (alright imaginary) example of how little > information one developer of xine has from others. I just don't want to > have a situation where if one person is a way no can fix a problem. Also > I desire to empower new programmers. I share your concerns. Fortunately, there is now group of people that knows the whole project quite well, and several other developers who know a lot from particular areas. To empower the new programmers, i believe the most important thing is making sure our site has some good and well organized resources, including API information, links to other language bindings (like python) and sample code. Still, I don't think the Changelog has anything to do with the information one developer has from another. the most important changes are usually discussed here and cvs messages we put while committing play a *very* important role on documenting the changes. The Changelog is mostly meant to be readable by xine users. cvsweb interface is quite efficient, imho, for checking what exactly was changed and why. regards, Miguel PS: I have compiled x.org but i still need to test it at home. I can't reproduce the blue window problem using a nvidia card i have at work. I hope the problem will show with the G450. |
From: Miguel F. <mfr...@gm...> - 2004-09-02 10:02:34
|
On Wed, 1 Sep 2004 15:53:16 -0300, Miguel Freitas <mfr...@gm...> wrote: > PS: I have compiled x.org but i still need to test it at home. I can't > reproduce the blue window problem using a nvidia card i have at work. > I hope the problem will show with the G450. update: I installed x.org but still could not reproduce the blue window problem. it seems we will depend on users with this problem to test patches and debug it. i will check the cvsweb once again if something gets my attention but i'm still pretty clueless on what might be going on... regards, Miguel |
From: <va...@us...> - 2004-08-31 20:38:39
|
Hi Stephen, V =C3=9At, 31. 08. 2004 v 04:49, Stephen torri p=C3=AD=C5=A1e: > Here is a list of things that I gleaned from the TODO and the > ChangeLog that we are trying to provide. I need help distinguishing > which are doable for this release and what should be put off for 1-rc7 > or 1.0. For each one I am trying to understand what their status is, > how much longer it will take (education guess) to complete and whether > its a show-stopper for 1-rc6. >=20 > * Translations are done: >=20 > Status: UNKNOWN > Time required: UNKNOWN > 1-rc6 Stopper: UNKNOWN >=20 > Languages supported and translator: >=20 > Czech: Frantisek Dvorak > German: Philip Hahn > Spanish: Juan Manuel GarcA a Molina > French: Daniel Caujolle-Bert > Italian: Giovanni Venturi > Polish: Bartaomiej Muryn > Portuguese (Brazilian): Marcelo Roberto Jimenez > Slovak: ? >=20 > NOTE: I would appreciate to know what the status of > their respective translations is. >=20 I recently commited Czech translation. It's only cca. 80% of translated text, the remain I'll tranlsate later. Btw. percentage status of all translations should be displayed during 'make dist'. Cheers, Frantisek |
From: Stephen t. <st...@to...> - 2004-08-31 20:53:49
|
On Tue, 2004-08-31 at 16:41, Franti=B9ek Dvo=F8=E1k wrote: > >=20 > > Czech: Frantisek Dvorak > I recently commited Czech translation. It's only cca. 80% of translated > text, the remain I'll tranlsate later. When is later? > Btw. percentage status of all translations should be displayed during > 'make dist'. Any ideas on doing this? I have not looked into do translations to quote the Fifth Element "I only know English and Bad English". Stephen --=20 Email: st...@to... |
From: <va...@us...> - 2004-08-31 21:03:23
|
V =C3=9At, 31. 08. 2004 v 22:53, Stephen torri p=C3=AD=C5=A1e: > On Tue, 2004-08-31 at 16:41, Franti=C5=A1ek Dvo=C5=99=C3=A1k wrote: > > >=20 > > > Czech: Frantisek Dvorak >=20 > > I recently commited Czech translation. It's only cca. 80% of translat= ed > > text, the remain I'll tranlsate later. >=20 > When is later? >=20 I think this is not show stopper. I plan it after release... > > Btw. percentage status of all translations should be displayed during > > 'make dist'. >=20 > Any ideas on doing this? I have not looked into do translations to quot= e > the Fifth Element "I only know English and Bad English". >=20 Sorry, this was misunderstood, I'm not English native. I meant "percentage status IS displayed during 'make dist'". :-) Cheers, Frantisek |
From: Michael R. <mr...@us...> - 2004-08-31 21:28:32
|
Hi, > > Btw. percentage status of all translations should be displayed during > > 'make dist'. > > Any ideas on doing this? I also saw KDE's Konqueror displaying the translation ratio in the tooltip when hovering over a .po file. (even with a nice diagram!) But it doesn't work here, so I guess one has to install some add-on for this. Michael -- "This vulnerability is completely theoretical!" -Microsoft |
From: Michael R. <mr...@us...> - 2004-08-31 21:17:02
|
Hi Stephen, > > Yeah, my mistake. You are right. > > Fixed. The changes have been applied in CVS Thanks. > > > Sat Jul 31 03:15:39 2004 Stephen Torri <st...@to...> > > > > > > * Fixed major bug in widget #5 that cause newspapers to fly out > > > at 80 miles/hour at a customer [SF BUG 3049509] > > > > Is that really necessary? Sometimes you cannot assign a single person or > > a single date to these items because they are a collective effort. And I > > would not want the ChangeLog to report every little change that has been > > made but keep it as user-readable as possible. Reason: I am always scared > > when I look at the Linux kernel ChangeLogs... > > Good question. How detailed should a ChangeLog file be? What I can say > in an answer depends on how usable this file would be and who the user > of it will be. > > If I am a developer with CVS access I can tell who change what file by > access CVS using cvs log <filename>. Given how we use ChangeLog at > present I have to hunt down which files may have been affected by a > particular change. I have no guarantee unless I am intimately familiar > with the fix. > > If I am a user considering getting involved with development and I don't > have any CVS access then I am sunk. I have to hunt through the code and > hope I learn what how things fit together. You always have WebCVS and the xine-cvslog mailing list. If you want to know the files that changed, a quick search on this list should bring you up to date. > So I think a file that maintains the overall changes of the release > should be maintained. Perhaps we can make the NEWS file contain that? > While the intimate details might be considered a burdensome effort I > consider it a helpful aide. But I think this task should be automated and until now I thought CVS and the cvslog list did quite enough automation. > > You can get some detail here: > > http://sourceforge.net/mailarchive/forum.php?thread_id=4947206&forum_id=2 > >4060 > > > > It would be really cool if you could do something about these PHP wishes. > > (I have some more in the queue should you get bored. ;) But I don't know > > any PHP unfortunately.) > > I will write this into my notes. So far I see this as a "should get > done" but nothing that should block 1-RC6. Absolutely. > > > In order for the bug tracker to be useful people will need to be > > > reviewing it. > > > > The bug tracker is already under constant surveillance. Although some > > bugs take some time to be nailed down, there is a falling tendency for > > the number of open bugs right now. This might change if we link to the > > tracker from xinehq, though. > > Thanks for the information. I am human and not psyhic. Alas I cannot > read minds. Noone expects that. :) > Are there any other "show stopper" bugs besides the blue screen problem? Not to my knowledge. But I just remembered the buffer overflow fixes that accumulated in CVS. I think I (or someone else who wants the job) should write a security advisory, since rc6 will fix these. I will go over the patches and propose something, but I cannot do this before Friday, since I have an important exam on Thursday. But expect this to be done till the weekend. > I have one janitorial duty I would like people to do. Can people double > check their code and remove any compiler warnings? I got a nice long > this when I did a build last night. I collected them by doing "make | > grep warn". This item was on the list of things to be done for this > release in the TODO file. I regularly do a "make clean all install 2> warnings.log" and check the log. All warnings listed there are either unfixable right now (libtool and automake warnings) or are in non-xine code (vidix is the most prominent one here). With my compiler (gcc 3.3.2), I get no warnings in native xine code and only a few in total. I think we can consider the warning item done. Michael -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c |
From: Drew 'd. O. <dan...@um...> - 2004-09-02 15:16:53
|
Miguel Freitas wrote: > >I share your concerns. Fortunately, there is now group of people that >knows the whole project quite well, and several other developers who >know a lot from particular areas. To empower the new programmers, i >believe the most important thing is making sure our site has some good >and well organized resources, including API information, links to >other language bindings (like python) and sample code. > > > I would put forward the suggestion that a certain level of documentation be a requirement for xine-lib 1-final -dante |
From: Stephen t. <st...@to...> - 2004-09-02 15:56:33
|
On Thu, 2004-09-02 at 11:16, Drew 'dantealiegri' Ogle wrote: > Miguel Freitas wrote: > > > > >I share your concerns. Fortunately, there is now group of people that > >knows the whole project quite well, and several other developers who > >know a lot from particular areas. To empower the new programmers, i > >believe the most important thing is making sure our site has some good > >and well organized resources, including API information, links to > >other language bindings (like python) and sample code. > > > > > > > I would put forward the suggestion that a certain level of documentation > be a requirement for xine-lib 1-final Ok. What would we document? Let's prepare a list: - Documents specific to developers - xine-lib framework & diagrams - xine-lib interfaces - xine-lib testsuite Anymore? Stephen -- Email: st...@to... |
From: Bruce R'. M. <br...@yo...> - 2004-09-02 17:14:44
|
On Thursday 02 September 2004 08:56, Stephen torri wrote: > On Thu, 2004-09-02 at 11:16, Drew 'dantealiegri' Ogle wrote: > > I would put forward the suggestion that a certain level of documentation > > be a requirement for xine-lib 1-final > > Ok. What would we document? Let's prepare a list: I've been playing around with implementing slow reverse lately. The Hacker's Guide was helpfull for describing the individual 'classes' (input, demux, decode, etc...) in isolation but it was a little vague on the way that the classes interacted. I had trouble figuring out who was driving the flow of frames. It would have been helpfull for the Guide to tell the longitudinal story of the life of a single MPEG2 B-frame from being read off of the disk, chunked together by the demuxer, waiting in the decoder for the relevant I and P frames, being queued to the vo and stalling for the metronome, and finally being rendered at exactly the right time by, say, Xv. You could add another chapter called "Billy the B-frame Goes to the Movies". -b |
From: <va...@us...> - 2004-09-02 20:01:05
|
Hi team, V =C3=9At, 31. 08. 2004 v 23:16, Michael Roitzsch p=C3=AD=C5=A1e: > > I have one janitorial duty I would like people to do. Can people doub= le > > check their code and remove any compiler warnings? I got a nice long > > this when I did a build last night. I collected them by doing "make | > > grep warn". This item was on the list of things to be done for this > > release in the TODO file. >=20 > I regularly do a "make clean all install 2> warnings.log" and check the= log. > All warnings listed there are either unfixable right now (libtool and a= utomake=20 > warnings) or are in non-xine code (vidix is the most prominent one here= ).=20 > With my compiler (gcc 3.3.2), I get no warnings in native xine code and= only=20 > a few in total. I think we can consider the warning item done. >=20 What about warning "use of cast expressions as lvalues is deprecated"? I guess it's in category 'unfixable right now'. I fixed several warnings on WIN32 platform, but some remain. One is due to GUID - WIN32 API has non-portable GUID struct (using unsigned long instead uint32_t) which cause one warning in demux_asf.c. I would let it there. And more important: We print file offsets (off_t) and thread (pthread_t), so maybe we would need some formating string for it. off_t differs on various systems and configurations and in MINGW32 it's only 32-bit. Cheers, Frantisek |
From: Bruce R'. M. <br...@yo...> - 2004-09-02 21:50:20
|
On Thursday 02 September 2004 13:03, Franti=C5=A1ek Dvo=C5=99=C3=A1k wrote: > What about warning "use of cast expressions as lvalues is deprecated"? I > guess it's in category 'unfixable right now'. A couple of weeks ago I build xine with g++ (not gcc) v3.4.0 and this was t= he=20 main problem I came across. It was easy enough to fix by declaring a point= er=20 of the appropriate type. I can generate some diffs if you guys are=20 interested. Compiling with c++ really flushes out questionable code. =2Db |
From: Michael R. <mr...@us...> - 2004-09-03 13:39:14
|
Hi, > > What about warning "use of cast expressions as lvalues is deprecated"? I > > guess it's in category 'unfixable right now'. > > A couple of weeks ago I build xine with g++ (not gcc) v3.4.0 and this was > the main problem I came across. It was easy enough to fix by declaring a > pointer of the appropriate type. I can generate some diffs if you guys are > interested. Compiling with c++ really flushes out questionable code. Patches would be really welcome. Thanks for your efforts. Michael -- The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying. |
From: Michael R. <mr...@us...> - 2004-09-03 13:38:39
|
Hi Frantisek, > > I regularly do a "make clean all install 2> warnings.log" and check the > > log. All warnings listed there are either unfixable right now (libtool > > and automake warnings) or are in non-xine code (vidix is the most > > prominent one here). With my compiler (gcc 3.3.2), I get no warnings in > > native xine code and only a few in total. I think we can consider the > > warning item done. > > What about warning "use of cast expressions as lvalues is deprecated"? I > guess it's in category 'unfixable right now'. My compiler does not emit these. Michael -- Never trust a programmer who is carrying a screwdriver. |
From: Dave D. <do...@do...> - 2004-09-02 20:36:01
|
On Thu, Sep 02, 2004 at 10:03:07PM +0200, Franti?ek Dvo?ák wrote: > And more important: We print file offsets (off_t) and thread > (pthread_t), so maybe we would need some formating string for it. off_t > differs on various systems and configurations and in MINGW32 it's only > 32-bit. On Linux/glibc, for example, sizeof(off_t) can change depending on the compilation flags. One option would be to cast the value to uintmax_t and then use the PRIuMAX conversion from <inttypes.h>. Regarding pthread_t: according to the Single Unix Specification it can legally be a struct type. From the <sys/types.h> footnotes: IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/26 is applied, adding pthread_t to the list of types that are not required to be arithmetic types, thus allowing pthread_t to be defined as a structure. -Dave Dodge |
From: <va...@us...> - 2004-09-16 17:30:03
Attachments:
lib_w32warns.diff
|
Hi Dave, V =C4=8Ct, 02. 09. 2004 v 22:44, Dave Dodge p=C3=AD=C5=A1e: > On Thu, Sep 02, 2004 at 10:03:07PM +0200, Franti?ek Dvo?=C3=A1k wrote: > > And more important: We print file offsets (off_t) and thread > > (pthread_t), so maybe we would need some formating string for it. off= _t > > differs on various systems and configurations and in MINGW32 it's onl= y > > 32-bit. >=20 > On Linux/glibc, for example, sizeof(off_t) can change depending on the > compilation flags. One option would be to cast the value to uintmax_t > and then use the PRIuMAX conversion from <inttypes.h>. >=20 Good idea. I think this way is only simple solution. I send here a patch (compilation is OK but I didn't test it in action). I used signed type for off_t. Cheers, Frantisek |
From: Drew O. <og...@um...> - 2004-09-02 15:16:50
|
Miguel Freitas wrote: > >I share your concerns. Fortunately, there is now group of people that >knows the whole project quite well, and several other developers who >know a lot from particular areas. To empower the new programmers, i >believe the most important thing is making sure our site has some good >and well organized resources, including API information, links to >other language bindings (like python) and sample code. > > > I would put forward the suggestion that a certain level of documentation be a requirement for xine-lib 1-final -dante |