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

[Steven Edwards]

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