HekaFS Development Workflow

Pete Zaitcev was having trouble building HekaFS the way he (apparently) builds other things, which led to an email discussion about how those of us already working on HekaFS currently build. With Pete’s permission – at his urging, in fact – here’s the scoop.


I can’t speak for Kaleb (or Edward) but my work flow is generally
something like this:

* Make changes on my desktop where I have a nice cscope setup etc.

* Rsync to build/test machine.

* Go into …/cloudfs/packaging.

* “make fedora” or “make gluster” as appropriate.

* Go into …/rpmbuild.

* “rpm –rebuild SRPMS/hekafs…”

* “yum reinstall –nogpgcheck RPMS/x86_64/hekafs…”

It’s a tiny package, so the whole cycle still takes practically no
time and it avoids most forms of inconsistency or rpm breakage. It
also allows me to deal with the differences between the Gluster and
Fedora packaging easily, which is important because I have to switch
between the two almost daily.

> If you write it somewhere, it would be appreciated. In particular,
> suppose you want to change something. Do you make changes to the git
> tree, or to the unpackage (rpmbuild -bp) tree? If the first, do you
> run the whole gauntlet in order to test the results? If the second,
> how do you scatter the changes back into the git (the pathnames are
> all different and not just having a different prefix)?

Sometimes while I’m debugging I make changes in …/cloudfs on the
build/test machine and rsync back, but I’ve been burned too many times
by making and then losing changes in …/rpmbuild/BUILD to do that any