понеділок, 26. червень 2006 14:44, Denis Dupeyron Ви написали: > Is the plan to have one subproject for each sci-* category ? That is one possibility. My stance is "whatever makes sense" - projects are the means to organize, so I'd just follow the herd structure. However the projects are more visible (that web page and some blurb after all..), so 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 - high performance computing. That one did not go far however under Scientific Gentoo, but I think the more natural place for it would have been under -cluster anyways (and that one seems to be reasonably active anyways). There were talks about "closer involvment with academia", but nothing even close to a sustainable idea ever came out of it (not that much time was spent on that either), still, this just shows potential projects. So, we can have Scientific Gentoo at top level consisting of active subprojects (Scientific Overlay could be one such that is presently active, for example) and maintainance subprojects - that's a rough idea that we can 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 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 Incidentally I was thinking about this as well :), see comment #2 in bug #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 sufficiently small herds, so that people are not afraid to join. For example plasmaroo maintains many electronics packages but he is not on sci herd, but agreed to join if we split electronics off. So, while now it seems herds will have mostly the same people listed, we may expect this to change when others, not in sci, start to add themselves to smaller groups.. Right now sci is kind of a "stale community", as everybody just supports mostly his ebuilds and roughly knows who touches what. However this structure is not exposed (via normal ways), and that at 300+ packages, thus creating a non-trivial barrier of entry. One of my primary goals is to lover this 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 waters" here - on whether there is a feeling that some category should be split or not. As such, sci-biology will likely stay - there were no comments on that one. However there was an interest in splitting off sci-crystallography from chemistry for example, creating -physics and possibly splitting math-proof from sci-math. It is clear that herds should be created, to represent developer's wishes, categorisation should be decided based on how many packages are there for each and on the desire of actual maintainers to perform such action. > > sci-electronics: 34 > > I confirm that you can count on me for anything that's in sci-electronics. Thanks! So, this is a clear candidate for the herd to be created soon then :). > > 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 It won't be worse than it is now anyways :), but the way to regulate this is 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 some time. Besides, what better material to train a recruit on is there than the ebuilds he submitted? That was my usual mentoring practive and it seems to work well :). Please see bug #138021 (this is addressed to all devs). I listed the three people who expressed interest in becoming maintainers and have made contributions. I can mentor one, but we need two more mentors.. > > > 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. Um, are you talking about herd or category names here? Categories will not change, except for some possibly being split (they were around for far too long if any reason is necessary). Herd names can be almost arbitrary - they are not visible from outside and devs will know what they are woring on :). 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 more rich hierarchy, by creating category names like say sci/math/proof or sci/chemistry/crystallography (and not requiring all leafs to be the same depth), but this is out of question, as portage would have to support that and this just won't happen any time soon (provided this will not be killed outright by screams to go to a flat "tree" of package names only and any categorization done in metadata - yes, that was for real last time this was 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. -- [email protected] mailing list
