Hi Bernd,
Bernd Eilers wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
Hey,
Hey Kay,
I am glad that I read the QA list ... :-) So, I just found out, that
since Bernds mail, changes in a CWS need to be Tinderbox compatible.
Mhhhhmm, ->Bernd, change acceptance isn't your biggest strength, is
it? (No flame intended, I promise you a beer if you are offended :-)
Well, I am not offended at all. Tinderboxes have not been MY invention
they did exists for quite some time know. All I did was to react to the
community request to make them more visible by integrating their result
into EIS. What to do with this enhanced visibility is NOW up for
discussion and that´s just started here. I didn´t start a process or
Ohh, good, I understand.
introduced a rule or a change all I did was to make stuff others in the
community do more visible. If you think we need rules on how to react to
the results of their work, well that´s fine and a good thing, let´s go
ahead and discuss on what we would like to do next here.
OK
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. 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, 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.
I am a fan of good cooperation anyways ...
This all could also have happened without the enhanced visibility in
EIS, of course.
OK.
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.
Mmmhhh, yes and no, I just have the feeling, that it would be too much
overhead.
My personal opinion is that if it looks like that developers-X changes
on a CWS might eventually break the build on any other established
platform we shouldn´t integrate the CWS but seek for help from
developer-Y being expert on that platform. Developer-X would likely
generate work for Porters (developer-Y + developer-Z) on that other
platform anyway but waiting with integration gives them at least a
chance to have a look at the potential problem when they have time to do
so on the CWS and let´s Developer-Z also working on that platform
continue with other important work on the MasterWorkspace. But hey well
I am only maintaining EIS and mostly likely neither in the developer-X
or developer-Y or developer-Z group so my personal opinion is not of
much weight here.
I certainly appreciate your opinion here.
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.
I fear, that turnaround times are too high. So, OOo builds from scratch
on a local Linux box in under an hour, which nearly is "real time" :-) I
don't know how fast e.g. Mac can build?!
By the way, it would be nice, to offer a buttom to retrigger tinderbox
builds,
I have also heard that feature wish already and I think too that this
would be a nice idea. But as far as I know that´s currently not possible
with how tinderboxes currently work. If it becomes possible to trigger
tinderbox builds somehow i would surely offer to provide a button for
that in EIS also.
Obviously I have to inform myself some more ...
>and certainly a buildbot would be nice as well.
Speaking about buildbots: TERMITE is now also visible in EIS you can
find that at the menu at "MISC / Termit Main Page". There are Wiki
entries for Termite and Tinderbox on OOoWiki.
Is there are fundamental difference between tinderboxes and buildbots? I
thought tinderboxes are kind of similar, with the difference, that they
don't need to be triggered manually.
And, as the tinderbox stuff seems to be important, I would have at
least expected a discussion on [email protected], as this affects all
OOo developers ...
Well I admit that was certainly my mistake that I just wrote the feature
mail and didn´t start such discussion. I must admitt that I just
integrated the enhanced visibility of the thing in EIS without thinking
about importance or unimportance of it.
OK.
What might make it important is those people looking at the results of
tinderbox builds and pointing developers to it´s LOGfiles saying hey
look there do you think you might just have created a problem and that´s
what just happpend and that´s why we are now having this discussion.
Good.
Regards
Kay
Regards,
Bernd
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
