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 |