James McKenzie wrote:
Fridrich:
I would be willing to be a 'porter' but I'm running Tiger, which has not
been universally adopted. However, I will be sending in a signed JCA so
that I can assist in building and finding those patches that work and
those that do not.
Well done. Signing JCA is a good move. It does affect only your
contributions to OOo and only the stuff you have copyright for, so do
not be scared, you are not signing any treaty with devil :-).
Also, I would like to point out that there are a series of patches,
contributed by Patrick Luby, that Eric Bachard is trying to work back
into the current SRX645 series. With those patches, OOo 1.1.5rc3 builds
on MacOSX without further massaging on Tiger and Panther. I would like
to see someone assist Eric and get the effort completed.
I remember Eric complaining that it was not possible to resync the
macxjoin1153 CWS. It is possible that this kind of thing happens if you
are not owning the CWS. Just a first lesson :-) now about how to work
this around:
1) Check out a fresh tree of the latest milestone.
2) Create a CWS with the same modules included as the CWS that you
cannot resync.
3) CD to each module and execute following:
cvs up -d -j CWS_SRX645_<UPPERCASECWSNAME>_ANCHOR -j
cws_srx645_<lowercasecwsname>
Where cwsname is the old cws name. (For SRC680 simply replace the
SRX645, still respecting the uppercase for the anchor tag and lowercase
for the branch tag. This command merges into your new cws all changes of
the old one from the day of it creation to its current state.
4) If there are conflicts, crosscheck the files concerned and resolve
them. Like that, you will have a new cws containing the changes from the
old one
5) After these steps, you build a new tree a verify that it does
correctly. Note the modules that you had to modify in order to do it.
6) After the build was successful, add to the cws the additional
modules. Use "cwsadd -f <modulename>". "-f" will prevent the process to
overwrite the module changes with a clean checkout.
7) Module by module commit the changes.
8) Find a _sensible_ QA person who will be likely to build the CWS
speedily and set it "ready for QA".
9) If the QA finds a problem, she/he will report the problem in IZ,
assign it to you and set the CWS status to "new"
10) You solve the problem, commit the modifications and set the CWS
again to "ready for QA".
11) After of a serie of iterations of points 9 and 10, the QA will find
the CWS correct and set it to "approved by QA". At this point, your job
is to wait whether the Hamburg RE have any questions. If not, you will
see that your CWS will be "nominated" and "integrated".
That's for the lesson n° 1. BTW: there is a lot of documentation at
http://tools.openoffice.org
Are you willing to assist Eric in getting this accomplished so we can
find, fix and work back into the current MWS all of the patches.
ericb2 knows well that I am ready to help whenever one asks me. The
above-mentioned steps should help a lot.
And Eric is the point person on SRC680 as he has recently worked in
macosx10 as the most recent child work space.
Cheers
Fridrich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
