September 2005 - Wine-Devel

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

by Phil Krylov

Hi Michael, On Thu, 8 Sep 2005 23:10:18 +0200 Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > Wouldn't it be enough to call notify_click after notify_itemactivate? I've > attached a modification of your patch, which does just this. Seems to work > fine for me. Probably, but what if some apps depend on order in which these notifications are sent? (assuming we already send them in the right order) -- Ph.

Sept. 8, 2005

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

by Michael Jung

Hello Dimi, On Thursday 08 September 2005 23:37, Phil Krylov wrote: > Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > > Wouldn't it be enough to call notify_click after notify_itemactivate? > > I've attached a modification of your patch, which does just this. Seems > > to work fine for me. > > Probably, but what if some apps depend on order in which these > notifications are sent? (assuming we already send them in the right order) It seems that the code in it's current form was written by you: http://cvs.winehq.org/cvsweb/wine/dlls/comctl32/listview.c.diff?r1=1.204&r2… Do you see a problem to move the notify_click below the notify_itemactivate? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Sept. 8, 2005

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

by Michael Jung

Hi Phil, On Thursday 08 September 2005 19:23, Phil Krylov wrote: > * Every double click on a folder in the listview destroys this listview > object (effectively destroying all underlying structures), creates a new > one, and returns control to the place where double click notification was > sent by the old listview (notify_hdr() function in listview.c). This time > the old listview and its structures are already destroyed, but we > continue to access them, exception! Thanks a lot, that really saved my day. I've spend some hours chasing this bug already, but to no avail. > Here is a patch which adds checking if the window has been destroyed at > that point. I don't know if it is acceptable but it fixes the problem. Wouldn't it be enough to call notify_click after notify_itemactivate? I've attached a modification of your patch, which does just this. Seems to work fine for me. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Sept. 8, 2005

Re: Spam in wine-announce?

by Jeremy Newman

I'll delete it from the archives. Always hate it when this happens. :-( On Thu, 2005-09-08 at 20:52 +0100, Ivan Leo Puoti wrote: > Anssi Hannula wrote: > > This just came in from wine-announce list. > > Seen it too, I've already sent a report to the admin who's network originated it. > > Ivan. > > >

Sept. 8, 2005

Re: Empire Earth continued

by Stefan Dösinger

Am Donnerstag, 8. September 2005 22:03 schrieb Lionel Ulmer: > On Thu, Sep 08, 2005 at 09:20:39PM +0200, Stefan Dösinger wrote: > > Do you mean on Windows or on Wine? How can I get these members from an > > external application? I thought that apps can't look inside a COM object, > > as the structures used by the libs and the structures exported to the app > > are different. > > Well, just do an 'AddRef' which returns the (now incremented) reference > count and then a Release. If you print the returned value minus one, you > will get the current reference count at the moment of the call. I think you're right. After Releasing the DDraw object two times, as EE does, it's far from beeing freed: It has a refcount of 8!! In particular, creating the surface and performing QueryInterface on it increase the refcount by 1, creating a D3D device increases the refcount by 7. I'll do more tests. Stefan

Sept. 8, 2005

Re: Empire Earth continued

by Lionel Ulmer

On Thu, Sep 08, 2005 at 09:20:39PM +0200, Stefan Dösinger wrote: > Do you mean on Windows or on Wine? How can I get these members from an > external application? I thought that apps can't look inside a COM object, as > the structures used by the libs and the structures exported to the app are > different. Well, just do an 'AddRef' which returns the (now incremented) reference count and then a Release. If you print the returned value minus one, you will get the current reference count at the moment of the call. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Sept. 8, 2005

Re: Empire Earth continued

by Oliver Stieber

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > > Yeah, I suspected that the problem was in the 'force destroy' code. Could > > you change your test script to get the reference count of the 'complex' > > object before release of the DDraw object and after ? Could you do the same > > for the 'normal' objects (mostly before as after it will crash :-) ) ? > Do you mean on Windows or on Wine? How can I get these members from an > external application? I thought that apps can't look inside a COM object, as > the structures used by the libs and the structures exported to the app are > different. > > Well, on the Wine side, I can hack on these thing, but on Windows? > You should be able to do an AddRef + Release ref. Oliver. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Sept. 8, 2005

Re: dll/winmm/playsound.c

by Ulrich Czekalla

fccType is type FOURCC which is a DWORD. /Ulrich On Thu, Sep 08, 2005 at 11:28:56AM -0500, Robert Shearman wrote: > I think these formats should be %04x as fccType is 2 bytes, not 4 bytes.

Sept. 8, 2005

Re: Spam in wine-announce?

by Ivan Leo Puoti

Anssi Hannula wrote: > This just came in from wine-announce list. Seen it too, I've already sent a report to the admin who's network originated it. Ivan.

Sept. 8, 2005

Re: Empire Earth continued

by Stefan Dösinger

Hi, > Yeah, I suspected that the problem was in the 'force destroy' code. Could > you change your test script to get the reference count of the 'complex' > object before release of the DDraw object and after ? Could you do the same > for the 'normal' objects (mostly before as after it will crash :-) ) ? Do you mean on Windows or on Wine? How can I get these members from an external application? I thought that apps can't look inside a COM object, as the structures used by the libs and the structures exported to the app are different. Well, on the Wine side, I can hack on these thing, but on Windows?

Sept. 8, 2005

Spam in wine-announce?

by Anssi Hannula

This just came in from wine-announce list. -- Anssi Hannula julliard(a)winehq.com wrote: > Warning: This message has had one or more attachments removed > Warning: (document.txt .scr, document.zip). > Warning: Please read the "yoursite-Attachment-Warning.txt" attachment(s) for more information. > > Here are your banks documents. > > > > ------------------------------------------------------------------------ > > This is a message from the MailScanner E-Mail Virus Protection Service > ---------------------------------------------------------------------- > The original e-mail attachment "document.zip" > was believed to be infected by a virus and has been replaced by this warning > message. > > If you wish to receive a copy of the *infected* attachment, please > e-mail helpdesk and include the whole of this message > in your request. Alternatively, you can call them, with > the contents of this message to hand when you call. > > At Thu Sep 8 11:27:12 2005 the virus scanner said: > ClamAV: document.txt .scr contains Worm.Mytob.H-1 > MailScanner: Windows Screensavers are often used to hide viruses (document.txt .scr) > > Note to Help Desk: Look on the yoursite MailScanner in /var/spool/MailScanner/quarantine/20050908 (message j88GR1Ks012044).

Sept. 8, 2005

Re: Empire Earth continued

by Lionel Ulmer

> Wine releases the surface in 5), Windows doesn't. It appears to me, that > Windows doesn't release Surfaces which have a D3D object attached when the > DDraw instance they belong to is freed. Yeah, I suspected that the problem was in the 'force destroy' code. Could you change your test script to get the reference count of the 'complex' object before release of the DDraw object and after ? Could you do the same for the 'normal' objects (mostly before as after it will crash :-) ) ? After that, it's always a bit tricky to test stuff like this as non-crashing is not a definite proof that the object was not actually destroyed... Lionel -- Lionel Ulmer - http://www.bbrox.org/

Sept. 8, 2005

Re: Need ideas about ntoskrnl (WITH ideas)

by Damjan Jovanovic

--- Mike McCormack <mike(a)codeweavers.com> wrote: > > Damjan Jovanovic wrote: > > > Using int 0x2e and other Linux-specific hacks like > > kernel modules, limits portability of Wine, you'll > > never get it working on Windows itself. > > I have no idea why you'd want to port Wine back to > Windows to use > Windows device drivers. What if you want to run Windows XP apps on Windows 98? I used a bad example, any non-Linux OS (FreeBSD, MacOS, ReactOS) would have the same problem. > > 4. TYPED HANDLES > > ---------------- > > Modify HANDLE to somehow store handle type, or > else function pointers to functions used on handles, > like reading, writing and ioctl's. NTDLL functions > like NtWriteFile(), NtReadFile() and > NtDeviceIoControlFile() should use the handle type > to demultiplex the I/O request to the correct > function. So for example when > NtDeviceIoControlFile() is called on a handle of > type (say) WINE_HANDLE_USB_SCAN, the function > UsbScanDeviceIoControl() is called, when it's called > on a handle of type WINE_HANDLE_CDROM then > CDROM_DeviceIoControl() is called. It would help too > if some generic data (eg. void*) could be associated > with each handle, so code managing a handle family > could store some internal data there. > > Personally I advise: > > struct HandleData { > > VOID (*Close)(HANDLE handle); > > DWORD (*Ioctl)(HANDLE handle, /* Other > DeviceIoControl() parameters */); > > DWORD (*Read)(HANDLE handle, LPVOID *buffer, > DWORD size); > > DWORD (*Write)(HANDLE handle, LPVOID *buffer, > DWORD size); > > VOID *internalData; > > }; > > #define HANDLE_TO_HandleData(h) ... > > Wine used to have function call tables like this > about 5 years, and > typed handles about a year ago. Those things have > been removed on purpose. > > You can't store function pointers in the wineserver, > as each process may > have those functions at a different address. You could store arbitrary pointers, usable from wine itself. > It looks like Alexandre has made the design decision > to live with a file > handle mapping to a single Unix file descriptor a > while back. That > makes things difficult for people who want to write > code to load and use > device drivers in any consistent fashion. Thus our problems arose. > Mike > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Sept. 8, 2005

Re: appdb developers please read

by Tom Wickline

On 9/8/05, James Hawkins <truiken(a)gmail.com> wrote: > On 9/8/05, Tom Wickline <twickline(a)gmail.com> wrote: > > > > 1) send a patch > > 2) wait five days for a commit > > 3) re-submit after five days has passed > > 4) if the patch still isn't committed after two days ask why. > > > > 7 days is a long time to wait for an explanation of why a patch wasn't > committed. The only reason why I said 7 days was you need to take week ends, days off, holidays, your position in the Que and so on into account. So maybe seven days is a bit long but I'm sure if someone here said two days someone would scream if two days went by and there patch wasn't committed when it might have been on the third.. I agree with the other commits you made. Tom > -- > James Hawkins >

Sept. 8, 2005

Re: appdb developers please read

by James Hawkins

On 9/8/05, Tom Wickline <twickline(a)gmail.com> wrote: > > 1) send a patch > 2) wait five days for a commit > 3) re-submit after five days has passed > 4) if the patch still isn't committed after two days ask why. > 7 days is a long time to wait for an explanation of why a patch wasn't committed. I usually wait a day, resubmit the patch asking why it wasn't accepted. One of the biggest problems we have is one of responsibility. It's easy to become dependent on Alexandre to tell us why each of our patches is not acceptable (I'm guilty of this too). More responsibility should be shifted from Alexandre to the developers when it comes to examining submitted patches. If a patch is not accepted, the developer that sent the patch in (and even other developers) should review the patch and try to see what is wrong with it. Put yourself in Alexandre's shoes and think why he would reject it. Granted it isn't always possible to know why a patch was rejected (design issue maybe), but if more time was spent reviewing our own patches (before and after submission), I don't think this would be as big of an issue. You have to keep in mind that Alexandre has a lot more work to do then reviewing and committing patches, and it isn't his job to make our patches correct. -- James Hawkins

Sept. 8, 2005

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

by Phil Krylov

On Fri, 26 Aug 2005 23:03:33 +0200 Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > Every time you double click a folder, the current ShellView object is > destroyed and a new one is created. Given that I have to browse into like 30 > different folders before it crashes on me, I can't pin down the relevant > infoPtr. In hunt for this bug, I discovered the following: * It appears both with unixfs and normal Wine fs. * Every double click on a folder in the listview destroys this listview object (effectively destroying all underlying structures), creates a new one, and returns control to the place where double click notification was sent by the old listview (notify_hdr() function in listview.c). This time the old listview and its structures are already destroyed, but we continue to access them, exception! Here is a patch which adds checking if the window has been destroyed at that point. I don't know if it is acceptable but it fixes the problem. ChangeLog: Protect against wrong memory access if a listview is destroyed in a handler for its NM_DBLCLK notification. -- Ph.

Sept. 8, 2005

Re: wineserver keeps running after wine exits

by Alexandre Julliard

"ivan vadoviè" <pivo(a)pobox.sk> writes: > So, wine exits, but wineserver keeps running and finishes a second or two > later. As a result it rewrites the config files AFTER the command completion. > That confuses scripts reading and manipulating the registers. Well, it confuses > wine too, if I try to run wine immediately after exiting wine. > > Is that on purpose? Is there any workaround? Am I doing something wrong here? Yes, it's on purpose. You can reduce the timeout by using the -p option to wineserver, but there will be a race in any case. You really shouldn't be manipulating the registry files directly, you should call regedit from your scripts. And running wine immediately after exiting should work fine, could you please give details on what doesn't work? -- Alexandre Julliard julliard(a)winehq.org

Sept. 8, 2005

Re: Empire Earth continued

by Stefan Dösinger

Am Donnerstag, 8. September 2005 18:24 schrieb Oliver Stieber: > --- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Hi, > > I think I've found the cause of the Empire Earth crash. This is not a > > reference counting problem at all, Empire Earth releases the DirectDraw > > and Surface objects on purpose. This is what happens: > > > > 1) EE creates a DDraw object > > 2) It attaches a Complex Surface > > 3) It sets up a D3D device for this Surface > > 4) EE performs a Flip(NULL, 0x20) on the surface > > 5) It Releases the DirectDraw object > > 6) It Releases the surface > > > > Wine releases the surface in 5), Windows doesn't. It appears to me, that > > Windows doesn't release Surfaces which have a D3D object attached when > > the DDraw instance they belong to is freed. > > > > I have written a small test app, which reproduces EEs behaviour. It > > crashes in Wine, but worksin Windows 2000. I'll do some more tests and > > submit a patch. > > by the sound of things an internal reference is missing, up until 6 a > reference should be kept, preventing the surface from being released at 5. No, Wine frees all Surfaces attached to a DDraw object once the DDraw object is freed, no matter how many references the Surface has. Windows does the same for normal surfaces(I checked it), but as it looks not for D3D Surfaces. If the surface doesn't have a D3D object attached, the above combination leeds to a crash even in Windows. >From the log: 0009:trace:ddraw:Main_DirectDraw_Release (0x7fe00430)->() decrementing from 2. 0009:trace:ddraw:Main_DirectDraw_Release (0x7fe00430)->() decrementing from 1. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x5e52f958 with refcnt 2 0009:trace:ddraw:gltex_final_release deleting texture with GL id 0. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x5e535ba8 with refcnt 2 0009:trace:ddraw:gltex_final_release deleting texture with GL id 0. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x5e535680 with refcnt 2 0009:trace:ddraw:gltex_final_release deleting texture with GL id 0. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x5e5352e0 with refcnt 2 0009:trace:ddraw:gltex_final_release deleting texture with GL id 0. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x5e54fb00 with refcnt 2 0009:trace:ddraw:gltex_final_release deleting texture with GL id 0. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x5e54f5d8 with refcnt 2 0009:trace:ddraw:gltex_final_release deleting texture with GL id 0. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x5e5650d8 with refcnt 2 0009:trace:ddraw:gltex_final_release deleting texture with GL id 0. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x5e564bb0 with refcnt 1 0009:trace:ddraw:gltex_final_release deleting texture with GL id 0. 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x7fe04738 with refcnt 2 0009:trace:ddraw:DIB_DirectDrawSurface_free_dc Releasing DC for surface: 0x7fe04738 0009:warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x7fe04398 with refcnt 1 0009:trace:ddraw:User_DirectDrawSurface_final_release waiting for update thread to terminate... 0009:trace:ddraw:User_DirectDrawSurface_final_release update thread terminated 0009:trace:ddraw:DIB_DirectDrawSurface_free_dc Releasing DC for surface: 0x7fe04398 0009:trace:ddraw:Main_DirectDraw_Release (0x7fe000e0)->() decrementing from 1. wine: Unhandled exception (thread 0009), starting debugger... ->Crash due to Releasing a surface attached to DDraw 0x7fe00430 There are a lot of surfaces attached, which are destroyed, and only the Complex surface with the D3D object should survive. Empire Earth also doesn't touch the other surfaces any more. It's also fine that EE releases the DDraw instance here. It perfoms a lot of checks on a lot of things, and it initialises numerous DDraw objects, Surfaces and D3D objects and Releases them again to check if they are working. Stefan

Sept. 8, 2005

Re: appdb developers please read

by Tom Wickline

On 9/8/05, Ivan Leo Puoti <ivanleo(a)gmail.com> wrote: > We don't need that, it's not much better than what we've got and isn't > worth the effort, what is needed is something that Alexandre can use. > New patches are "New", committed patched are "committed" and rejected > patches are marked as "rejected, reason:" so people can know what is and > isn't committed and why as soon as Alexandre makes that decision. All of this comes down to one simple thing... "Communication Overhead" And the way I see it AJ would soon go from hacking and committing patches to explaining why every dropped patch was dropped. So the question at the end of the day comes down to this, do we want AJ working on hacking/committing or sending reasons why patches dont get applied? There are only 24 hours in a day and I believe the current system is the most productive. 1) send a patch 2) wait five days for a commit 3) re-submit after five days has passed 4) if the patch still isn't committed after two days ask why. This gives everyone who is interested a week to review/test the patch in question. Tom > Ivan. > > >

Sept. 8, 2005

Re: dll/winmm/playsound.c

by Robert Shearman

Ulrich Czekalla wrote: >fccType may be NULL or contain non-printable characters. Show output as hex >instead of characters. > >ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Display fccType as hex instead of characters in trace output > > >------------------------------------------------------------------------ > >Index: dlls/winmm/playsound.c >=================================================================== >RCS file: /home/wine/wine/dlls/winmm/playsound.c,v >retrieving revision 1.17 >diff -u -p -r1.17 playsound.c >--- dlls/winmm/playsound.c 13 Jul 2005 11:59:15 -0000 1.17 >+++ dlls/winmm/playsound.c 8 Sep 2005 14:42:09 -0000 >@@ -328,7 +328,7 @@ static DWORD WINAPI proc_PlaySound(LPVOI > if (mmioDescend(hmmio, &mmckInfo, &ckMainRIFF, MMIO_FINDCHUNK)) > goto errCleanUp; > >- TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX \n", >+ TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX \n", > (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); > > lpWaveFormat = HeapAlloc(GetProcessHeap(), 0, mmckInfo.cksize); >@@ -349,7 +349,7 @@ static DWORD WINAPI proc_PlaySound(LPVOI > if (mmioDescend(hmmio, &mmckInfo, &ckMainRIFF, MMIO_FINDCHUNK)) > goto errCleanUp; > >- TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX\n", >+ TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX\n", > (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); > > I think these formats should be %04x as fccType is 2 bytes, not 4 bytes. -- Rob Shearman

Sept. 8, 2005

Re: Empire Earth continued

by Oliver Stieber

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > I think I've found the cause of the Empire Earth crash. This is not a > reference counting problem at all, Empire Earth releases the DirectDraw and > Surface objects on purpose. This is what happens: > > 1) EE creates a DDraw object > 2) It attaches a Complex Surface > 3) It sets up a D3D device for this Surface > 4) EE performs a Flip(NULL, 0x20) on the surface > 5) It Releases the DirectDraw object > 6) It Releases the surface > > Wine releases the surface in 5), Windows doesn't. It appears to me, that > Windows doesn't release Surfaces which have a D3D object attached when the > DDraw instance they belong to is freed. > > I have written a small test app, which reproduces EEs behaviour. It crashes in > Wine, but worksin Windows 2000. I'll do some more tests and submit a patch. > by the sound of things an internal reference is missing, up until 6 a reference should be kept, preventing the surface from being released at 5. Oliver. > Stefan > > > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Sept. 8, 2005

wineserver keeps running after wine exits

by ivan vadovič

Hi, This is what's going on using wine-20050725 and 20050830 under gentoo: $ ls -l user.reg; wine winecfg; ls -l user.reg # winecfg did some changes ... 7517 Sep 2 16:00 user.reg ... 7517 Sep 2 16:00 user.reg $ sleep 5 $ ls -l user.reg ... 7629 Sep 2 16:13 user.reg So, wine exits, but wineserver keeps running and finishes a second or two later. As a result it rewrites the config files AFTER the command completion. That confuses scripts reading and manipulating the registers. Well, it confuses wine too, if I try to run wine immediately after exiting wine. Is that on purpose? Is there any workaround? Am I doing something wrong here? Ivan

Sept. 8, 2005

Empire Earth continued

by Stefan Dösinger

Hi, I think I've found the cause of the Empire Earth crash. This is not a reference counting problem at all, Empire Earth releases the DirectDraw and Surface objects on purpose. This is what happens: 1) EE creates a DDraw object 2) It attaches a Complex Surface 3) It sets up a D3D device for this Surface 4) EE performs a Flip(NULL, 0x20) on the surface 5) It Releases the DirectDraw object 6) It Releases the surface Wine releases the surface in 5), Windows doesn't. It appears to me, that Windows doesn't release Surfaces which have a D3D object attached when the DDraw instance they belong to is freed. I have written a small test app, which reproduces EEs behaviour. It crashes in Wine, but worksin Windows 2000. I'll do some more tests and submit a patch. Stefan

Sept. 8, 2005

Re: appdb developers please read

by Ivan Leo Puoti

Francois Gouget wrote: > > Also it would not require disrupting Alexandre's routine or having him > do extra work. And the optional email to new submitters would be much > more friendly than having the patch go into a black hole without the > drawback of bothering old-time contributors. I'm still in favour of a real patch management system, if it was on Newman's todo list it can't be an evil idea and I think it would really help new and old developers. Ivan.

Sept. 8, 2005

Re: appdb developers please read

by Francois Gouget

On Thu, 8 Sep 2005, Ivan Leo Puoti wrote: > Francois Gouget wrote: > >> On Thu, 8 Sep 2005, Ivan Leo Puoti wrote: >> >> What is a 'patch management system'? >> >> If it's something Alexandre uses to apply patches, then his requirement >> that it be usable from his desktop environement (Emacs) precludes a >> web-based system. >> >> So what about something more like a patch tracking system, not for >> Alexandre's use but for everyone to see on the web? > > We don't need that, it's not much better than what we've got I disagree. It would be loads better than what we have now (i.e. nothing): > The benefits would be: > * we'd have a clear indication of what's the status of a patch > * we'd have a better idea of how many patches get dropped > * if we implement the automatic email notification submitters of > dropped patches would automatically get instructions on how to remedy > the issue > * dropped patches would be clearly visible making it easy for > volunteers to investigate themand take action Also it would not require disrupting Alexandre's routine or having him do extra work. And the optional email to new submitters would be much more friendly than having the patch go into a black hole without the drawback of bothering old-time contributors. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.

Sept. 8, 2005