ooo-build.git

What is ooo-build.git?

GIT: effort to move SVN and patching (apply.pl) to SCM

Cumbersome development process
- Generate patches (using CVS or GIT)
- Commit into SVN
- Test applying on clean tree, with patch.unapply, patch.apply often fails
- Indirect development: patches are fragile and patching problems are sometimes hard to reproduce
Effectively no [shared] SCM for most of our real work
- Lose most of change history or
- carry forward changes in local GIT tree.
- No [quick] vc-annotate on changes, must fallback on grep patches/*/*diff and manual verification.
- Upstream/Go-oo development in disjunct trees.
- Duplictation of effort.

GIT: Design decisions

patches or branches?
- STGit: only for local work, cannot be shared [yet]. STGit looks real nice, if it only had distributed qualities and the patches were stored as branches.
- Seems just right: this is what GIT is built for and this is how kernel people use it (see Ingo Molnar's git list post).
- Quite fresh (announced August 3): TOPGit. Not considered yet, we started in June. [Must look]

* we chose to make a solution based on branches ~1 patch or a set of very closely related patches from ooo-build svn form a branch.

GIT: Current state

Current state of the GIT efforts is a set of buildable ooo-build achives. You may have a peek by doing

git clone http://lilypond.org/vc/ooo-build.git
cd ooo-build
./autogen.sh --with-distro=SUSE
./download   # runs: git clone http://lilypond.org/vc/dev300-m28.git
make

now builds m28 on a clean checkout.

So, we currently [/confusingly] have *two* git archives.

GIT: Repository dissection

Instead of unpacking a tarball in build/dev300-m28 this will clone a second GIT archive, similar to what you have when you use GIT locally. This archive contains

main branches:

distro/SUSE                  main branch, all patches applied
for --distro=SUSE

upstream/dev300-m28          unpatched ooo-build r13158,
                             currently without history

380 feature branches of which

266 independent feature branches:

about-build-ver-readability  upstream/dev300-m28
                             + about-build-ver-readability.diff

addrbk-datasrc-ordering      upstream/dev300-m28
                             + addrbk-datasrc-ordering.diff
...
cws-npower10                 upstream/dev300-m28
                             + cws-npower10-m28.diff

114 feature branches which depend on (and thus include) other branches

cws-npower11                 upstream/dev300-m28
                             + cws-npower10-m28.diff
                             + cws-pflin10.diff
                             + cws-npower11.diff

Some patches are aggregated together in a branch

by directory:

emf+                         + patches/emf+/*
gsteamer                     + patches/gstreamer/*
...

by patch name prefix:

fpicker-kde                  + dev300/fpicker-kde*
...

by stripping -MODULE suffix:

wpsimport                    + wpsimport-writerperfect.diff
                             + wpsimport-scp2.diff
                             + wpsimport-filter.diff
                             + wpsimport-config_office.diff

Creation of this git archive is done with the ooo-build/bin/gob script. For details, see there. The current archive only contains distro/SUSE but adding more distros is rather straightforward. The dev300-m19 version had also distro/Debian.

Milestone updates

When a new upstream release happens (that we want to base new work on)

a new upstream/dev300-m29 branch is created
the distro/SUSE branch is updated to include the upstream changes
all feature branches are updated to include the upstream changes

which is done using the ooo-build/bin/gob-bump script, which we tested to go from dev300-m19 to dev300-m21.

QUESTIONS/DECISIONS -- Must have/decide

Your input. [Thanks Thorsten, Kendy Kohei, Jon!]
Multiple distros in one repository, one repository per distro?
Buildability of branches, ref. Jon's forms-radiobutton-group-names in a build failure within `connectivity'
```
connectivity/source/drivers/evoab2/NStatement.cxx:406:
error: 'getTableRange' was not declared in this scope
```
Responsibility/workflow of keeping master up to date. Suggestion: before any upload/sharing of work, developer integrates all her changes in feature branches into master. (What about multiple masters: distro/Debian, distro/SUSE. gob tooling? multiple archives?)
Revise gob-bump script (see Ingo Molnar's git list post).
Help the GIT-uninitiated scare their GIT-daemons away by providing user story workflow examples, possibly SVN+apply.pl -> ooo-build.git commands side by side.
Green light/Planning[/Flaming? :-)]

Packager's concerns -- Must have [gob] tooling/recipies

check whether a patch causes a regression in ooo-build
- simply disable a patch and check
easily determine what stuffs belong to what patch
- easily find what to disable when someone broke something
always have the most up to date milestone
always have the release branch
support workflow:
- make changes on a clean upstream tree
- create a patch
- add patch to tree and manually resolve any conflicts

TODO -- Good to have

CVS(/SVN)-history for the upstream/* imports; has been done before (preferrably optional/with history horizon). Possibly from upstream SVN this time using git-svn?
An ooo-build.git with *all* branches (with nice commit messages).
Gob tooling for creating new branches, generating patch sets, looking-up maintainer and issue numbers, etc.

LATER -- Nice to have

Morf ooo-build.git into just another feature branch?
--pieces? [orthogonal: use git-filter-branch]
Remove unnecessary dependencies (commits) from branches (the gob git-export script is set to greedy) [individual maintainers].

Pointers

wiki.services.openoffice.org/wiki/Git
Ingo Molnar, merge lots of topic branches thread.gmane.org/gmane.comp.version-control.git/89644
STgit future developments kerneltrap.org/mailarchive/git/2007/5/4/245281 kerneltrap.org/mailarchive/git/2007/5/4/245280
TOP-git kerneltrap.org/mailarchive/git/2008/8/3/2795494

Status of ooo-build.git 2008-08-06