Mark J. Nelson wrote:
> I guess I'm not imagining changes to nightly.sh that result in
> incremental build failures.
Heh. Actually, after reviewing the IPS flag day email[1], I think my
original text puts too much constraint on the person changing
nightly.sh. So I think the text should be
If developers must do a clobber build after merging in your changes,
you must send out a flag day notice to that effect. If incremental
builds will succeed with warnings, send out a heads-up notice so
that gatelings know not to worry about the warnings. If you're not
sure what will happen with an incremental build, it's okay just to
recommend a clobber build.
> >>> === Old/new Nightly ===
> >>>
> >>> * new nightly, new source
> >>> * new nightly, old source
> >>> * old nightly, new source
> >>>
> >>> Many developers run ##nightly## from /ws/onnv-tools/onbld/bin, which is
> >>> updated daily. In general, your new version of ##nightly## should be
> >>> able to build workspaces that haven't yet merged in your changes.
> >>> Note that a workspace might contain old source for the clobber phase
> >>> and then contain your changes for the "make install" phase. (See also
> >>> the section on "updates" below.)
> >>
> >> The warning about old clobber / new install bits seems unrelated to
> >> which version of nightly.sh you're using?
> >
> > Well, the point of the warning was not to assume that you're building an
> > "old" workspace or a "new" workspace, because the old/new status can
> > (but need not) change as a result of the pull. I'm open to other
> > wording. :-)
>
> I'm not sure it's worth the emphasis. The clobber portion of nightly.sh
> makes no such assumptions,
First, I don't think that's entirely true. For example, nightly.sh
currently has baked into it some knowledge of how the different proto
areas are arranged. And it has some knowledge of what things in the
source tree can be deleted without penalty. Even if you consider the
current code to be forward-compatible, since we're talking about
projects that change nightly.sh, someone might change the clobber phase
in a way that works perfectly in a new workspace but trashes something
important in an old workspace.
Second, the point is not so much about what happens during "make
clobber", it's about how nightly.sh determines what to do, and when it
needs to make those decisions. It took me two tries[2] to get this
right when I split out the closed sources into usr/closed. I would
prefer that future developers benefit from what I learned in that
process.
> * old nightly, new source: If this does not work, you will need to send
> a flag day note, preferably with an example of the failure mode.
> * new nightly, old source: You should make this work if it's reasonable
> to do so. Otherwise, you will need to send a flag day note, preferably
> with an example of the failure mode.
I believe this is mostly covered by the current text, except I'll add
verbiage about describing known/expected failure modes in the flag-day
email.
mike
[1] http://onnv.sfbay.sun.com/flagdays/pages/20100302184109.html
[2] See CRs 6366373, 6366785.
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
