Date: Sun, 18 Feb 2007 15:54:53 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org, Joel Dahl <joel@FreeBSD.org> Subject: Re: cvs commit: www/en/projects/ideas index.sgml Message-ID: <20070218155453.5m1oglt3i804oko8@webmail.leidinger.net> In-Reply-To: <20070218113835.H49018@fledge.watson.org> References: <200702161712.l1GHCX81057433@repoman.freebsd.org> <20070217154631.v9su1z6uscsoggsk@webmail.leidinger.net> <20070217193246.M63360@fledge.watson.org> <20070218123225.f9wuaidqsswc0kk0@webmail.leidinger.net> <20070218113835.H49018@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Robert Watson <rwatson@FreeBSD.org> (from Sun, 18 Feb 2007 =20 11:46:44 +0000 (GMT)): > > On Sun, 18 Feb 2007, Alexander Leidinger wrote: > >> Quoting Robert Watson <rwatson@FreeBSD.org> (from Sat, 17 Feb 2007 =20 >> 19:37:48 +0000 (GMT)): >> >>> On Sat, 17 Feb 2007, Alexander Leidinger wrote: >>> >>>>> - Magic symlinks: Several implementations exists, so we don't need mor= e >>>>> people looking at this right now. >>>> >>>> But we need people reviewing them and chosing the right one. So =20 >>>> the entry needs to be changed instead of removed. >>> >>> I think an alternative explanaation is that people have looked at =20 >>> them and been left sufficiently worried by the experience as to =20 >>> wonder whether "magic symlinks" are really a good idea. I think =20 >>> we should take it off the list before we get yet another set of =20 >>> patches that won't be accepted for the same reason. >> >> There are mixed feelings about this in the responses. AFAIR it can =20 >> be summarized to: If it is not enabled by default and needs to be =20 >> activated even when compiled in (sysctl), then nobody will object. =20 >> The crowd which is interested in the magic symlinks would be happy =20 >> 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. Ok. >> If an entry is removed completely because it is inappropriate we =20 >> should list it somewhere and explain why it will not be accepted in =20 >> 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 I don't want to put everything up there. It's more like a FAQ list, =20 but instead of questions there are rejected ideas. Magic symlinks come =20 up from time to time. So it is a candidate for such a rejects-list. > 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 =20 >>> the point where most entries would be zombie entries. How about =20 >>> we have a separate page on projects that are currently in =20 >>> progress? People go to the ideas page, one presumes, to find =20 >>> things to work on, so we should only list things that are new =20 >>> ideas to be worked on. >> >> The metaphor behind my idea about the zombie entries can be =20 >> visualized like as the plug-in window in firefox. It tells you the =20 >> current status and when you click on update it will show te =20 >> plug-ins which can be updated. When you update them the state =20 >> changes in the list. >> >> Your proposal can be visualized as two tabs, one with the plugins =20 >> for which updates are available (open ideas), and one for the =20 >> plugins which will be activated at next (re)start (nearly finished =20 >> ideas). >> >> For the firefox plugins the current way is more appropriate. For =20 >> our ideas list I see good points in both approaches. I can't really =20 >> say one is more appropriate than the other. A variation of the =20 >> zombie entries idea is to have a separate paragraph for the nearly =20 >> finished stuff. >> >> My main motivation is to show the progess we make. Sometimes I get =20 >> drive-by questions about the status of some of the entries. So our =20 >> userbase definitivly wants to know about the progress. As long as =20 >> we inform them instead of just removing the entries, It's ok for =20 >> me. I don't care that much if this is inline, as a separate =20 >> 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 It's not the same scope. While each entry in the ideas list is a =20 project on its own, it is most of the time not a big picture project =20 like SMP or netperf. The linuxulator entry on the ideas list for example is a project which =20 would be suitable to put on the projects page. It is not there but we =20 have some wiki pages about it. The wiki is more suitable for this =20 instead of a projects page in CVS. There are contributors which are =20 not committers which run for example the linux test project tests on =20 amd64 hardware and update the status page in the wiki. We can add a =20 link from the project page to the wiki pages, but I prefer a link from =20 the ideas list to the wiki page. A link from the project page looks to =20 me like there's a team working on this and they are proceding just =20 fine, while a link from the ideas page actively shows that a project =20 wants/needs help. On the other hand, the ideas entry to extend dump/restore for better =20 UFS2 support (backup of extended attributes) is not a big picture =20 project which I would put up on the project page. > same love and care that the ideas page is getting? Or would you rather Someone who is willing to put some love into the project page would be =20 nice. There are several projects which seem to be dead. And if someone =20 would want to continue with some of those projects he would need to =20 restart from the beginning. So the page needs clearly a helping hand. =20 Maybe we should put up an entry on the ideas list, maybe a volunteer =20 is willing to ping all listed people about the status to determine if =20 it is still worthwile to have all projects listed as they are ATM. > we repurposed the current projects page to be a new ideas page, and > pointed at that for new ideas instead? In my eyes those 2 pages have different intentions while having a =20 little bit of overlapping stuff. The stuff they have in common is not =20 large enough to merge them. Bye, Alexander. --=20 If at first you do succeed, try to hide your astonishment. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070218155453.5m1oglt3i804oko8>