Sat 2007/Aug/11
-
This is the inside of the vault over the bathroom, the
one that used hexagonal chicken-wire mesh. It was easy
to give even tension to the mesh over the steel bars, so
it did not buckle when applying the concrete on top.
The inside of the vault still needs to be evened out and
polished with a mixture of cement and sand.
In contrast, this is the vault over my office, which
used rhombus mesh for plaster. This kind of stupid mesh
stretches a lot, and very unevenly at that. So, it got
very bumpy when the concrete got laid on top. We'll
have to use some sort of pickaxe to even out the biggest
bumps, and then cover everything with the polishing
layer.
The bathroom's vault (foreground) already has a layer of
polished concrete on top, versus the office's vault
(background), which is still rough on the outside.
(Yes, our builders have taken to using rebar that sticks
out of the roof as a holder for soda bottles...)
-
I've been trying to figure out a Git-based workflow for
working with openSUSE's patched packages. For example,
openSUSE 10.3 is the bleeding edge distro being
developed, with GNOME 2.19.x packages in it. These
packages, modulo details, are the same as the ones that
were in openSUSE—10.2, except they have newer
source tarballs (to move from GNOME 2.16 to
GNOME 2.19), and of course updated patches against
those tarballs.
I want this workflow to solve the following problems:
-
Each time the distro gets a major update of packages
(like from GNOME 2.16 to 2.19), some old
patches need to be dropped, some need to be
re-diffed, and some need a complete rewrite. What
if instead of doing all this grunt work, we did
a periodic "git rebase" against the latest
development packages — that way it may be
easier to keep the patches up to date.
-
Having openSUSE 10.3 right now with a
GNOME 2.19 desktop is really nice for
development of upstream features. However,
sometimes this work needs slight modifications to
work in the distro. I'd like to have a Git branch
with my work in progress, which could later be
extracted easily as patches for upstream or patches
for the distro.
Something tells me that one could have a "pristine"
master branch for the upstream tarballs, a "distro"
branch (or "distro-version-x", "distro-version-y", etc.)
for the distribution's patches, and any number of
"personal" branches for development. I just haven't
figured out a clever way of juggling that.
Syndicated 2007-08-11 18:51:00 from Federico Mena-Quintero - Activity Log