February 2008 - Wine-Devel - list.winehq.org

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by James Hawkins

On Feb 10, 2008 11:57 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Feb 11, 2008 12:52 AM, Steven Edwards <winehacker(a)gmail.com> wrote: > > Let me put it another way. Having worked on multiple maintainer > > projects with public write access repositories and a single maintainer > > repo like Wine I know the up and down side of both methods, but it > > will be a cold day in hell before I waste my time trying to do any > > sort of major infrastructure work over bugzilla with plain diffs. Gits > > design is supposed to remove the need for such development practices. > > Its already in CVS in darwine but that does not make for easy merging > > so I fail to see how bugzilla + diff's is supposed to be a more > > effective development method. > > Sorry I didn't mean for that to sound quite so rude. Having invested a > good bit of time in trying to understand git, I think I git it now so > to speak and not having a public repo where there can be really > collaborative development seems to be a step back to me. Not that > bugzilla + diff's is bad. Its great for minor enhancements and small > patches that are not ready to go in but for major new developments > requiring multiple eye balls, a shared repository is the only sane way > to go. > This sparked a memory of the discussion about having a -devel and a -stable branch after we release 1.0. -- James Hawkins

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by Dan Kegel

On Feb 10, 2008 9:57 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > ... Having invested a > good bit of time in trying to understand git, I think I git it now so > to speak and not having a public repo where there can be really > collaborative development seems to be a step back to me. ? But you don't need a central public git repository to do collaborative development, that's the whole point of git... - Dan

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by Steven Edwards

On Feb 11, 2008 12:52 AM, Steven Edwards <winehacker(a)gmail.com> wrote: > Let me put it another way. Having worked on multiple maintainer > projects with public write access repositories and a single maintainer > repo like Wine I know the up and down side of both methods, but it > will be a cold day in hell before I waste my time trying to do any > sort of major infrastructure work over bugzilla with plain diffs. Gits > design is supposed to remove the need for such development practices. > Its already in CVS in darwine but that does not make for easy merging > so I fail to see how bugzilla + diff's is supposed to be a more > effective development method. Sorry I didn't mean for that to sound quite so rude. Having invested a good bit of time in trying to understand git, I think I git it now so to speak and not having a public repo where there can be really collaborative development seems to be a step back to me. Not that bugzilla + diff's is bad. Its great for minor enhancements and small patches that are not ready to go in but for major new developments requiring multiple eye balls, a shared repository is the only sane way to go. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by Steven Edwards

On Feb 10, 2008 11:18 PM, James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: > I would like to 'chime' in here. If you have it local and it is not > complete, why submit to the main program flow. Create a bug and put it > there. Simple and it keeps the code tree "clean". This allows others > to become aware of what you are up to and can increase collaboration. > Otherwise, your work becomes 'lost' and will never be complete. I would > NEVER submit anything to the tree that is not complete and ready for > review by Alexandre. I have been a victim of the dreaded drop, but that > is not because the code I submitted was incomplete, but parts of it have > become irrelivant because of changes to the tree. So, I've had to back > up and redo the work and then collaborate with the original submitter > and have a peer review and then submit. Hopefully this will be > applicable to your project. > Again, to summarize, if your code is not ready for Alexandre's review, > open a bug, put your changes there, let the development list know and > kick back and see what happens. If you need help, submit your code and > then let others help. Don't expect things to happen overnight, > sometimes it can take weeks or months. > Also, I am very interested in your work on winequartz, please let me > know what the bug number is. I am not talking about submitting anything broken to the main Wine tree. I was talking about having seperate repo that would allow for a limited amount of brokeness on public branches. The simple fact is that too much in mainline Winehq has changed from when winequartzdrv was first written and it needs to be in a tree somewhere that is public so there can be a merge and collaboration to fix the brokeness. Off the top of my head there is problems with visable region handling that was moved in to wineserver and CreateWindow abstraction that need to be fixed. Not to mention the fact Alexandre views the entire design to be flawed as is...Development of major new features like this out of bugzilla is a non-starter. See ntoskrnl development history for example. Let me put it another way. Having worked on multiple maintainer projects with public write access repositories and a single maintainer repo like Wine I know the up and down side of both methods, but it will be a cold day in hell before I waste my time trying to do any sort of major infrastructure work over bugzilla with plain diffs. Gits design is supposed to remove the need for such development practices. Its already in CVS in darwine but that does not make for easy merging so I fail to see how bugzilla + diff's is supposed to be a more effective development method. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by James McKenzie

Steven Edwards wrote: > On Feb 10, 2008 1:55 PM, Dan Kegel <dank(a)kegel.com> wrote: > >> Joeseph wrote: >> >>> Is there a Git Repositories for Unaccept Patches or (work in Progress)? >>> >> Not really, but people often attach patches to bugzilla >> entries if they're not quite good enough to submit. >> And if anybody wants to start such a git repository, >> more power to them. >> > > +1 > > I've got a local git repo setup where I have the winequartzdrv from > darwine sitting and I have been trying to bring up to date but never > have time to mess with it. It would be cool if we had a repo for > unacceptable patches that we could write to and maintain branches on > for projects like this because with others working on it it might one > day evolve in to the shape of something he would accept. > > I would like to 'chime' in here. If you have it local and it is not complete, why submit to the main program flow. Create a bug and put it there. Simple and it keeps the code tree "clean". This allows others to become aware of what you are up to and can increase collaboration. Otherwise, your work becomes 'lost' and will never be complete. I would NEVER submit anything to the tree that is not complete and ready for review by Alexandre. I have been a victim of the dreaded drop, but that is not because the code I submitted was incomplete, but parts of it have become irrelivant because of changes to the tree. So, I've had to back up and redo the work and then collaborate with the original submitter and have a peer review and then submit. Hopefully this will be applicable to your project. Again, to summarize, if your code is not ready for Alexandre's review, open a bug, put your changes there, let the development list know and kick back and see what happens. If you need help, submit your code and then let others help. Don't expect things to happen overnight, sometimes it can take weeks or months. Also, I am very interested in your work on winequartz, please let me know what the bug number is. James McKenzie

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by Steven Edwards

On Feb 10, 2008 1:55 PM, Dan Kegel <dank(a)kegel.com> wrote: > Joeseph wrote: > > Is there a Git Repositories for Unaccept Patches or (work in Progress)? > > Not really, but people often attach patches to bugzilla > entries if they're not quite good enough to submit. > And if anybody wants to start such a git repository, > more power to them. +1 I've got a local git repo setup where I have the winequartzdrv from darwine sitting and I have been trying to bring up to date but never have time to mess with it. It would be cool if we had a repo for unacceptable patches that we could write to and maintain branches on for projects like this because with others working on it it might one day evolve in to the shape of something he would accept. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 11, 2008

Re: pdh[3:3]: remove unnecessary tests done inPdhLookupPerfNameByIndexW

by Dmitry Timoshkov

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: >>> --- a/dlls/pdh/pdh_main.c >>> +++ b/dlls/pdh/pdh_main.c >>> @@ -837,14 +837,7 @@ PDH_STATUS WINAPI PdhLookupPerfNameByIndexA( >>> LPCSTR machine, DWORD index, LPSTR >>> >>> TRACE("%s %d %p %p\n", debugstr_a(machine), index, buffer, size); >>> >>> - if (machine) >>> - { >>> - FIXME("remote machine not supported\n"); >>> - return PDH_CSTATUS_NO_MACHINE; >>> - } >>> - >>> if (!buffer || !size) return PDH_INVALID_ARGUMENT; >>> - if (!index) return ERROR_SUCCESS; >> >> Changelog mentions PdhLookupPerfNameByIndexW by the change is in >> PdhLookupPerfNameByIndexA. >> Why are you removing the checks in one place by leave the same in >> other one? Why the tests >> are unnecessary? >> > The parameters, bufferW and sizeW passed by PdhLookupPerfNameByIndexA to > PdhLookupPerfNameByIndexW are local to PdhLookupPerfNameByIndexA. That doesn't mean that PdhLookupPerfNameByIndexW can't be called directly. > The > test is needed still in PdhLookupPerfNameByIndexA because the size and > buffer are not passed but still need to be checked. That still doesn't answer my questions. -- Dmitry.

Feb. 11, 2008

Re: gecko download not robust?

by Jacek Caban

Scott Ritchie wrote: > This would be ideal, however last I heard gecko didn't compile properly > in mingw. Is this no longer the case? Can we build it on Ubuntu? > Compiling the package is quite tricky. I've compiled it on Windows XP using MSVC. There is no other way ATM, so I think that my Gecko package should be included as is in Linux packages. Thanks, Jacek

Feb. 11, 2008

Re: COD4 stopped working

by Vitaliy Margolen

Matthew Clark wrote: > Vitaliy Margolen wrote: >> Matthew Clark wrote: >>> So around the time that 0.9.54 came out I lost COD4 on both my >>> desktop and laptop. In order for it to work you have to compile wine >>> with the >> >> Please don't make posts like this. Open bug in bugzilla instead. The >> mailing list is the bad place to track any information, especially bug >> related. >> >> Vitaliy. >> > sorry about that http://bugs.winehq.org/show_bug.cgi?id=11545 Thank you. Vitaliy

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by Vitaliy Margolen

Here we go again. Please read the archives. At least last few weeks would have pointed you to exactly the same topic which comes back again and again: http://www.winehq.org/pipermail/wine-devel/2006-September/thread.html#50915 And please respect everyone and don't use that color thingy in mailing lists (plain text no html). Vitaliy. Joseph Stein wrote: > skipped as it's impossible to read.

Feb. 11, 2008