On 6/25/06, George Shapovalov <[EMAIL PROTECTED]> 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. -- [email protected] mailing list
