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
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.
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.
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.
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.
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.
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.
>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.
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.
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.
Regards
Kay
Regards,
Bernd
Thorsten Ziehm wrote:
Hi Bernd,
> If you want a formal process than I would propose to get the following
> into QA processes:
>
> Don´t nominate a CWS if tinderbox status is red without checking
> together with the owner first if it´s OK that the status is red.
The QA rules [1] should be changes only, when the developer (owner of
a CWS) knows, what to do, when the CWS is rejected. So for all teams
a definition or a process have to be defined for this new tooling.
That is what I miss.
> I do believe a rule to not nominate when known to break on a platform
> already is there in our processes, is it?
The QA couldn't check this until now. The QA representative gets an
install set and for Sun internal patches. It is required to get builds
on 2 platforms. If one of the other platform is broken, nobody take care
until now. And especially for Mac. Sun internally we do not test Mac, so
how should be take care of this.
Thorsten
[1] : http://wiki.services.openoffice.org/wiki/Approve_a_CWS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
