Takuma Murakami added to commit list

[Harold L Hunt II]

> On Tue, Feb 03, 2004 at 07:19:40PM -0500, Harold L Hunt II wrote:
>> >On Tue, Feb 03, 2004 at 12:23:57PM -0500, Harold L Hunt II wrote:
>> >>Takuma Murakami has been contributing patches for a few months now.  To 
>> >>make submitting clean patches easier for Takuma, and since we can now 
>> >>provide this, I have added Takuma to the list of commiters for the xorg 
>> >>tree on freedesktop.org.
>> >>
>> >>Remember, we can now give commit access to anyone that demonstrates an 
>> >>interest in the success of the project by submitting a few clean 
>> >>patches.  If you have big plans for features, send some small patches to 
>> >>get started, then we can set you up with commit access for your 
>> >>continuing changes.
>> >
>> >Harold,
>> >
>> >I just want to understand what's happening with the project on SourceForge
>> >that we had control over anyway and you could add new committers there
>> >anyway ?
>> >
>> >Alan.
>> 
>> Alan,
>> 
>> Well, the problem with the SourceForge project was that it was not where 
>> our upstream changes originated from and it was not the upstream final 
>> destination for our changes.  We got changes from non-Cygwin specific 
>> portions of the code and we made changes to non-Cygwin specific portions 
>> of the code.  Thus, we could not ignore the fact that we had an upstream 
>> tree that we would always want to stay in sync with.
>> 
>> The new xorg repository on freedesktop.org is our new upstream home. 
>> That makes it less work for me to keep our work in sync with our 
>> upstream tree.  All we have to do now is merge from the CYGWIN branch 
>> back to the CURRENT branch.  Even better, I can delegate this to other 
>> people that can *do* it rather than them just asking that it be done and 
>> then follow it for two months waiting to make sure that it was done 
>> correctly.
>> 
>> It is really great and has dramatically cut down the amount of time that 
>> I spend doing administrative tasks for Cygwin/X.  It freed up enough 
>> time that I was able to, gasp, actually start working on new features 
>> again such as the improved clipboard integration.  :)
>> 
>> I hope that clears things up,
> 
> Not really. I'm confused over what you mean by upstream. 

Lets look at this from the analogy of Linux for a minute.  People make 
lots of generic changes to Linux that apply to all architectures that 
are supported by Linux.  Now, assume that instead of supporting the 
Cygwin port of X that I am supporting the Alpha port of Linux.  My users 
will expect me to make releases when the official Linux project makes 
releases such as 2.4.0-25 or 2.6.0-1 since they want all of those 
"upstream" generic changes.  Similarly, people I need to make sure that 
the code for my Alpha port (and any bug fixes made to generic files) 
finds its way back to the "upstream" Linux tree so that the Alpha 
support will be up to date.

The SourceForge project did not help meat any of those goals.  It 
provided a place to develop some code in isolation, but it did nothing 
to help get code back to the official tree.  In fact, it created quite a 
bit of work, because my 4.3.0 tree that I used for builds was different 
than the XFree86 HEAD, and both of these were different from the code in 
the SourceForge tree.  Mind you, I am talking only about the code in the 
hw/xwin directory; there were enough differences in that code alone to 
make merging patches from one tree to another a bit of a chore.

Additionally, we would frequently introduce support for new features 
added to the "upstream" (or XFree86) tree, such as Kensuke's new 
multi-window window manager that uses the miext/rootless extension 
developed for X on X.  That extension wouldn't exist in the SourceForge 
tree unless we imported it... and that is a pain to do when it is under 
heavy development.  Since the XFree86 tree is the tree that originated 
the miext/rootless code, then any bug fixes that we make to that code 
have to go back "upstream" to the XFree86 tree.

In the case of the XFree86 tree, syncing with the upstream tree was a 
pain in the ass because no one would let us do things for ourselves, 
even when they were platform specific fixes.  We had to put patches in a 
queue (and mind you, generating perfect patches is not easy, you might 
have forgotten that since you had CVS commit access for so long), mind 
the queue, thunk people on the heads when they ignored or misapplied our 
patches, wait about two months, etc. and finally be able to cross a 
single item off of our to-do list.

Today I can tell people to pull the CYGWIN tag from the xorg tree and be 
done with it.  That code is totally up to date and all developers have 
access to that code.  I no longer have to say, "grab the XFree86 CVS 
tree, then apply these fourteen patches in order".  Or, "grab the 
XFree86 CVS tree, replace the hw/xwin directory with the contents of 
this tarball, then apply this patch to config/cf/cygwin.cf, this patch 
to Xserver/Imakefile, this patch to Xserver/dix/main.c...".

I dunno Alan... it almost seems as if you are mocking me by saying you 
don't understand.  You know perfectly well the issues that I have 
continuously raised regarding getting the Cygwin/X code into the 
upstream tree.  Everytime I asked you you said that the system we had 
was fine; now you say you don't know what an upstream tree is.  I don't 
know what to think about that.

> But nevermind, you've moved to freedesktop.org, so I agree with Alexander
> about moving the docs and deleting the XonCygwin project from SF.

Okay.

Harold