Hi Bernd,
Le 16 mars 07 à 12:26, Bernd Eilers a écrit :
But, even after I have read the mails, I am not sure how to work
with this respectively to avoid build breakers in practical life.
E.g. I just set my latest CWS to "Ready for QA", despite the
MacOSX being red. I had somewhat a of clue what went wrong, but
was not really able to fix it, as I had no machine at hand. So, my
question is, what is the suggested approach to address such
issues? I currently see three options:
-a- ignore it, does not seem to be choice
-b- find somebody e.g. with a Mac and ask him/her to look at the
problem
-c- write an issue for the Mac port owner
IMHO that´s kind of a general question on how to develop when you
are developing in an Open Source environment. Someone else can show
you that what you just did might have a problem somewhere your
options are than to try to analyse that potential problem yourself
or to seek help or to ignore it it depends. If you are not a MAC
expert and the potential problem is a MAC specific one the answer
could be too seek help from the community.
I propose to analyse first what could be build breakers on Mac OS X,
caused by changes in cws for other archs/OS, and what can break other
architectures ?
AFAIK, the most important I have in mind ( I only build
OpenOffice.org since 4 years) are :
- compiler issues (builds fine everywhere excepted on Mac OS X) :
most famous is gcc-3.3 parser, bad templates writting, missing
parenthesis ...
- cws tested locally, and QA approved by the same people writting the
code
- headers not present, or not the same locations on Mac OS X
- bad cases .IF / .ENDIF in Makefile.mk for Mac OS X
- bad order in libs linking ( I remember several cases )
- removing Mac OS X specific code
- add X operating system libs and believe all other architecture will
build using them ( no #ifdef / #endif in the code )
- make changes for one OS and ignore (don't care ?) the consequences
in other.
- cws integrated friday late in the afternoon (no, I'm joking :) )
Lot of other build breakers I know will break several archs, and I
don't count them here :)
Now, *do we really be* a Mac OS X expert to solve build issues caused
by cws for other OS ?
=> I don't think so, but Pavel Janik , who does a lot of fixes, is
the most relevant specialist here, and will probably complete/correct
me.
Tinderbox build breaks and people pointing you at them by writing
comments about them into issues or CWS comments are just one of
many possible ways on how you can get feedback. And to be sure on
things it might of course also be the case that you didn´t
introduce a problem at all and it´s the testcase being wrong eg.
the tinderbox is not setup correctly,
hmm .. once configured, I always believed a tinderbox was robust ..
maybe I misunderstood
this is something which might happen with tinderboxes as well as
with any other type of automated testing. So well in such cases QA
(tinderbox maintainer, automated testing) than has to somehow work
together with development to look at where the problem really is.
This all could also have happened without the enhanced visibility
in EIS, of course.
Well what´s wrong with writing an issue and adding that to the CWS
so options b and c are IMHO fine, aren´t they.
From Mac OS X side : when we create a cws for Mac OS X we *always*
take care to NOT break other OS archs, and we *always* verify, or ask
in case of doubt.
Why could it be different for other OS and devs ?
For me :
first : a broken cws must *not* be integrated
second : they are a lot of possibilities to ask help, and inform Mac
people and discuss the issue. We have #ooo_macport channel on IRC :
simple and efficient in case of break and need of help (excepted
after 1:00 in the night ;) )
Last but not least, integrate such cws would introduce a broken master
ft be integra
IMHO, none of these options are suitable for practical life. The
only real solution (which needs to scale well) I scan see is, to
provide access e.g. to Macs, to allow a developer to fix the issue
him-/herself.
*hmm* my understanding is that access to macs is at least partial
available via buildbots provided by the community, but that´s
probably not what you meant, of course.
As I already wrote, it would be great to -at least- add ressources
for Mac OS X port in OpenOffice.org project. I'm sure it's easy to
find resources for a Mac ...
Regards,
Eric Bachard
