Baby steps towards master-sync (Was: Re: Building Xquartz from source)
Baby steps towards master-sync (Was: Re: Building Xquartz from source)
- Subject: Baby steps towards master-sync (Was: Re: Building Xquartz from source)
- From: Jeremy Huddleston <email@hidden>
- Date: Mon, 19 Nov 2007 03:01:37 -0800
Ok, so I spent a bit of time today learning about git and all its
wonderful features (of which usability is not one). I've learned how
to handle pushing our branch's base (the branch-point) further along
master. As an example, the following command will change our base to
the end of the server-1.2-branch. The long hex string there is the id
for the branch point. You can get it from clicking on "Distribute hw/
xfree86/modes." here http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=shortlog;h=server-1.2-branch
git-rebase 96c637350d1117d18a10ca3de40814b506c8ffc3 xorg-server-1.2-
apple
I'd like to start taking our base in baby steps forward along the
master branch towards current, and I'd like to see if anyone has any
complaints about that. Here are the possible concerns with this and
my responses:
1) Jeremy, you should be fixing Xquartz since it's not working as I'd
like.
I just started diving into xserver's codebase a month ago with
leopard's release. As such, I'm still learning how things are laid
out. Doing the code cleanup and other tasks has helped me learn a bit
more about it, and I think doing this will help me get an even better
handle on the xserver code, so I can help out more in the future while
also moving us closer to current (master branch) development.
2) Why don't you jump to the end instead?
As Ben mentioned, there is a problem with Xquartz on the current
master branch. We get far more crashes in the rootless code than with
1.2 as a base.
3) Ok, so then why not half-way and start binary-searching for the
problem?
Binary-searching for a bug is a great way to find it if it's 100%
deterministically reproducible. These crashes, afaik, are not as
deterministic, and I'd hate to go down the wrong path at a binary
split assuming "working" when it really wasn't. I don't like the idea
of pushing many changes at once, so this will give me a better chance
to audit the changes as they are merged in. If we loose stability,
I'll have a better idea of exactly what few changes were made. Plus a
binary search assumes there is just ONE problem!
4) Newer versions will have higher dependencies. The rebase above
already needs an update to 3 xserver deps. I don't want to update
other stuff.
The updated dependences will be well documented on the wiki.
Additionally, the main updates will be to header files and only
necessary if you will be compiling from source. Furthermore, any
binary updates will be rolled into the x11_update.sh script.
Comments?
--Jeremy
On Nov 18, 2007, at 12:31 PM, Jeremy Huddleston wrote:
On Nov 18, 2007, at 10:49 AM, Ben Byer wrote:
The real answer to that question is: At some point, I had to pick
a specific version of every given X11-related software component
for "X11 that will ship on a zillion expensive DVDs of Leopard",
and that was the most current version on that day. So, in some
sense, it's arbitrary; this is why we got screwed by libX11-1.1.2
causing Gimp crashes, etc.
As you noted, there are specific symbol dependencies between a
specific version of the X server and the version of MesaLib used to
build the server. However -- we've spent most of the past few
weeks on this mailing list just trying to address the immediate
problems with the specific versions of the software that was
distributed as part of the Leopard GM release. Our long-term goal
is to build the X server against the X.org git master branch -- the
very latest and greatest code. If you try that now, it almost
works, but we get many crashes in the Rootless code -- none of
which changed between the 7.2 code and the X. So, we don't know
why it broke, or exactly when -- so if you wanted to start
upgrading bits and figure out when it breaks, that would be very
helpful.
And git is a great tool to help us do this, but HOW to use it is
beyond my comprehension at present... From what I've seen, we should
be able to "easily" merge the xorg-server-apple-1.2 branch changes
to a more recent branch point of master (perhaps stepping to the 1.3
tag first, then doing binary searches on the major releases, then on
individual changes between the releases)... I know git-bisect is
good for the binary searching, but I don't know if it can do binary
searching among branch-points...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden