Difference between revisions of "TinderboxAndEISStatus"
(→The technical aspect of tinderbox integration into EIS) |
|||
| (21 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category: Release Meeting]] | [[Category: Release Meeting]] | ||
| + | [[Category:Tinderbox]] | ||
== The technical aspect of tinderbox integration into EIS == | == The technical aspect of tinderbox integration into EIS == | ||
| Line 19: | Line 20: | ||
4.) A link to that Wiki page is available with a help bubble right behind the tinderbox headline above the tinderbox status messages on the CWS Overview page making this information easily accessible. | 4.) A link to that Wiki page is available with a help bubble right behind the tinderbox headline above the tinderbox status messages on the CWS Overview page making this information easily accessible. | ||
| − | 5.) [[EIS]] now delivers the list of to be checked [[CWS]]/[[MWS]] with one single SOAP call fixing a performance problem between [[EIS]] and [[tinderbox]]. | + | 5.) [[EIS]] now delivers the list of to be checked [[CWS]]/[[MWS]] with one single SOAP call fixing a performance problem between [[EIS]] and [[tinderbox]]. And since the switch tinderbox also tracks approved and nominated [[CWS]] (formerly the logs of those [[CWS]] were no longer available via [[tinderbox]] pages) |
6.) A potential problem that the [[tinderbox]] might try to start a build before modules have been added to the [[CWS]] and the status might get red in that case because there are no modules and that this happend even before the developer did do anything has been resolved. This fix was a side effect of 5.) | 6.) A potential problem that the [[tinderbox]] might try to start a build before modules have been added to the [[CWS]] and the status might get red in that case because there are no modules and that this happend even before the developer did do anything has been resolved. This fix was a side effect of 5.) | ||
| Line 29: | Line 30: | ||
9.) Only open issue IMHO is the feature wish to be able to tell [[tinderbox]] to restart a build in case of a failed build caused by things other than problems in the source code like network failures, anoncvs problems etc. | 9.) Only open issue IMHO is the feature wish to be able to tell [[tinderbox]] to restart a build in case of a failed build caused by things other than problems in the source code like network failures, anoncvs problems etc. | ||
| − | + | 10.) [[Buildbot]] builds from http://termite.services.openoffice.org now are available in EIS, since the logs are now sent to the tinderbox. | |
| − | + | 11.) In case of there is a major problem with anoncvs which is used by [[tinderbox]] we need to announce that because it makes [[tinderbox]] results unusable. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
==> IMHO technically there is nothing left to be clearified "for integration the result of the tinderbox into the QA approval process." | ==> IMHO technically there is nothing left to be clearified "for integration the result of the tinderbox into the QA approval process." | ||
| − | |||
== The Community aspect == | == The Community aspect == | ||
| Line 55: | Line 48: | ||
So it looks like it is already partly being integrated into QA approval process whoever that did informally before the Release Meeting decided on and announced a policy ;-) | So it looks like it is already partly being integrated into QA approval process whoever that did informally before the Release Meeting decided on and announced a policy ;-) | ||
| + | |||
| + | == Further suggestions == | ||
| + | |||
| + | We need to define a responsible person who would announce relevant infrastructure outages, eg. breakage of anoncvs sync, on QA and DEV mailing lists. | ||
| + | |||
| + | If new [[tinderbox]] platforms appear in the future they will be automatically also shown in [[EIS]]. | ||
| + | Maybe the release council should have to approve any additional platform to be "tinderbox red rule" ready ? | ||
Latest revision as of 12:42, 17 March 2010
The technical aspect of tinderbox integration into EIS
The initial "tinderbox EIS integration" feature was to show the tinderbox status of a CWS on the CWS Overview page if it is available.
Additional features and issue fixes done recently:
1.) There´s a new menu in EIS: MasterWorkspaces / Tinderbox status which shows Tinderbox information of recent Milestone tinderbox builds for comparison. This allows to easily find out if a build break is already on the master.
2.) Links to Tinderbox Overview pages which might be useful for QA and development and to the Tinderbox Main page have been integrated into the EIS menu
3.) A Wiki page RedTinderboxStatusInEIS has been created explaining how to get more information out of tinderbox if the status is red and what might be done in this case. This page may contain anything that will be defined as a policy in the future.
4.) A link to that Wiki page is available with a help bubble right behind the tinderbox headline above the tinderbox status messages on the CWS Overview page making this information easily accessible.
5.) EIS now delivers the list of to be checked CWS/MWS with one single SOAP call fixing a performance problem between EIS and tinderbox. And since the switch tinderbox also tracks approved and nominated CWS (formerly the logs of those CWS were no longer available via tinderbox pages)
6.) A potential problem that the tinderbox might try to start a build before modules have been added to the CWS and the status might get red in that case because there are no modules and that this happend even before the developer did do anything has been resolved. This fix was a side effect of 5.)
7.) Tinderbox now also checks OO*680 codelines, previously only SRC680 codelines had been checked, so that tinderbox information now becomes available for all public ChildWorkspaces. Also a side effect done with fix 5.)
8.) The "difficulty" that there is no MAC available inside Sun´s OpenOffice.org development department for testing potential bug fixes on Mac plattform is gone with recent events ;-)
9.) Only open issue IMHO is the feature wish to be able to tell tinderbox to restart a build in case of a failed build caused by things other than problems in the source code like network failures, anoncvs problems etc.
10.) Buildbot builds from http://termite.services.openoffice.org now are available in EIS, since the logs are now sent to the tinderbox.
11.) In case of there is a major problem with anoncvs which is used by tinderbox we need to announce that because it makes tinderbox results unusable.
==> IMHO technically there is nothing left to be clearified "for integration the result of the tinderbox into the QA approval process."
The Community aspect
Discussions took place on development and QA mailing lists from which possible policies and potential problems indiviuals might have with integrating or not integrating such a policy can be extracted. These discussions also did contain some explanations about how tinderbox actually works which might not have been known to stakeholders before and which might be useful to be moved into the existing tinderbox Wiki entry. At least one of the mails on that discussion informed that the Release Meeting will decide on a policy.
The Wiki entry CWS_Checklist_for_QA_responsibilities already contains the following sentence:
Check the status of the tinderbox in the Environment Information System. Is the status red the CWS has to go back to development.
Where tinderbox in that sentence is a link to that RedTinderboxStatusInEIS wiki page explained above.
So it looks like it is already partly being integrated into QA approval process whoever that did informally before the Release Meeting decided on and announced a policy ;-)
Further suggestions
We need to define a responsible person who would announce relevant infrastructure outages, eg. breakage of anoncvs sync, on QA and DEV mailing lists.
If new tinderbox platforms appear in the future they will be automatically also shown in EIS. Maybe the release council should have to approve any additional platform to be "tinderbox red rule" ready ?
