Re: MACOSX Porter sorely needed [Was: Donation request: small silent fast i686 box for Win mingw porting]

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