Takuma Murakami added to commit list

[Harold L Hunt II]

> On Tue, Feb 03, 2004 at 08:42:18PM -0500, Harold L Hunt II wrote:
>> >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.
>  
> But if Torrey makes changes to the miext/rootless code you can either
> ignore them, or import them again from XFree86.

miext/rootless was just an example.

>> 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.
> 
> But I see your importing tag's already from XFree86. I see you've brought
> in 4.3.99.16 not long ago. So there's still merging work going on.

I'm not importing them.  That's part of the point: others are working on 
that tree as well, and hopefully more will in the future.  That lessons 
my work load for keeping in sync when it is required.

Of course, I have some new features that I will be working on that will 
not be sent to XFree86.  They will go only to the freedesktop.org trees 
and anyone that builds from those trees can use those new features.  Of 
course, I won't stop people from importing those patches to XFree86, nor 
will I require they put my name in documentation, but none of that 
really matters.

Another example would be that Alexander Gottwald just fixed some 
fundamental brokeness related to FD_SETSIZE and XFD_SETSIZE; that patch 
was committed directly to the xorg tree rather than being ignored on the 
XFree86 patch queue for two months.  Again, anyone that builds from the 
freedesktop.org tree will have that generic fix.

>> 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...".
> 
> But you could have done that with the SourceForge tree. No one ever had
> to download part of XFree86 to make that tree compile. It was just
> like the code you have on freedesktop.org now.

There was a difference: the version on freedesktop.org is the canonical 
version of the Cygwin/X source; if something is not in that tree, then 
it will not be in the next release; bugs present in the fd.o tree are 
exactly those bugs that will be in the next release (when I start 
cutting releases from that tree soon).  This is as opposed to the 
XFree86 and SourceForge trees: bugs present in each tree were different, 
particularly from the 4.3.0 branch used for building distributions; 
features present in the two trees were different.

When someone wanted an exact debug build of the current release, the 
only way to do it was to grab the 4.3.0 branch from XFree86, then apply 
the Cygwin-specific changes that had not been merged.

Could I have possibly done this at SourceForge?  Sure, but what is the 
bloody point of now keeping in sync with HEAD and xf-4_3-branch? 
Remember, I didn't get into this project to be a cvs lacky, I got into 
it because I enjoy coding.  Forcing me to keep an alternate tree in sync 
for no good reason was pretty much the ultimate insult; there was the 
ability to lesson my work load on such trivial, but time consuming, 
things; however, my request to do so was met with refusal.

>> 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.
>  
> No - I'm not mocking you at all - your making your own interpretation there.
> I was just trying to understand why I'm seeing commits for documentation,
> but nothing for hw/xwin yet I'm seeing new releases being made. 

Of course, I am responsible for my own interpretations.  I'm not sure if 
you have been following the Cygwin/X project lately, but I think you at 
least know that we are no longer associated with XFree86.  Given that, 
we needed a new canonical tree, or upstream tree, which is what the 
freedesktop.org tree is.  So, for you to ask why I wasn't committing to 
our SourceForge tree instead of fd.o seemed a little silly.

I can understand that seeing the documentation still being updated in 
the SourceForge tree would be a little confusing, which is why the 
documentation should be moved to fd.o and the SourceForge project should 
be deleted.  I think everyone agrees on that; it just hasn't been done yet.

Harold