"Roger A. Faulkner" wrote:
> > > So the next time we have a lint party (we used to do them every
> > > couple of years), we can easily identify the lint-dirty sources.
> >
> > What if the sources are externally maintained (e.g. "perl", "ksh93") ?
> > Is there a procedure to say "... provide lint fixes to upstream..." ?
> 
> Well, we just punt on perl with this in the Makefile
> (since no one at Sun will ever attempt to sanitize it):
> 
> # Perl is not lint-clean.  Fake up a target.
> lint:
>         @ $(ECHO) "usr/src/cmd/perl is not lint-clean: skipping"
>         @ $(TRUE)
> 
> As for ksh93, we'd have to invent the procedure.
> I certainly hope that making the code lint-clean would be viewed
> favorably by the community

See
http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-June/002640.html
- most of the compiler warnings and similar stuff have already been
slaughtered.

> and that pushing such changes upstream
> would be straightforward.

That worked perfectly in the whole last year. We've updated the
ksh93-integration prototype tree incrementally for each alpha/beta/final
version between ksh93r up to ksh93s+_beta and patches were accepted by
upstream without any problems.

> Ditto for bug fixes (or have you fixed
> the last bug in ksh93? :-)

Grumpf... no... do you want to see my list of "major" items still open
in ast-ksh.2007-04-18 (which is the basis for this putback (disclaimer:
None of these bugs are "critical" and ksh93 passes the testsuite and it
capable of replacing /usr/bin/ksh in it's current version without
problems, too)) ? There is still _lots_ of work which needs to be
done... ;-(

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) [EMAIL PROTECTED]
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to