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