> "Jim" == James Carlson writes:
JimC> How about this?
JimC> "This is the workspace in which the build will be done."
Yes, that works for me.
cheers,
mike
> "Rich" == Richard Lowe writes:
Mike> There does seem to be some sort of mismerge here (1704-1707),
Mike> though.
Rich> What do you see on the stated lines that's bad? The mail_msg file
Rich> should be constructed regardless of whether it's actually sent via
Rich> mail, no?
Never mind. I
Mike Kupfer writes:
> JimC> usr/src/tools/scripts/nightly.1
> JimC>
> JimC> 275: should add back in "This is the source to be built."
>
> I took that phrase out for a variety of reasons. In particular, it
> could be read to imply that only this source will be built, which will
> not be true fo
Richard Lowe writes:
> James Carlson writes:
> > usr/src/tools/scripts/cstyle.pl
> >
> > 194,203,211: why set this flag only when we print errors? It seems
> > to me that even if $no_errs is set, we should still return an error
> > code when something is wrong. (Shouldn't we?)
> >
>
> $no
James Carlson writes:
> Richard Lowe writes:
>> A webrev is available for prelim code review:
>>
>> http://cr.opensolaris.org/~richlowe/scm-review_90
>
> Completing the review notes from yesterday:
>
> usr/src/tools/scripts/cstyle.pl
>
> 194,203,211: why set this flag only when we print err
Mike Kupfer writes:
> JimC> 1707: uuoc
>
> I don't know what "uuoc" means. There does seem to be some sort of
> mismerge here (1704-1707), though.
UUOC -> Useless Use Of Cat
What do you see on the stated lines that's bad? The mail_msg file
should be constructed regardless of whether it's ac
JimC> usr/src/tools/scripts/nightly.1
JimC>
JimC> 275: should add back in "This is the source to be built."
I took that phrase out for a variety of reasons. In particular, it
could be read to imply that only this source will be built, which will
not be true for internal builds with separate (b
Mike Kupfer writes:
> Rich> usr/src/tools/scripts/nightly.sh
> [...]
> Rich> (old) 2199: Should this really go away entirely? What about the
> Rich> TeamWare case?
>
> See http://bugs.grommit.com/show_bug.cgi?id=264#c9.
Ah, ok. I think stevel and myself fixed another set of poss
Rich> usr/src/tools/scripts/nightly.sh
[...]
Rich> (old) 2199: Should this really go away entirely? What about the
Rich> TeamWare case?
See http://bugs.grommit.com/show_bug.cgi?id=264#c9.
mike
Richard Lowe writes:
> James Carlson writes:
> > As for the *.flg files, I might have to retract that comment for now.
> > The xref (cscope) tools use those *.flg files and make assumptions
> > about Teamware. Oh well. :-<
>
> The flg files are used in general, hence the changes to make flg.flp
James Carlson writes:
>> > 41,42: I don't think we should have exceptions here for SCCS
>> > directories or for Teamware ".del-*" files, as they'd represent
>> > errors if present. Perhaps these are things that `nightly' could
>> > add with a findunref command line option just when doing
Richard Lowe writes:
> James Carlson writes:
> > usr/src/tools/SUNWonbld/Makefile
> >
> > 31: unexpected change ... how did we grow GPLv2 on top of the
> > existing license? (See findunref.py comments below.)
>
> cdm, which is intimately familiar with the Hg internals. We talked
> this thro
Richard Lowe writes:
> A webrev is available for prelim code review:
>
> http://cr.opensolaris.org/~richlowe/scm-review_90
Completing the review notes from yesterday:
usr/src/tools/onbld/Scm/WorkSpace.py
Contains a number of XXX comments; these should be removed prior to
putback. (If the
Richard Lowe writes:
> Stephen Hahn writes:
> > Yes, and various Sun-specific steps we took during the DSCM change
> > have been completed/accepted for this change. So, if it's any
> > reassurance, it's getting to be more and more official. But I guess
> > what's being asked for is a com
Stephen Hahn writes:
> * James Carlson [2008-05-29 17:07]:
>> Stephen Hahn writes:
>> > > While for a change to slim_install or pkg-gate it would be valid, it's
>> > > absolutely wrong for others. The other alternative I can think of
>> > > (baking that knowledge into the code) is untenable, I
James Carlson writes:
> Stephen Hahn writes:
>> > While for a change to slim_install or pkg-gate it would be valid, it's
>> > absolutely wrong for others. The other alternative I can think of
>> > (baking that knowledge into the code) is untenable, I think.
>> >
>> > If there's another way to g
Stephen Hahn writes:
> Yes, and various Sun-specific steps we took during the DSCM change
> have been completed/accepted for this change. So, if it's any
> reassurance, it's getting to be more and more official. But I guess
> what's being asked for is a complete picture, which I don't per
Stephen Hahn writes:
> * Richard Lowe [2008-05-29 02:38]:
>> Richard Lowe writes:
>>
>> > James Carlson writes:
>>
>> >> usr/src/tools/onbld/Checks/DbLookups.py
>> >>
>> >> It'd be nice if this knew about defect.opensolaris.org. Lack of
>> >> direct support of open bug tracking in the n
Stephen Hahn writes:
> > While for a change to slim_install or pkg-gate it would be valid, it's
> > absolutely wrong for others. The other alternative I can think of
> > (baking that knowledge into the code) is untenable, I think.
> >
> > If there's another way to go about it, I'm open to suggest
* James Carlson [2008-05-29 17:07]:
> Stephen Hahn writes:
> > > While for a change to slim_install or pkg-gate it would be valid, it's
> > > absolutely wrong for others. The other alternative I can think of
> > > (baking that knowledge into the code) is untenable, I think.
> > >
> > > If there'
* Richard Lowe [2008-05-29 02:38]:
> Richard Lowe writes:
>
> > James Carlson writes:
>
> >> usr/src/tools/onbld/Checks/DbLookups.py
> >>
> >> It'd be nice if this knew about defect.opensolaris.org. Lack of
> >> direct support of open bug tracking in the new tools is going to be
> >> a
Richard Lowe writes:
> James Carlson writes:
>> usr/src/tools/onbld/Checks/DbLookups.py
>>
>> It'd be nice if this knew about defect.opensolaris.org. Lack of
>> direct support of open bug tracking in the new tools is going to be
>> a stumbling block for external committers.
>
> defect.op
James Carlson writes:
I'm responding to the bits I can as we go, these aren't so much
responses as "Here's why I recall things being this way".
> Richard Lowe writes:
>> A webrev is available for prelim code review:
>>
>> http://cr.opensolaris.org/~richlowe/scm-review_90
>
> I'll be issuing m
Richard Lowe writes:
> A webrev is available for prelim code review:
>
> http://cr.opensolaris.org/~richlowe/scm-review_90
I'll be issuing my comments in batches, in part because of the size of
the review. ;-}
One high level issue to deal with: the CR should be updated with a
summary of the m
Richard Lowe wrote:
> "James C. McPherson" writes:
...
>> these should have a 2008 copyright date:
>>
>> usr/src/tools/onbld/Checks/Cddl.py
>> usr/src/tools/onbld/Checks/CStyle.py
>> usr/src/tools/onbld/Checks/Comments.py
>> usr/src/tools/onbld/Checks/Copyright.py
>> usr/src/tools/onbld/Checks/DbL
"James C. McPherson" writes:
> Richard Lowe wrote:
>> "James C. McPherson" writes:
> ...
>>> these should have a 2008 copyright date:
>>>
>>> usr/src/tools/onbld/Checks/Cddl.py
>>> usr/src/tools/onbld/Checks/CStyle.py
>>> usr/src/tools/onbld/Checks/Comments.py
>>> usr/src/tools/onbld/Checks/Copy
Richard Lowe wrote:
> Hey all,
>
> A webrev is available for prelim code review:
>
> http://cr.opensolaris.org/~richlowe/scm-review_90
>
> We'd appreciate code review comments from anyone inclined to provide
> them, but scm-migration folks especially, at the moment.
>
> Deadline for comments
Richard Lowe writes:
> Hey all,
>
> A webrev is available for prelim code review:
>
> http://cr.opensolaris.org/~richlowe/scm-review_90
>
Not all of this is strictly review, but I thought it worth including
completely.
general
CAS changes should be done under a separate bug?
(though th
"James C. McPherson" writes:
> Richard Lowe wrote:
>> Hey all,
>>
>> A webrev is available for prelim code review:
>>
>> http://cr.opensolaris.org/~richlowe/scm-review_90
>>
>> We'd appreciate code review comments from anyone inclined to provide
>> them, but scm-migration folks especially, at t
Bonnie Corwin writes:
> Richard Lowe wrote:
>> Hey all,
>>
>> A webrev is available for prelim code review:
>>
>> http://cr.opensolaris.org/~richlowe/scm-review_90
>>
>> We'd appreciate code review comments from anyone inclined to provide
>> them, but scm-migration folks especially, at the mome
Richard Lowe wrote:
> Hey all,
>
> A webrev is available for prelim code review:
>
> http://cr.opensolaris.org/~richlowe/scm-review_90
>
> We'd appreciate code review comments from anyone inclined to provide
> them, but scm-migration folks especially, at the moment.
>
> Deadline for comments
Hey all,
A webrev is available for prelim code review:
http://cr.opensolaris.org/~richlowe/scm-review_90
We'd appreciate code review comments from anyone inclined to provide
them, but scm-migration folks especially, at the moment.
Deadline for comments is Friday May 29th.
As the name sugges
> "Jim" == James Carlson writes:
>> 441 P3 scm-migration-dev at opensolar... tools/Makefile.tools INS.pyfile
>> shou...
Jim> I think you can scratch this from the list of pre-internal-review
Jim> bugs.
Sounds good, thanks.
I'm going to create a bug for the internal review, and mark t
Mike Kupfer writes:
> 441 P3 scm-migration-dev at opensolar... tools/Makefile.tools INS.pyfile
> shou...
I think you can scratch this from the list of pre-internal-review
bugs. I've split it into a component to go into ON (CR 6680948) and
another to go into our gate. The part for our gate
James Carlson writes:
> Mike Kupfer writes:
> > 265 P3 scm-migration-dev at opensolar...SGS commands use sccs SID in
> > version...
>
> I think we need more discussion about this one before putting it on
> the stopper list for internal review.
After a brief off-line discussion, it looks like
Mike Kupfer writes:
> 265 P3 scm-migration-dev at opensolar... SGS commands use sccs SID in
> version...
I think we need more discussion about this one before putting it on
the stopper list for internal review.
The problem listed here is that "ld -V" grabs its version number
information fro
> "Rich" == Richard Lowe writes:
Rich> I still think it'd be a very good idea for us to go through the
Rich> code we have doing the same code review we expect others to do. I
Rich> think actual review will be far easier if we've done a second pass
Rich> and dealt with anything that really st
37 matches
Mail list logo
