On Feb 10, 2008 11:18 PM, James McKenzie jjmckenzie51@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.