svn commit: r246362 - head/games/fortune/datfiles

Chris Rees utisoft at gmail.com
Tue Feb 5 17:14:12 UTC 2013


On 5 Feb 2013 17:01, "John Baldwin" <jhb at freebsd.org> wrote:
>
> On Tuesday, February 05, 2013 11:51:00 am Benjamin Kaduk wrote:
> > On Tue, Feb 5, 2013 at 11:45 AM, John Baldwin <jhb at freebsd.org> wrote:
> >
> > > On Tuesday, February 05, 2013 9:39:38 am Dag-Erling SmXXrgrav wrote:
> > > > Author: des
> > > > Date: Tue Feb  5 14:39:37 2013
> > > > New Revision: 246362
> > > > URL: http://svnweb.freebsd.org/changeset/base/246362
> > > >
> > > > Log:
> > > >   Remove political propaganda
> > > >
> > > > Modified:
> > > >   head/games/fortune/datfiles/fortunes-o.real
> > >
> > > *sigh*
> > >
> > > I'm sure there are other quotes that people who do not share your
political
> > > persuasion might find propaganda or offensive, etc.  Censorship and
freedom
> > > of speech is quite a sticky widget, and I think the only truly sane
policy
> > > is that fortune files are append-only (unless we outright remove them
and
> > > that seems excessive).  And new things should have a very high bar to
be
> > > added to fortune.  Perhaps we should move fortunes-o to ports
entirely?
> > >
> >
> > I am more concerned about the insta-MFC than the removal per se.
> > Only security or legal issues are cause to go under 3 days, was my
> > impression.
>
> Yes, the insta-MFC is also not appropriate, esp. for something that you
know
> is going to raise eyebrows when it is committed.  Having to debate this
sort
> of thing in public on mailing lists is also distinctly unhelpful and very
> distracting from productive work.  Also, I'd like to preemptively ask
> developers to refrain from any further commits to the fortunes datfiles
for
> the time being as the last thing we need is a commit war over this sort of
> thing.

Moving the -o file to ports as you suggested is probably the best idea.  Or
simply allowing people to fetch their own....  I don't see why we should
have trash installed by default on a professional operating system; we have
higher standards in other areas.

Chris


More information about the svn-src-head mailing list