From owner-cvs-doc@FreeBSD.ORG Sun Feb 18 14:55:06 2007 Return-Path: X-Original-To: cvs-doc@freebsd.org Delivered-To: cvs-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20F4F16A401; Sun, 18 Feb 2007 14:55:06 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 70CD713C46B; Sun, 18 Feb 2007 14:55:05 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5F1A1.dip.t-dialin.net [84.165.241.161]) by redbull.bpaserver.net (Postfix) with ESMTP id 9EAE42E0A8; Sun, 18 Feb 2007 15:54:56 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id DFF205B482A; Sun, 18 Feb 2007 15:54:53 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l1IEsre2064511; Sun, 18 Feb 2007 15:54:53 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from proxy.Leidinger.net (proxy.Leidinger.net [192.168.1.103]) by webmail.leidinger.net (Horde MIME library) with HTTP; Sun, 18 Feb 2007 15:54:53 +0100 Message-ID: <20070218155453.5m1oglt3i804oko8@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Sun, 18 Feb 2007 15:54:53 +0100 From: Alexander Leidinger To: Robert Watson 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> In-Reply-To: <20070218113835.H49018@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org, Joel Dahl Subject: Re: cvs commit: www/en/projects/ideas index.sgml X-BeenThere: cvs-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the doc and www trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2007 14:55:06 -0000 Quoting Robert Watson (from Sun, 18 Feb 2007 =20 11:46:44 +0000 (GMT)): > > On Sun, 18 Feb 2007, Alexander Leidinger wrote: > >> Quoting Robert Watson (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