Re: Takuma Murakami added to commit list

[Alan Hourihane <alanh at fairlite dot demon dot co dot uk>]

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.

> 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.

> 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.

> 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. 

Alan.