cvs commit: src/lib/libc/stdlib getenv.3 getenv.c putenv.c
setenv.c src/sys/sys param.h src/usr.bin/limits limits.c
src/usr.bin/env env.c src/usr.sbin/sysinstall main.c variable.c
src/usr.sbin/pstat pstat.c src/usr.sbin/sade main.c variable.c ...
ache at freebsd.org
Tue May 1 18:52:50 UTC 2007
On Tue, May 01, 2007 at 01:12:12PM -0400, Daniel Eischen wrote:
> > Not because I admit they are technically wrong and not because of bug
> > reports (I receive nothing). But because I surprisingly meets so
> > strong opposition and resistance so lost any desire to continue that.
> Uh, please put them back in. This is -current and we do want
> to be conformant with POSIX where possible.
And I think exacly so, but read others negative opinions and my answers
explaining why I disagree with each point respectively, if you wish. There
is lots of strange things like people falsely accuse me that I stamp
to other shoes changing the code even without reading my code, treating
putenv() like BSD POLA even not looking first where it appearse and so on.
Then imagine what happens in case first broken port will be ever found.
The same wave again, with new persons added with the same points, I can't.
I perefer technical concrete real reasons (like "what is broken?") and to
write/fix soft, not to talk and feel pressure. Especially when talk is so
I really have bad luck because this changes are nothing compared to f.e.
objformat disaster we hit (and still not recovered until now), but
strangely I don't saw such strong resistance or opposition to objformat
removing or strong demands to return it back (in the matter of question, I
think objformat removal is good).
I almost agree with two opinions only:
1) We are in the code slush, changes must be reviewed by re@
2) We need to discuss/test that before commit.
And Backout will be good for this two.
Now changes are in the cvs diffs form and re@ or anyone other are able to
review/test, if they wish. In case changes will be found acceptable at
some moment, anybody is free to commit them too, I can't. If someone will
be lacky enough to restore them in any form I promise my help fixing
software bugs in case they appearse.
Back to the matter - why I don't do that initially? I never thought that
minimal code (most files are 1 line changes) cleanly implementing
standards conformance may require special re@ attention or
before-discussion because I already fix all base and expect only few ports
failing (if any, because ports are usually portable or Linux supported).
More information about the cvs-src