Hi Maho, *, On Mon, Mar 19, 2007 at 12:30:19PM +0900, Maho NAKATA wrote: > From: Caio Tiago Oliveira <[EMAIL PROTECTED]> > Subject: Re: [qa-dev] Automated GUI Testing: What is a 'global' CWS and how > do we test it? > Date: Sat, 17 Mar 2007 16:04:32 -0300 > > > I meant: how to integrate the QA on Mac OS X with some non-Mac related > > CWS's. > > If someone is touching a file with Mac specific code and modifying the > > non-Mac specific part, he could break it on Mac and don't notice. > > Yes. This is the main problem. Practically, but after the integration, > we can submit patches and can integrate after a few milestones, having > discussion > with Ono-san. Is it a really big issue?
If it is a *known* build-breaker: Sure it is a big issue > I'm not talking about RC process. > Hamburg QA team has done QA of global CWS > for all platforms; GNU/Linux, Solaris, and Windows. mingwport03 cws is a > global CWS. > However, MacOSX build was broken. So you still say: Mac is a minor platform with less "rights" than the other ones? > IMHO, implementing as policy for including build ability for other platform is > not good for ordinal development cycle (not RC) CWS nomination process. > Because: > > 1. CWS nomination process. > Hamburg team should handle CWS nomination process. I don't think others can > handle. > They are not only doing buildablity check for GNU/Linux/Windows(4nt)/Solaris > but > also doing QA. (this is what Jogi wrote before) "buildability" checks are done by tinderbox (or buildbot) in that case. > It is very very tough job. I understand why Hamburg QA/RE team only do QA for > specific > platforms. Their resouces are also severely limited. > We sometimes need patches for SRC680_m* as well. this is called master fix. > See below. > (Still enviromnet is bit different from outside of Hamburg, they do not use > configure) "sometimes"? Means: In the past. The last buil-problem patch needed for mach was for m196, after that you didn't need any patches to have it build anymore. (the icu runtime problem was fixed in m199) It is OK to have "master"fixes for stuff you didn't know about before. But if you already know that it breaks: Don't integrate. > 2. VCL testtool problem. That is totally different. In the scope of tinderbox and EIS, this doesn't matter yet. > 3. There are also practical way of doing things; raise as issues to keep it > buildable. > Problem here is mingwport03 cws breaks other ports. This is unfortunate > for such a big cws. Whether big or not doesn't really matter. It breaks. That is what matters. > [...] > Do we have to keep buildable for every milestone striclty without patches? Hell yeah. (I mean: This is one major point in having cws based development) Again: If you know about a build-breaker: Don't integrate. Of course, to every rule there can and will be exceptions, but these exceptions must be reasoned. One must state why the build-breaker was ignored. > I don't think so. Even for GNU/Linux, there are some milestones that need > pathces > for outside of Hamburg team. If fixes are trivial, we fix them as master > fixes. > http://www.openoffice.org/servlets/ReadMsg?listName=releases&msgNo=8529 They might be trivial, but why would you have 12 cws suffer from it (those that resynced to the now broken master (didn't know about the breaker) and those that have to delay the resync (because they know if the'd resync now, their build would break)) instead of delaying one single cws a couple of days? > [...] > Of course, situation will change if this some cws is included in the RC > process > for mature ports. So you really don't see the Mac port as a mature port. Kind of sad.. > My stand points are: > a. Not expect perfect for development cycle. it exhausts developers/resources. Having a broken master binds more ressources. Everyone who wants to build that master or a cws based on that master has to hunt for the necessary patches. (if there are any) > b. our resources are limited and we expect outputs are maximum ;) > c. there are practical way of keeping buildability. Yes. The simplest one is: Don't integrate a cws that breaks the build. > d. I'm not talking about RC process. > e. there are not so many unfortunate CWS like mingport03. If so many, we > expect > even stability and we cannot do porting! Yes, there are not many that break on one platform only, and fortunately there are even less that get nominated despite of a build breaker... Hence: If there are few anyway: Why is it a problem of dealing with those few cws that cause major problems? ciao Christian -- NP: Kid Rock - Black Chick, White Guy Join #qa.OpenOffice.org on irc.freenode.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
