On Tue, Mar 07, 2006 at 10:21:35AM -0800, Keith M Wesolowski wrote:

> One hopes that his actions are logical, but they're not all programmatic.

Many are, though.  At present, since we're teamware based, the following
happens:

  - gateling does a putback

  - putback sends a message to a handful of aliases, defined in the
    Codemgr_wsdata/notification file:

    - one alias forwards the putback message to the internal ON community, so
      people know when things come into the gate

    - one alias archives the message, in a per-build mailbox

    - one alias pipes the message into a short script that does super basic
      style-checking -- it runs cstyle, jstyle, hdrchk, etc.  All these
      checks should have been done before putback via wx, like Liane said.
      The output of this is sent to the gateling, as well as the
      gatekeepers, so that it can be corrected in short order.

      Through a different script, this alias also sends a message to the
      gateling letting saying what build the bug has been fixed in, and
      some explanation about what can be done to the bug in question.  For
      those who saw my previous post today about "I can automatically mark
      the bug as fixed", that's where this would go, logically.

      Another script attached to this alias maintains our internal web page
      archiving our flag-days and heads-ups.  This page includes references
      to all ARC cases that get put back, which is what happens here.

    - one alias does some mangling for opensolaris that Steve Lau can explain

    - the last alias does a boatload of stuff:
      - checks to make sure that the RTI for each bug listed in the putback
        is approved
      - creates a file containing the diffs that the putback introduced
        (due to teamware limitations, this is done by keeping another gate,
        oddly called "daily", which is kept exactly one putback behind the
        main gate, and is what the diffs are done against).
      - mails out the diffs to interested people
      - creates a codereview.ps file for the change (see codereview(1))
      - creates a webrev for the change (see webrev(1))
      - if the putback is related to a manpage or doc bug, notifies the
        appropriate manpage and doc-writers that they need to get crackin'
    
    Note that this email notfication is almost all that teamware has in the
    way of hooks, which makes all of the checking we do racy.  Teamware
    does have a pre-putback hook of sorts, but it's very intrusive, which
    has prevented me from hooking it up,  I'm hoping (expecting, really)
    that this will change when switching to the new SCM.

  - The gatekeeping staff scans the email that gets sent out to make sure
    that nothing obvious is broken.  If we catch an egregious problem
    quickly enough, we'll undo the change.  If it's not so bad, or we don't
    catch it in time, a backout may be appropriate.  Usually, though, a
    simple follow-up putback is more appropriate, as it's lower overhead
    for everyone involved.  Multiple follow-up putbacks are discouraged,
    and often send the gatekeepers into seething rages.

  - A periodic cron job pulls each change (or all changes that happened
    within the period) and builds an incremental on both sparc and x86.
    These check for almost all build errors, and we do a lint check on
    sparc as well.  Unless there are debug-only errors that happen on x86
    or non-debug-only errors that happen on sparc (or unreferenced files,
    which can't be caught in an incremental), we can often get major
    problems corrected or backed out before the bad bits get into the
    nightly build.

Although much of the functionality here is new for Nevada (the result of me
being laaaazy), the structure dates back into the distant, murky past.
I'll let previous gatekeepers justify those decisions.

Obviously much of this work will need to be re-done given the switch to the
new SCM.  My hope is that we can be more rigorous and thorough in our
checking (/me ignores groans from the cheap seats), and when that
transition happens most, if not all, of that code will become a formal part
of the gate, and will move out into opensolaris.

> > Since stuff with semi-sentient-intelligent systems (in this case,
> > sanity checks / test suites on the putback code) falls right into my
> > domain, the code gates picqued my interest. That's all.
> 
> I'm sure Danek will take some offense to the "semi-sentient-intelligent"
> label. :-)

Eh, huh, what?  Hrm.  Where's that any key?

Danek
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to