Difference between revisions of "Ooo-build"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Checking out)
(update the releasing, branching, support for new MWS processes for SVN and new Go-oo site)
Line 43: Line 43:
 
disruptive, one of the core ooo-build hackers will follow something like this process:
 
disruptive, one of the core ooo-build hackers will follow something like this process:
  
* '''cvs update''' - get the latest everything
+
* '''svn up''' - get the latest everything
  
 
* Read back through the ''ChangeLog'' and update the ''NEWS'' file for the release, summarizing and attributing the changes.
 
* Read back through the ''ChangeLog'' and update the ''NEWS'' file for the release, summarizing and attributing the changes.
Line 57: Line 57:
 
</pre>
 
</pre>
  
* '''./autogen.sh''' - this re-builds configure with the version in place; a distro must be specified eg. '''./autogen.sh --with-distro=SUSE'''
+
* '''svn commit''' - so what's there is what's there. If there was a collision you get to loop to the first stage here, but don't re-increment the number.
  
* '''make dist''' - this builds the archive containing everything.
+
* '''svn -r <id> copy svn+ssh://<user>@svn.gnome.org/svn/ooo-build/<tree>/ svn+ssh://<user>@svn.gnome.org/svn/ooo-build/tags/OOO_BUILD_X_Y_Z''' - this creates a copy of the current state so we can reproduce the build at any time and easily diff between releases. The '''id''' is the revision number printed when the '''commit''' command finishes, e.g. ''10364''. The '''tree''' is either ''trunk'' or ''branches/ooo-build-M-N''.
  
* '''cvs commit''' - so what's there is what's there. If there was a collision you get to loop to the first stage here, but don't re-increment the number.
+
* '''./autogen.sh''' - this re-builds configure with the version in place; a distro must be specified eg. '''./autogen.sh --with-distro=GoOoLinux'''
  
* '''cvs -z3 tag OOO_BUILD_X_Y_Z''' - this leaves a static tag so we can reproduce the build at any time and easily diff between releases.
+
* '''make dist''' - this builds the archive containing everything.
  
 
* '''md5sum ooo-build-X.Y.Z.tar.gz > ooo-build-X.Y.Z.tar.gz.md5''' - so that users can do at least the basic consistency check
 
* '''md5sum ooo-build-X.Y.Z.tar.gz > ooo-build-X.Y.Z.tar.gz.md5''' - so that users can do at least the basic consistency check
  
* '''scp ooo-build-X.Y.Z.tar.gz* ooo@go-oo.org:/var/www/packages/<MWS_DIR>/''' - uploads the tarball and the .md5 file for the right Master Work Space, eg. SRC680
+
* '''scp ooo-build-X.Y.Z.tar.gz* ooweb@seagull.dreamhost.com:~/download.go-oo.org/<MWS_DIR>/''' - uploads the tarball and the .md5 file for the right Master Work Space, eg. SRC680
  
 
* It's then customary to announce the release, see the template in ''doc/announce.txt'' - update all the ***s to the right versions, insert the contents of ''NEWS'', fire and forget.
 
* It's then customary to announce the release, see the template in ''doc/announce.txt'' - update all the ***s to the right versions, insert the contents of ''NEWS'', fire and forget.
Line 73: Line 73:
 
== Branching ==
 
== Branching ==
  
When there's a particularly good reason for a branch, such as a MWS is moved to the maintenace mode and we want open HEAD for further development, one of the core ooo-build hackers will follow something like this process:
+
When there's a particularly good reason for a branch, such as a MWS is moved to the maintenace mode and we want open TRUNK for further development, one of the core ooo-build hackers will follow something like this process:
  
* create the tags:
+
* create the branch and anchor copies:
** '''cvs update''' or  '''cvs update -r OOO_BUILD_X_Y_Z'''- get the latest everything or a tagged sources
+
** '''svn copy svn+ssh://<user>@svn.gnome.org/svn/tags/OOO_BUILD_X_Y_Z svn+ssh://<user>@svn.gnome.org/svn/ooo-build/branches/ooo-build-M-N''' - do the branch for OOo-M.N from a previous release of ooo-build-X.Y.Z
** '''cvs -z3 tag -b ooo-build-X-Y-Z''' - do the branch
+
** '''svn copy svn+ssh://<user>@svn.gnome.org/svn/tags/branches/ooo-build-M-N svn+ssh://<user>@svn.gnome.org/svn/ooo-build/tags/OOO-BUILD-M-K-ANCHOR''' - this creates a copy of the current state so we can diff against it and see the branch specific changes
** '''cvs tag OOO-BUILD-X-Y-Z-ANCHOR''' - this leaves a static tag so we can diff against it and see the branch specific changes
+
* make changes specific for the original tree (TRUNK):
* make changes specific for the original tree (HEAD):
+
** '''svn co svn+ssh://<user>@svn.gnome.org/svn/ooo-build/<tree>/ ooo-build''' - get sources from the original tree, either from ''trunk'' or ''branches/ooo-build-M-N''.
** '''cvs co ooo-build''' - get sources from the original tree
+
 
** if it is an important branch, such as for a minor OOo version, add a line to the message printed at the end of ''configure.in''. It might be something like:  
 
** if it is an important branch, such as for a minor OOo version, add a line to the message printed at the end of ''configure.in''. It might be something like:  
 
**:<tt>ooo-build-X-Y-Z  branch for X.Y.Z</tt>
 
**:<tt>ooo-build-X-Y-Z  branch for X.Y.Z</tt>
 
** add a line to any handy ''ChangeLogs'', so we can easily see where this happened in the flow. Of course, if you branched an older tag, you must put the comment into the right context. See below for a sample comment.
 
** add a line to any handy ''ChangeLogs'', so we can easily see where this happened in the flow. Of course, if you branched an older tag, you must put the comment into the right context. See below for a sample comment.
** '''cvs commit'''
+
** '''svn commit'''
 
* make changes specific for the branch:
 
* make changes specific for the branch:
** '''cvs co -r ooo-build-X-Y-Z''' - get sources from the branch
+
** '''svn co svn+ssh://<user>@svn.gnome.org/svn/ooo-build/branches/ooo-build-M-N ooo-build-M-N''' - get sources from the branch
 
** modify the message printed at the end of ''configure.in''. It might be something like:
 
** modify the message printed at the end of ''configure.in''. It might be something like:
**:<tt>This is ooo-build-2-0-4 - the stable branch for the 2.0.4 release.<br>If you want to build something cool, unstable, and risky, use HEAD.</tt>
+
**:<tt>This is ooo-build-2-0-4 - the stable branch for the 2.0.4 release.<br>If you want to build something cool, unstable, and risky, use trunk.</tt>
 
** add the same comment to the ''ChangeLog'' as in the original tree
 
** add the same comment to the ''ChangeLog'' as in the original tree
** '''cvs commit'''
+
** '''svn commit'''
 
* it's then customary to announce the release
 
* it's then customary to announce the release
  
Line 108: Line 107:
  
 
* first, it is better to clean ooo-build and remove support for all old and obsolete milestones; FIXME: it will be described somewhere else
 
* first, it is better to clean ooo-build and remove support for all old and obsolete milestones; FIXME: it will be described somewhere else
*'''cvs update''' - get the latest everything
+
*'''svn up''' - get the latest everything
 
*edit ''download.in'', mention the new tarball file name and URL in the array ''%SRC_URLS'', something like:
 
*edit ''download.in'', mention the new tarball file name and URL in the array ''%SRC_URLS'', something like:
 
*:<tt>              'oox680-m.*'                        => '@MIRROR@/OOX680',</tt>
 
*:<tt>              'oox680-m.*'                        => '@MIRROR@/OOX680',</tt>
Line 125: Line 124:
 
*:        * configure.in: Default to oox680-mY
 
*:        * configure.in: Default to oox680-mY
 
*:</pre>
 
*:</pre>
*'''cvs commit'''
+
*'''svn commit'''
 
*it's then customary to announce this kind of change
 
*it's then customary to announce this kind of change
  

Revision as of 17:12, 9 November 2007

This collection of patches, artwork and build infrastructure exists solely as a reflection of the many problems encouraging reasonably responsive change up-stream. The process of change is painful for any organisation, the larger the more painful. However - the size of the problem is no excuse to not try; hence the evenutal aim is to remove the need for ooo-build by incrementally fixing the various problems.

About ooo-build

ooo-build arose from acute frustration with the bad-old days of OOo process before the Child Workspace concept was introduced, it is also fueled by a non-performant CVS server.


Checking out

To check out ooo-build from the gnome subversion repository, run one of the following in the command line:

[fundamental,N] svn co svn://svn.gnome.org/svn/ooo-build/trunk ooo-build (trunk) svn co svn://svn.gnome.org/svn/ooo-build/branches/ooo-build-2-2 ooo-build (ooo-build-2-2 branch) svn co svn://svn.gnome.org/svn/ooo-build/branches/ooo-build-2-1 ooo-build (ooo-build-2-1 branch)

svn co svn+ssh://[your gnome account]@svn.gnome.org/svn/ooo-build/trunk ooo-build (trunk via ssh tunnel)

Making a patch on a set of files

You can use git locally and it's really great for larger tasks.

make patch.apply
cd build/current
git init
echo unxlng*.pro > sc/.gitignore
git add sc
git commit

And from now on you can locally commit to sc (git commit -a) until you are happy. To generate the patch, just

git diff | sed 's#^\(---\|+++\) [ab]/#\1 #'

To remove the git tracking :

rm -rf .git

Releasing

When there's a particularly good reason for a release, such as a distro needs a stable base or we want to do something potentially disruptive, one of the core ooo-build hackers will follow something like this process:

  • svn up - get the latest everything
  • Read back through the ChangeLog and update the NEWS file for the release, summarizing and attributing the changes.
  • edit configure.in, bump the version in the AC_INIT line, incrementing the minor version eg. AC_INIT(ooo-build, X.Y.Z)
  • Add a line to any handy ChangeLogs, so we can easily see where this happened in the flow:
    2019-13-33  Ned Squeers  <ned@sqeers.com>

            * Version X.Y.Z
  • svn commit - so what's there is what's there. If there was a collision you get to loop to the first stage here, but don't re-increment the number.
  • svn -r <id> copy svn+ssh://<user>@svn.gnome.org/svn/ooo-build/<tree>/ svn+ssh://<user>@svn.gnome.org/svn/ooo-build/tags/OOO_BUILD_X_Y_Z - this creates a copy of the current state so we can reproduce the build at any time and easily diff between releases. The id is the revision number printed when the commit command finishes, e.g. 10364. The tree is either trunk or branches/ooo-build-M-N.
  • ./autogen.sh - this re-builds configure with the version in place; a distro must be specified eg. ./autogen.sh --with-distro=GoOoLinux
  • make dist - this builds the archive containing everything.
  • md5sum ooo-build-X.Y.Z.tar.gz > ooo-build-X.Y.Z.tar.gz.md5 - so that users can do at least the basic consistency check
  • scp ooo-build-X.Y.Z.tar.gz* ooweb@seagull.dreamhost.com:~/download.go-oo.org/<MWS_DIR>/ - uploads the tarball and the .md5 file for the right Master Work Space, eg. SRC680
  • It's then customary to announce the release, see the template in doc/announce.txt - update all the ***s to the right versions, insert the contents of NEWS, fire and forget.

Branching

When there's a particularly good reason for a branch, such as a MWS is moved to the maintenace mode and we want open TRUNK for further development, one of the core ooo-build hackers will follow something like this process:

  • create the branch and anchor copies:
    • svn copy svn+ssh://<user>@svn.gnome.org/svn/tags/OOO_BUILD_X_Y_Z svn+ssh://<user>@svn.gnome.org/svn/ooo-build/branches/ooo-build-M-N - do the branch for OOo-M.N from a previous release of ooo-build-X.Y.Z
    • svn copy svn+ssh://<user>@svn.gnome.org/svn/tags/branches/ooo-build-M-N svn+ssh://<user>@svn.gnome.org/svn/ooo-build/tags/OOO-BUILD-M-K-ANCHOR - this creates a copy of the current state so we can diff against it and see the branch specific changes
  • make changes specific for the original tree (TRUNK):
    • svn co svn+ssh://<user>@svn.gnome.org/svn/ooo-build/<tree>/ ooo-build - get sources from the original tree, either from trunk or branches/ooo-build-M-N.
    • if it is an important branch, such as for a minor OOo version, add a line to the message printed at the end of configure.in. It might be something like:
      ooo-build-X-Y-Z branch for X.Y.Z
    • add a line to any handy ChangeLogs, so we can easily see where this happened in the flow. Of course, if you branched an older tag, you must put the comment into the right context. See below for a sample comment.
    • svn commit
  • make changes specific for the branch:
    • svn co svn+ssh://<user>@svn.gnome.org/svn/ooo-build/branches/ooo-build-M-N ooo-build-M-N - get sources from the branch
    • modify the message printed at the end of configure.in. It might be something like:
      This is ooo-build-2-0-4 - the stable branch for the 2.0.4 release.
      If you want to build something cool, unstable, and risky, use trunk.
    • add the same comment to the ChangeLog as in the original tree
    • svn commit
  • it's then customary to announce the release

Sample comment:

2019-13-33  Ned Squeers  <ned@sqeers.com>

    * Branched for X.Y.Z:                                                   
          OOO-BUILD-X-Y-Z-ANCHOR - the anchor tag,                              
          ooo-build-2-0-4 - the branch.                                         

Support for new MWS

When the upstream branches new MWS and we want to support it in ooo-build, one of the core ooo-build hackers will follow something like this process:

  • first, it is better to clean ooo-build and remove support for all old and obsolete milestones; FIXME: it will be described somewhere else
  • svn up - get the latest everything
  • edit download.in, mention the new tarball file name and URL in the array %SRC_URLS, something like:
    'oox680-m.*' => '@MIRROR@/OOX680',
  • edit patches/src680/apply
    • fix the OLDEST_SUPPORTED option; note that more MWSs can be supported, it might be something like:
      OLDEST_SUPPORTED=src680-m181,ooe680-m1
    • fix the conditions for the various sections; note that you must add condition for the new MWS everywhere where a condition for another MWS already exists; it might look like:
      [ Fixes >= src680-m182 >= ooe680-m2 ]
  • might want to use the new milestone by default, then update DEFAULT_TAG in configure in, it looks like:
    DEFAULT_TAG=oox680-mY
  • describe all changes in ChangeLog; it is usually enough to mention something like:
    2019-13-33 Ned Squeers <ned@sqeers.com>
    * configure.in, download.in, patches/src680/apply: support for oox680
    * configure.in: Default to oox680-mY
  • svn commit
  • it's then customary to announce this kind of change

Support for final OOo version

When the upstream releases final version of a MWS, one of the core ooo-build hackers will follow something like this process:

  • must check whether the final sources differ from the latest milestone; if the sources are the same, only symlink is made at go-oo.org/packages; new sources are created otherwise; the new tarball name is something like OOO_X_Y_Z
  • do all the steps as in case of support for new MWS with the following modifications:
    • use the tarball name OOO_X_Y_Z instead of the MWS- and milestone-based name oox680-mY
    • if the sources are only symlinks to the lates milestone, hack bin/unpack, so it creates the symlink to the unpacked sources; it might look like:
      if test -d oox680-mY -a ! -d OOO_X_Y_Z ; then
      echo "Linking rcZ to X.Y.Z"
      ln -sf oox680-mY OOO_X_Y_Z
      fi

Remaining unsolved issue summary

A helpful summary of these is provided here in no particular order along with suggestions for improvement. Many of these are mercifully easy to fix, and should be fixed soon.

source handling

ooo-build has a post-configure 'download' mechanism, whereby the relevant source archives will be automatically downloaded to your system having configured it, in response to your various options.

non-responsiveness / lack of leadership

Many ooo-build patches are ready for up-streaming but there is no / little response from up-stream. Worse there is the perception that taking leadership and actually doing something about merging fixes would be firmly opposed. Finally - even when maintainers are active, responsive & friendly - there is no agreed mechanism for blanket approving fixes - or sub-types of trivial fixes, which thus tend to fester in IssueZilla.

At the time of writing ooo-build's patches are available here: http://go-oo.org/ooo-build/patches/src680/apply.

font substitution

Many vendors ship AGFA's propriatory metric-compatible fonts with OO.o - it is thus necessary to run several seds on the VCL.xcu [ further bloating this already gigantic messy beast ]. We also remove some of the more foolish & enthusiastic font-usage of eg. the metrically-extremely-strange bitstream font eg. bin/font-munge.pl

   s/(Bitstream Vera Sans;.*)Albany;/Albany;$1/;
   # add AMT fonts
   s/Albany;/Albany AMT;Albany;/g;
   s/albany;/albanyamt;albany;/g;

no 'UI' team

The up-stream UI team have come up with master-pieces of UI design such as the Yes/No dialog on

"Would you like to not continue saving in the original OpenOffice.org 2.0 format or perhaps switch to another format"

that takes 10 seconds to parse each time ( presumably since it's a recent feature - with a specification too ).

The rest of us mere-mortals know that the OO.o is shockingly broken - and hence are eager to fix it without being blocked & frustrated for weeks by those responsible for the current mess.

A number of the changes / patches in apply/ are blocked on 'user experience' feedback.

different defaults

It is self evident to ooo-build users that a slew of dialogs on 1st run is a painful mess; eg. if there are settings to migrate, don't shout about it - do it silently. Furthermore - the registration dialog looks tacky, we disable both. We also alter a number of other defaults. cf. the last point - I'm optimistic that these will ~never get up-stream agreement.

bleeding-edgeness

There is a 'cool factor' to building the very latest things yourself; and helping solve problems with them. It's nice to be able to see your changes have an effect & help others rapidly, eg. a fix being immediately useful to other people. Of course - you can have too much of a good thing here but ...

Philosophical differences

compatibility

Up-stream believe that the most important data set to be compatible with is existing StarOffice / OO.o users. ooo-build users believe that nearly all the world's data is stored in Microsoft Office format - hence we sacrifice legacy support for better interop. This is of course a continuum, up-stream are at the luny extreme of pushing back-compatibility regardless of it's impact on interoperability, even in cases deliberately excluding useful interoperability improvements on that basis. ooo-build appreciates backwards comaptibility, but is in favour of viewing core differences that are non-interoperable as bugs not features.

process complexity

ooo-build users believe in programmer lead development, with strong peer review and user QA. up-stream believe in process based development, with teams, consensus building, specification writing, test-instead-of-detailed-code-review-or-unit-testing, and all these 'Professional' pasttimes. ooo-build users believe the OO.o we have today is broadly a product of these processes. Up-stream users believe the previous sentence is a compliment.

cross-platform

ooo-build enables patch sub-setting, thus we include patches for features (eg. Mono integration) that are most likely not well separated, and will break the Win32 build. Of course, for ooo-build these are not enabled on Win32 thus causing no problem. This is an impediment to getting work up-stream. Hopefully the 'experimental' process may help encourage good behavior here.

Conclusion

If you read all that don't get depressed - these issues can all be fixed - many of them almost painlessly. We hope to shrink this page quickly.

Personal tools