Rich tried posting to the temporary list that Ken had set up, which
didn't work, so he asked me to forward this. I think after this
message we can all go back to using scm-migration-dev.
mike
------- Forwarded Message
Subject: Re: thoughts about 'buglist' script
From: Richard Lowe <richl...@richlowe.net>
To: Mike Kupfer <mike.kupfer at sun.com>
Date: Thu, 04 Oct 2007 17:12:03 EDT
In-reply-to: <200710041904.l94J4kG7112602 at punchin-kene.eng.Sun.COM>
Ken Erickson <ken.erickson at sun.com> writes:
> So, I am re-sending this because for some reason the scm-migration-dev
> list is broken for me and won't send my emails...thinks I'm not on the
> list...whatever...that's what /etc/mail/aliases is for anyway...
>
> So, anybody have thoughts on this before I start on the gate scripts?
> ------------- Begin Forwarded Message -------------
>
> Date: Thu, 4 Oct 2007 10:17:00 -0500 (CDT)
> From: Ken Erickson <kene>
> Subject: thoughts about 'buglist' script
> To: scm-migration-dev at opensolaris.org
>
> So, while thinking about modifying the buglist gate script, I
> was thinking of an overall architectural issue, namely email
> notification of changes to the gate.
We have that up and working already with the bridged gate (and all the others).
> We currently have teamware send email to all gatelings whenever
> a putback or undo occurs. This email is also archived in a mailbox
> format file (which is how we get the buglist when the build closes).
We don't need to do that, that exists because the *only* real method
TeamWare has for hooks and various other things are the mail-based
hooks (putback-to, et al.).
> Anyway, how will commit notifications be handled using hg? Has there
> been a policy decision about this? Will a hook be used to email
> the changes to a list? If so, then buglist really doesn't have
> to change much.
Yes, they'd continue going to onnv-notify, at least in part.
buglist would be better served using the logs, however.
hg log -ronnv_74:onnv_75 --template '{desc}\n' | gegrep '[0-9]{7}'
Where from-rev, and to-rev could be specified, of course.
Are Dave Marker etc, on the alias you're using to workaround the mail
issues? A lot of this stuff is reasonably their choice to make...
> I guess what I am wondering is, are we planning to use hooks to
> closely mimic the current behavior of teamware, or is someone
> re-inventing something else? Or is this part of what I should
> be doing as I work on these gate scripts?
This kinda crosses boundaries.
The notifications are done, they go out via mail from the SCM hosting
infrastructure. Nothing (I've seen) in the gate tools actually needs
to know about that. I think the plan was for add-gateling to be
similarly infrastructure rather than script.
Dave had suggested, at one point, that it maybe easier to scrap most
of the existing stuff, find a machine to run as a pseudo-gate, and get
everything working as if it were a gate, then just use those bits. I
don't know how practical that is.
In general, the important bits of the gk stuff are the bits that don't
relate to actual workspace hooks (pbcheck, for instance, would be a
hook on the gate side, but I don't think it's part of the work on the
other gk stuff). I've been viewing it as mostly concerning those
parts related to the actual build and delivery.
> Have any decisions been made as to how a gate will run using hg?
>
Dave and I talked about it previously, from memory:
Gate is either inside or outside, it doesn't matter from the point of
view of this, mostly.
Gate machine brings over, starts its builds, etc, as it would now,
just with hg. But *must not* assume that the actual gate (sources)
are local to it or filesystem accessible. They will be at first, but
then either the entire gate, or part of it, will move to
opensolaris.org, and this will cease being true.
The clone isn't necessary, but is highly desirable, taken as now (but
with hg), open side pushed to opensolaris.org (Mike, do we want to
push it out from inside for right now, in general, or take it on
opensolaris.org?)
Daily snapshots, as now (I don't think these need to be pushed out,
but someone may disagree)
onbld update obviously runs as it does now, update_flagdays most
likely the same, though the latter *should* be an opensolaris thing.
Clone and snapshots can be shared actually read-only, they shouldn't
need the tricks currently used to deal with Codemgr_wsdata, for
instance.
Build would happen as now, in the case of SFW, out of Hg in general,
in the case of ON, src and closed out of Hg, IHV out of TeamWare, I
think. (unless someone intends to move those?)
Keep in mind the various things that either need to be pushed to, or will
eventually be on opensolaris.org, and try to avoid dependence on the
master copies being on SWAN.
-- Rich
------- End of Forwarded Message
