Hi Mathias, *, On Sat, Apr 28, 2007 at 03:11:06PM +0200, Mathias Bauer wrote: > Christian Lohmaier wrote: > > >> (1) If a tinderbox build is "red" it must be possible to find out the > >> reason within minutes, possibly with one or two mouse clicks. > > > > It is three clicks. > > EIS -> see the red status -> click on the tinderbox link (1) > > on thinderbox page -> click on "l L C" to open the popup (2) > > Within the popup -> click on "Summary log" (or full log) (3) > > I got reports from developers that it didn't work reliably in the past.
This probably was due to the cws already being in approved by qa or even nominated state. These were not tracked anymore. > If that had changed meanwhile an important blocker would have been > removed (IMHO). Fine. Yes. Now the nominated & approved by QA are still tracked and accessible. > >> (2) If the reason for the "red" state is that the build broke because of > >> a machine or infrastructure problem it should be ignored. > > > > Yes. > > Or more precicely: if the error log does not clearly show that the error > is caused by a compilation problem it should be ignored. Fine with me. But I think telling the other way is easier. It is easy to spot infrastructure problems like the one currently: anoncvs is out-of order thus checking out the sources will fail. Easy to tell from the summary log. The same for the other false "positives". Usually fairly easy to detect by looking at the logs. But no matter what: mention your reason in a comment in EIS "red tinderbox status is a false positive, becasue <blah>" > It's up to the > build process to provide useful error messages. Yes, but like any makefile based system, the error messages are usually from the compiler and should thus be self-explanatory. > >> (4) The developer that fixed the error must be able to restart the > >> tinderbox build immediately to get a result in an acceptable time frame. > > > > Nope, I disagree. This is not a must. > OK, let's say: in a reasonable time frame. "Immediately" is too much, I > agree. And even not: When there is no status available, QA/devs should not need to care. (when they're sure their change adressed the problem) But if you got a red status and ignore it, mention why you did so. > > Would you agree on rejecting CWS that break the build on one of the > > tracked platforms? > Of course not. Not sure whether this is a misunderstanding here or not. If I take you literally, you say it is OK to integrate stuff that breaks the build on Mac or Linux. > But in this case it's easy and fast to fix the problem, Hmm - this case? Can't follow. > rebuild and continue. In most cases (e.g. simple build breaker due to a > compiler error) this takes only a few hours, depending on the number of > platforms to rebuild. You're probably speaking of "inhouse" builds - that's not what I meant with "tracked platforms" - but I don't really see a hinderance here. > For me anything that takes more than a few hours to verify the fix for > the broken build is inacceptable. But that's only my opinion. You can use buildbot to verify your change if you cannot wait. But still you have to account for anoncvs delay. But still I don't think devs will sit and wait for a build to finish. Most breakers from Sun-cws are either because of "unclean" build-environments (missing headers or similar stuff), or because of compiler-specific errors (gcc parser bugs/different behaviour depending on the version of gcc) and thus rather easy to spot in the logs and usually easy to fix as well. > Other > people may have others. But at the end that doesn't matter. My main > objection against taking action regarding Tinderbox builds > immediately(!) is another one. Well, I believe in common sense, but that's apparently useless in the field of software development :-/ > As I said, there has been a team set up to install the process. But what's so hard about defining a goal: Don't integrate stuff that breaks the build. Tinderbox gives you a hint on that. If the build is red: /Have a look./ - nothing more asked for than that. Having a look at the logs. That's not rocket science. Then there are a few possibilities what to do after having a look at the log: If you cannot tell what's wrong with your code: * ask the porters/buildmasters for help/analysis * decide to ignore the status and state so in EIS If it is obvious why it breaks: * state you ignore it because it is a false positive (infrastructure,...) * fix your code (checkin all the stuff that's necessary, adapt for gcc-specific requirements, eleminate warnings to allow WaE-builds) > This was > decided by the Release Status Meeting and we should do what is decided > there. So I think we shouldn't rush things and we shouldn't take an > immediate action like it was suggested by Thorsten. Let's wait for the > results. And whatever is decided, let's give it a test for a few weeks > until we make it mandatory for all developers. There's no black and white here only. Red status doesn't automatically mean: reject. (and shouldn't mean that). Red status should just mean: Have a look. > It is totally inacceptable that new processes are created and people > must follow it without being asked before and without reacting on their > objections. I really cannot see the problem here. "Must follow". "Without being asked", etc. The new status has been announced, nobody reacted. Then it was reannounced more prominently. Again silence. Then when somebody told another one that somewhere there is that new rule about automatically rejecting red status-cws (what never was requested or decided upon) people start complaining/whining about not being asked or whatever :-( But I'm back on the common sense thing I guess. > BTW: we didn't have Tinderbox builds for years. We had tinderbox builds. The status just wasn't listed in EIS directly. > We should be able to > wait some more weeks until a process has been established that is > supported by all involved parties. See above. I guess you're trying to overdo it with the "process". ciao Christian -- NP: Machine Head - Now I Lay Thee Down --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
