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 1Fusmk-0007BV-NU for garchives@archives.gentoo.org; Mon, 26 Jun 2006 15:13:59 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k5QFAVbd032185; Mon, 26 Jun 2006 15:10:31 GMT Received: from mbox.unige.ch (mbox.unige.ch [129.194.9.209]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k5QFAUIS030155 for ; Mon, 26 Jun 2006 15:10:30 GMT Received: from conversion-daemon.mbox.unige.ch by mbox.unige.ch (Sun Java System Messaging Server 6.2-3.03 (built Jun 27 2005)) id <0J1H00F01332BW00@mbox.unige.ch> (original mail from george@gentoo.org) for gentoo-science@lists.gentoo.org; Mon, 26 Jun 2006 17:10:30 +0200 (CEST) Received: from pcc23679 ([129.194.54.121]) by mbox.unige.ch (Sun Java System Messaging Server 6.2-3.03 (built Jun 27 2005)) with ESMTPS id <0J1H00IW63HE2XI0@mbox.unige.ch> for gentoo-science@lists.gentoo.org; Mon, 26 Jun 2006 17:10:26 +0200 (CEST) Date: Mon, 26 Jun 2006 17:10:35 +0200 From: George Shapovalov X-Face: 4Rd)1/:bMGRby_[I4NY3u,g|=7e?V_VX?tkj,_ct-U4B#_-EEu_/wyvCWFsvDa<=?utf-8?q?D/=3A8bHX=0A=09y?=)m@s7@Ow=\_f^T>}LP_Rk2%phL7r5%sxXze`X/A_:8tz&|"*2^="=?utf-8?q?=5CZFo3=26+=27UGNhVu=23=5Dg=0A=09=5B?=<<~4glvaJa'ZEXW_#@LWa,OhxVN"r|/1P:`IL8=rciHKGxevczUO{X!r%,a Subject: Re: [gentoo-science] Scientific Gentoo reorg: the proposal In-reply-to: <7c612fc60606260544n6894792cvbad119d51220969c@mail.gmail.com> To: gentoo-science@lists.gentoo.org Message-id: <200606261710.36536.george@gentoo.org> Organization: Gentoo Linux 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=utf-8 Content-disposition: inline References: <200606252046.03386.george@gentoo.org> <7c612fc60606260544n6894792cvbad119d51220969c@mail.gmail.com> X-Comment: This message was scanned against viruses by mbox.unige.ch. User-Agent: KMail/1.9.3 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by robin.gentoo.org id k5QFAUIS030155 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k5QFAVc4032185 X-Archives-Salt: 9249f61d-66cc-4c3f-92f9-c2e7ec8c3996 X-Archives-Hash: 0f010e0abfd96f48bfdc8db11c7d38aa =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D1=96=D0=BB=D0=BE=D0=BA, 26. =D1=87=D0=B5=D1= =80=D0=B2=D0=B5=D0=BD=D1=8C 2006 14:44, Denis Dupeyron =D0=92=D0=B8 =D0=BD= =D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB=D0=B8: > Is the plan to have one subproject for each sci-* category ? That is one possibility. My stance is "whatever makes sense" - projects a= re=20 the means to organize, so I'd just follow the herd structure. However the= =20 projects are more visible (that web page and some blurb after all..), so=20 following the categories makes a good sense as well. But not limited to. For example there were a few initiatives proposed earlier on, such as HPC= -=20 high performance computing. That one did not go far however under Scienti= fic=20 Gentoo, but I think the more natural place for it would have been=20 under -cluster anyways (and that one seems to be reasonably active anyway= s).=20 There were talks about "closer involvment with academia", but nothing eve= n=20 close to a sustainable idea ever came out of it (not that much time was s= pent=20 on that either), still, this just shows potential projects. So, we can have Scientific Gentoo at top level consisting of active=20 subprojects (Scientific Overlay could be one such that is presently activ= e,=20 for example) and maintainance subprojects - that's a rough idea that we c= an=20 fill with particulars if enough interest arises.. > > 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 catego= ry > > 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 Incidentally I was thinking about this as well :), see comment #2 in bug=20 #138049 that I just created. > 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 Actually yes - one of the major goals of this reorg is to create sufficie= ntly=20 small herds, so that people are not afraid to join. For example plasmaroo= =20 maintains many electronics packages but he is not on sci herd, but agreed= to=20 join if we split electronics off. So, while now it seems herds will have=20 mostly the same people listed, we may expect this to change when others, = not=20 in sci, start to add themselves to smaller groups.. Right now sci is kind of a "stale community", as everybody just supports=20 mostly his ebuilds and roughly knows who touches what. However this struc= ture=20 is not exposed (via normal ways), and that at 300+ packages, thus creatin= g a=20 non-trivial barrier of entry. One of my primary goals is to lover this=20 barrier.. > 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 [...] > 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. Yes, so I am not going to push for anything. I just wanted to "test water= s"=20 here - on whether there is a feeling that some category should be split o= r=20 not. As such, sci-biology will likely stay - there were no comments on th= at=20 one. However there was an interest in splitting off sci-crystallography f= rom=20 chemistry for example, creating -physics and possibly splitting math-proo= f=20 from sci-math. It is clear that herds should be created, to represent=20 developer's wishes, categorisation should be decided based on how many=20 packages are there for each and on the desire of actual maintainers to=20 perform such action. > > sci-electronics: 34 > > I confirm that you can count on me for anything that's in sci-electroni= cs. Thanks! So, this is a clear candidate for the herd to be created soon the= n :). > > sci-misc: 19 > > Size is Ok, but, if we follow the idea, should probably stay under sc= i > > (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 It won't be worse than it is now anyways :), but the way to regulate this= is=20 exactly as you suggest below: > 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. > 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). Well, of course, the recruitment should start early, as it takes quite so= me=20 time. Besides, what better material to train a recruit on is there than t= he=20 ebuilds he submitted? That was my usual mentoring practive and it seems t= o=20 work well :).=20 Please see bug #138021 (this is addressed to all devs). I listed the thre= e=20 people who expressed interest in becoming maintainers and have made=20 contributions. I can mentor one, but we need two more mentors.. > > > Any comments on the structure? Also, while sci-xxx is a "natural" nam= e > > for the category (considering our present layout) it is somewhat > > cumbersome for the herd. I guess sci- part may be dropped, then, shou= ld > > the rest stay spelled out or people would prefere shortcuts, like mat= h > > 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. Um, are you talking about herd or category names here? Categories will no= t=20 change, except for some possibly being split (they were around for far to= o=20 long if any reason is necessary). Herd names can be almost arbitrary - th= ey=20 are not visible from outside and devs will know what they are woring on := ).=20 So, as far as herds are concerned, this is mostly a matter of taste.. Addressing the categories yet again: I think we could really benefit from= a=20 more rich hierarchy, by creating category names like say sci/math/proof o= r=20 sci/chemistry/crystallography (and not requiring all leafs to be the same= =20 depth), but this is out of question, as portage would have to support tha= t=20 and this just won't happen any time soon (provided this will not be kille= d=20 outright by screams to go to a flat "tree" of package names only and any=20 categorization done in metadata - yes, that was for real last time this w= as=20 discussed :)) George > As a conclusion, assuming the above details can be worked out / > clarified, I'm very much in favor of the proposed plan. > > Denis. --=20 gentoo-science@gentoo.org mailing list