svn commit: r314464 - head/usr.sbin/yppush

[Rodney W. Grimes]

[ Charset ISO-8859-1 unsupported, converting... ]
> On Tue, 2017-02-28 at 21:53 -0800, Rodney W. Grimes wrote:
> > -- Start of PGP signed section.
> > [ Charset UTF-8 unsupported, converting... ]
> > > 
> > > 
> > > > 
> > > > On Feb 28, 2017, at 21:38, Rodney W. Grimes <freebsd-rwg at pdx.rh.C
> > > > N85.dnsmgr.net> wrote:
> > > > 
> > > > Would it be possible to not do this as 1000 commits?
> > > 	Yes, but I?m trying to do this in a way that allows me to
> > > backport all of the changes as easily as possible to ^/stable/10
> > > (on the other side of the coin, I?ve run into dependent commits of
> > > other MFCs that required sweeping changes in order to make my
> > > changes possible).
> > > 	I do think your point is valid though and I can probably strike
> > > some middle ground with my changes. I think grouping it up by 2nd
> > > level directory (like I did with usr.bin/svn) makes the most sense.
> > > Thank you,
> > Yes, that is what I was thinking.??Note that I dont agree with this
> > change,
> > but I have probably missed a discussion that is allowing it to move
> > forward.
> > It makes the logfiles of make output now src tree possition
> > dependent,
> > but I am probalby the only person in the universe that has ever run a
> > diff on the output of make world.
> > 
> > It may also be possible to split this into some phases to reduce some
> > of
> > your issues, only do the {.CURDIR}/../../foo -> ${SRCTOP}/bar/foo in
> > one pass and
> > some of the other fixes in another pass.
> > 
> > 
> 
> You're not the only one who has diffed build output logs (I suspect
> anyone who has to maintain a non-trivial build infrastructure has done
> so), and you're not the only one who thinks that changing relative
> paths to absolute is a bad idea.

Was there any @developers or @hackers discussion on this before
such a wide sweeping and non-trival change was undertaken?  I may
of wrongly assumed that this was discussed and though to be a good
idea for some reason(s).


-- 
Rod Grimes                                                 rgrimes at freebsd.org