From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FurBz-0007SN-19 for garchives@archives.gentoo.org; Mon, 26 Jun 2006 13:31:55 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k5QDV07d020183; Mon, 26 Jun 2006 13:31:00 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k5QDUtMK029628 for ; Mon, 26 Jun 2006 13:30:58 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E6C5E65108 for ; Mon, 26 Jun 2006 12:44:55 +0000 (UTC) Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28210-10 for ; Mon, 26 Jun 2006 12:44:54 +0000 (UTC) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by smtp.gentoo.org (Postfix) with ESMTP id 1190765103 for ; Mon, 26 Jun 2006 12:44:53 +0000 (UTC) Received: by py-out-1112.google.com with SMTP id 39so1344327pyu for ; Mon, 26 Jun 2006 05:44:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kd7x9cgWGMsiczub5QXzceQtin/njjqU8yzVkWd/GW+iVKThvjGuOFep6FZU6s3zAPa1CI1AUSICv96ORakLd9bdg+VYjkvUIKjJshZ39IGDhDFAhE8ySa6bx8JUuMTeAJIvHgRpNXZmQa86aA5WsM/+NVLU+mTKTpLCm9PeswQ= Received: by 10.35.127.15 with SMTP id e15mr5923930pyn; Mon, 26 Jun 2006 05:44:53 -0700 (PDT) Received: by 10.35.100.2 with HTTP; Mon, 26 Jun 2006 05:44:53 -0700 (PDT) Message-ID: <7c612fc60606260544n6894792cvbad119d51220969c@mail.gmail.com> Date: Mon, 26 Jun 2006 14:44:53 +0200 From: "Denis Dupeyron" Sender: denis.dupeyron@gmail.com To: gentoo-science@lists.gentoo.org Subject: Re: [gentoo-science] Scientific Gentoo reorg: the proposal In-Reply-To: <200606252046.03386.george@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-science@gentoo.org Reply-to: gentoo-science@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200606252046.03386.george@gentoo.org> X-Google-Sender-Auth: 62629d9d5fe82ae8 X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Status: No, score=-2.216 required=5.5 tests=[AWL=0.183, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.216 X-Spam-Level: X-Archives-Salt: 35a65dd4-6753-44ba-8e1c-9c4c4781fa93 X-Archives-Hash: e23a4484363fdb4b73caf87a682634b0 On 6/25/06, George Shapovalov wrote: > 1. Make Scientific Gentoo a top-level and create subprojects > - this did not seem to get any complaints. So, when we are done with the > mainpart I'll try to update the page, like move it to a proper location, redo > the blurb and provide links to subprojects. Then I'll ask corresponding teams > to produce some descriptions for the corresponding subprojects (its the > same .xml essentially, just change the description paraagraph). But lets > first get done with the reorg itself.. Is the plan to have one subproject for each sci-* category ? > sci-biology: 58 > rather large, may be worth splitting more, no particular suggestions yet [...] > sci-chemistry: 50 > may be worth splitting up as well. One suggestion is to make a category for [...} > sci-mathematics: 34 > Ok size. There were calls to split it into symbolic and numeric, also -proof I'm not sure we should go from not enough herds to too many in one single step. I suppose the people managing the different subcategories will be the same anyway, so I fail to see the point here. Or is there some other problem you're trying to address that I don't see ? My opinion is that we may want to do this, but only as a second step at a later time, once we have some feedback on how the new organization works. I believe the problem is less about the number of packages, and more about the very specific topics touched by science apps. I would be totally unable to run a biology or crystallography app to check it works after I wrote the ebuild (I mean besides checking it doesn't segfault). Inside the sci-electronics category, to continue with me as example, I have no problem trying to run any app and playing with some examples or tutorials to verify it works. Even if it's not exactly my area, and even if it means that I need to invest some time in trying to understand what the app does and how. I know I will end-up understanding, which is definitely not the case with, say, a biology app (unless we have a package that's related to female anatomy). This said, once the packages are properly categorized, the number of packages only matters compared to the time they take to maintain (some are more complicated than others) and the number of devs maintaining them. Splitting categories into more sub-categories won't change that ratio. So I'd suggest we split packages based on topics, not on numbers. > sci-electronics: 34 > Ok size, devs: > calchan, chrb?, agriffis?, phosphan, ribosome, blubb?, plasmaroo, hansmi, > cryos?, gustavoz? I confirm that you can count on me for anything that's in sci-electronics. > sci-misc: 19 > Size is Ok, but, if we follow the idea, should probably stay under sci (herd) > devs: > cryos, hansmi?, phosphan, ribosome, kugelfang?, pbienst, blubb? Agreed. But it should be clear who maintains each of them, or that will become nobody. What I mean is that for any package in the other categories, the name of the (sub-)herd in the metadata is usually sufficient. For packages in this category, and in sci-libs by the way, we could require there is at least one dev name. > sci-cad was suggested and it looks like there may be a critical mass of > 5 > packages, but more planning is necessary on this one.. > > There was a suggestion for sci-phonetics or sci-linguistics. There is a dev > (translator's team, so he will need to be mentored for the "generic > development") who is willing to take on those, however I first need to see > how many packages would be there. If anything it will be good to have him as > a part of the team, even if this does not qualify for a full category (but > still should be good for herd I guess..) > > There were talks about creating sci-physics category, however I cannot find > traces of that atm (or was it on irc?). If there really are apps for > sci-physics it can start combined with sci-astronomy (or not, need a list of > packages..) We talked about this on irc already, but it's worth mentioning it again on this list. Be careful that adding new packages or categories before getting the benefits of the reorganization, like hopefully getting more devs onboard, will just add more work for the current devs. This may definitely scare potential recruits (not talking about the current ones that may leave or lose interest due to too much work). > Any comments on the structure? Also, while sci-xxx is a "natural" name for the > category (considering our present layout) it is somewhat cumbersome for the > herd. I guess sci- part may be dropped, then, should the rest stay spelled > out or people would prefere shortcuts, like math for mathematics, etc? Good idea. It could be argued that sci-electronics could be more properly called tech-electronics, for example. The same for the maybe future sci-cad category. So dropping the ambiguous prefix is an elegant solution to this. As a conclusion, assuming the above details can be worked out / clarified, I'm very much in favor of the proposed plan. Denis. -- gentoo-science@gentoo.org mailing list