On Sun, 18 Feb 2007, Alexander Leidinger wrote:
Quoting Robert Watson <[EMAIL PROTECTED]> (from Sat, 17 Feb 2007 19:37:48
+0000 (GMT)):
On Sat, 17 Feb 2007, Alexander Leidinger wrote:
- Magic symlinks: Several implementations exists, so we don't need more
people looking at this right now.
But we need people reviewing them and chosing the right one. So the entry
needs to be changed instead of removed.
I think an alternative explanaation is that people have looked at them and
been left sufficiently worried by the experience as to wonder whether
"magic symlinks" are really a good idea. I think we should take it off the
list before we get yet another set of patches that won't be accepted for
the same reason.
There are mixed feelings about this in the responses. AFAIR it can be
summarized to: If it is not enabled by default and needs to be activated
even when compiled in (sysctl), then nobody will object. The crowd which is
interested in the magic symlinks would be happy with this solution too.
No, I disagree. We will not accept security holes that are disabled by
default if the primary purpose of the feature is to cater to environments in
which the feature will be a security hole. This is a property of at least one
of the patches submitted to date, and my feedback along these lines was (I
seem to recall) entirely ignored. Please stop asking people to implement
magic symlinks unless you are willing to provide the necessary oversight to
make sure that we don't get yet more patches that represent security holes.
If an entry is removed completely because it is inappropriate we should list
it somewhere and explain why it will not be accepted in the tree.
I think we shouldn't try to enumerate everything that is a bad idea because
that list is very, very long. Instead, we should stop asking people to do
things that we think are bad ideas. If there is a variation on the theme that
could potentially be a good idea, but we've had several submissions that are
not good ideas to date, then it's clear having it on the ideas list isn't
helping matters.
I have mixed feelings about "zombie" entries since we've reached the point
where most entries would be zombie entries. How about we have a separate
page on projects that are currently in progress? People go to the ideas
page, one presumes, to find things to work on, so we should only list
things that are new ideas to be worked on.
The metaphor behind my idea about the zombie entries can be visualized like
as the plug-in window in firefox. It tells you the current status and when
you click on update it will show te plug-ins which can be updated. When you
update them the state changes in the list.
Your proposal can be visualized as two tabs, one with the plugins for which
updates are available (open ideas), and one for the plugins which will be
activated at next (re)start (nearly finished ideas).
For the firefox plugins the current way is more appropriate. For our ideas
list I see good points in both approaches. I can't really say one is more
appropriate than the other. A variation of the zombie entries idea is to
have a separate paragraph for the nearly finished stuff.
My main motivation is to show the progess we make. Sometimes I get drive-by
questions about the status of some of the entries. So our userbase
definitivly wants to know about the progress. As long as we inform them
instead of just removing the entries, It's ok for me. I don't care that much
if this is inline, as a separate paragraph, or as a separate page.
People go to the ideas page to find ideas for things to do. Things already
being done that don't need further help aren't things left to do. We have at
least one web page for in-progress projects -- how about we move the
in-progress projects to that page and give it the same love and care that the
ideas page is getting? Or would you rather we repurposed the current projects
page to be a new ideas page, and pointed at that for new ideas instead?
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
