June 2009 - Wine-Devel - list.winehq.org

Re: Removing active maintainers

by Dan Kegel

On Mon, Jun 29, 2009 at 5:56 AM, Remco<remco47(a)gmail.com> wrote: >> That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours. > > How about mailing admins after 24 hours? Maintainers are useful to > offload tasks of admins. Appdb admins get an absolute flood of appdb email. My impression was that we got copies of everything that ever happens on the appdb. Is it really only email for unmaintained apps? - Dan

June 29, 2009

Re: Removing active maintainers

by Erich Hoover

On Mon, Jun 29, 2009 at 8:38 AM, Remco <remco47(a)gmail.com> wrote: > On Mon, Jun 29, 2009 at 4:18 PM, Rosanne DiMesio<dimesio(a)earthlink.net> > wrote: > > On Mon, 29 Jun 2009 15:48:17 +0200 > > Remco <remco47(a)gmail.com> wrote: > >> > >> Ok, I thought everybody got their AppDB updates by mail. But whichever > >> way you receive notice of queued submissions without maintainers, > >> that's where the maintained submissions can be sent after 24 hours. > >> > >> Remco > > > > Admins can already see all test reports in the queue. That's not the > issue. The issue is removing maintainers who aren't doing their job. If we > do their job for them, with no consequences to the negligent maintainer, > that merely covers up the problem. > > So the issue is not that queued submissions aren't handled, but... > what? I thought the problem was unhandled submissions, caused by > negligent maintainers. But if that problem is not there, what problem > are negligent maintainers causing? > > Remco > > It sounds like they're causing too much extra work for the admins. What if the system checked for "Out of Office" bounces and used that to know that a maintainer was not going to be able to handle the submission for a while? Erich Hoover ehoover(a)mines.edu

June 29, 2009

Re: appwiz.cpl: updated French translation

by André Hentschel

Paul Vriens schrieb: > André Hentschel wrote: >> Frédéric Delanoy schrieb: >>> 2009/6/29 Paul Vriens <paul.vriens.wine(a)gmail.com>: >>>> Frédéric Delanoy wrote: >>>>> Some adaptation to English dialog too: "Add/Remove" button was >>>>> renamed to >>>>> "Remove", since its only purpose is to uninstall apps. >>>>> >>>> Hi Frédéric >>>> >>>> But the message clear says "or to modify its installed components". >>>> So I >>>> guess a more appropriate text on the button would be "Modify/Remove" >>>> (or >>>> something alike). >>>> >>>> -- >>>> Cheers, >>>> >>>> Paul. >>> >>> Hmm... you must be right... I'll change it to "Change/Remove" and >>> resubmit the patch. >>> >>> Thanks for your comment anyway >>> >>> Frédéric >>> >>> >> >> Hi Paul and Frédéric, >> You are also able to add Components/Software with the >> Installer-Button! So Add/Remove is correct. >> >> Best Regards, André Hentschel > Hi André, > > The installer-button I agree, but the (previously) Add/Remove button > doesn't if I'm correct. > Oh, sorry. Didnt saw that you were talking about the Button. In german its something like "Change/Remove..." so its ok in english and has nothing todo with the Installer-Button. My fault

June 29, 2009

Re: appwiz.cpl: updated French translation

by Paul Vriens

André Hentschel wrote: > Frédéric Delanoy schrieb: >> 2009/6/29 Paul Vriens <paul.vriens.wine(a)gmail.com>: >>> Frédéric Delanoy wrote: >>>> Some adaptation to English dialog too: "Add/Remove" button was >>>> renamed to >>>> "Remove", since its only purpose is to uninstall apps. >>>> >>> Hi Frédéric >>> >>> But the message clear says "or to modify its installed components". So I >>> guess a more appropriate text on the button would be "Modify/Remove" (or >>> something alike). >>> >>> -- >>> Cheers, >>> >>> Paul. >> >> Hmm... you must be right... I'll change it to "Change/Remove" and >> resubmit the patch. >> >> Thanks for your comment anyway >> >> Frédéric >> >> > > Hi Paul and Frédéric, > You are also able to add Components/Software with the Installer-Button! > So Add/Remove is correct. > > Best Regards, André Hentschel Hi André, The installer-button I agree, but the (previously) Add/Remove button doesn't if I'm correct. -- Cheers, Paul.

June 29, 2009

Re: [4/4] comctl32/rebar: Update Rebar structure

by Paul Vriens

Nikolay Sivov wrote: > Changelog: > - Update Rebar structure > >>From b0d8b14a60f391144077cf8c053df5ea36fd22c4 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Sun, 28 Jun 2009 03:40:20 +0400 > Subject: Update Rebar structure > > --- > include/commctrl.h | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/include/commctrl.h b/include/commctrl.h > index 2c887d0..beecb52 100644 > --- a/include/commctrl.h > +++ b/include/commctrl.h > @@ -1988,6 +1988,9 @@ typedef struct tagREBARBANDINFOA > UINT cxIdeal; > LPARAM lParam; > UINT cxHeader; > + /* _WIN32_WINNT >= 0x0600 */ > + RECT rcChevronLocation; > + UINT uChevronState; > } REBARBANDINFOA, *LPREBARBANDINFOA; > > typedef REBARBANDINFOA const *LPCREBARBANDINFOA; > @@ -2014,6 +2017,9 @@ typedef struct tagREBARBANDINFOW > UINT cxIdeal; > LPARAM lParam; > UINT cxHeader; > + /* _WIN32_WINNT >= 0x0600 */ > + RECT rcChevronLocation; > + UINT uChevronState; > } REBARBANDINFOW, *LPREBARBANDINFOW; > > typedef REBARBANDINFOW const *LPCREBARBANDINFOW; Hi Nikolay, Looks like this introduces test failures on everything below Vista. Could you check? -- Cheers, Paul.

June 29, 2009

Re: appwiz.cpl: updated French translation

by André Hentschel

Frédéric Delanoy schrieb: > 2009/6/29 Paul Vriens <paul.vriens.wine(a)gmail.com>: >> Frédéric Delanoy wrote: >>> Some adaptation to English dialog too: "Add/Remove" button was renamed to >>> "Remove", since its only purpose is to uninstall apps. >>> >> Hi Frédéric >> >> But the message clear says "or to modify its installed components". So I >> guess a more appropriate text on the button would be "Modify/Remove" (or >> something alike). >> >> -- >> Cheers, >> >> Paul. > > Hmm... you must be right... I'll change it to "Change/Remove" and > resubmit the patch. > > Thanks for your comment anyway > > Frédéric > > Hi Paul and Frédéric, You are also able to add Components/Software with the Installer-Button! So Add/Remove is correct. Best Regards, André Hentschel

June 29, 2009

Re: Removing active maintainers

by Remco

On Mon, Jun 29, 2009 at 4:18 PM, Rosanne DiMesio<dimesio(a)earthlink.net> wrote: > On Mon, 29 Jun 2009 15:48:17 +0200 > Remco <remco47(a)gmail.com> wrote: >> >> Ok, I thought everybody got their AppDB updates by mail. But whichever >> way you receive notice of queued submissions without maintainers, >> that's where the maintained submissions can be sent after 24 hours. >> >> Remco > > Admins can already see all test reports in the queue. That's not the issue. The issue is removing maintainers who aren't doing their job. If we do their job for them, with no consequences to the negligent maintainer, that merely covers up the problem. So the issue is not that queued submissions aren't handled, but... what? I thought the problem was unhandled submissions, caused by negligent maintainers. But if that problem is not there, what problem are negligent maintainers causing? Remco

June 29, 2009

Re: [PATCH 1/2] Include: Add fil_data.idl to describe IAMFilterData interface (resend)

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Strange, I found header here: > Samples/Multimedia/DirectShow/Misc/Mapper/fil_data.h > > The thing is, that IAMFilterData interface is not describe anywhere at all, > except that file. So, should I just move it into dxdiagn dir? Yes, apparently that's how it's meant to be used. -- Alexandre Julliard julliard(a)winehq.org

June 29, 2009

Re: [1/2] makedep: Add support for multiple object file extensions.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > This is useful to generate dependencies for crossbuilds. -o is traditionally used for the output file, so something like -x would probably be preferable. Also specifying multiple extensions by repeating the option (-xfoo -xbar instead of -xfoo:bar) is probably nicer, especially for usage in makefiles. -- Alexandre Julliard julliard(a)winehq.org

June 29, 2009

Re: Anyone at LinuxTag?

by Roderick Colenbrander

On Mon, Jun 29, 2009 at 8:28 AM, Scott Ritchie<scott(a)open-vote.org> wrote: > Kai Blin wrote: >> >> On Monday 29 June 2009 07:51:03 Austin English wrote: >>> >>> On Mon, Jun 29, 2009 at 12:46 AM, Kai Blin<kai.blin(a)gmail.com> wrote: >> >>>> Yes. Realistically, there will be a contract involved regulating what >>>> needs to be done to get the money. I very much doubt the government just >>>> go and drop money on random paypal buttons and hope for the best. The >>>> way >>>> I've seen stuff like this work before is that there's a call for bids >>>> from companies to implement certain features in a piece of software, >>>> maybe with the requirement at a reasonable effort to get the produced >>>> changes upstream. >>> >>> Ah, misunderstood what you meant there. >>> >>> Eventually some sort of foundation would be the best thing to head >>> toward, but that's a legal headache. >> >> I don't see how a foundation would help with a a situation like that. To >> recap the (theoretical) situation. Someone, let's call him the client, wants >> some features implemented in Wine and is ready to spend money on that. >> >> Now, there's three things the client could do. He could hire some >> developers to get the stuff he wants implemented. That's a huge >> administrative effort just to get some lines of code done, and as you tend >> to pay employees by work-hours, you need to estimate how long it will take >> to implement the feature. >> >> The more obvious thing to do (IMHO) is to go and contract somebody, >> company or individual to implement these features. As opposed to an >> employment contract, you usually agree on what needs to be delivered and pay >> only if it is delivered. >> Now what I understood you're suggesting is that instead of contracting a >> company or individual, the client could give the money to a Wine Foundation. >> How is that money going to turn into the code the client wants to have? Is >> the Wine Foundation going to hire Wine developers to work on such stuff? Is >> there enough money in development services like that to offer a stable job >> to any developer? >> > > There may very well be - Mozilla had a few full time employees years ago, > and at the time they had about as many users as we do. > > That doesn't even count other roles a foundation could play, such as > community organizing, developer recruiting, sponsoring "summer of code" > projects year round, or even just serving as a tax deduction for > Codeweavers' donated code. > > Thanks, > Scott Ritchie > > A full foundation could give us advantages like that. I really think that we could raise quite a bit of money (just see what other projects are receiving). We mainly lack good goals and policies what we should do with it. Sponsoring WineConf and perhaps even developers makes sense. The danger is of course competing with Codeweavers but I don't think it would be better for both. Right now Codeweavers works on areas which are critical to get programs they support working. This includes 'boring' stuff like msxml, msi, jscript and other parts which volunteers barely work. There are also big parts like our beloved DIB engine which take a lot of resources and might only get implemented if there is a serious need or a big paying customer. Else it is too expensive. I can imagine that if we had some good goals and organize lets say 1 or 2 fund raisers a year you might be able to raise 50k. This could be used for purposes like the ones explained but parts can also be used to sponsor Codeweavers (or an external developer) on things like a DIB engine which else never get implemented. Thanks, Roderick

June 29, 2009