Re: [gentoo-science] Scientific Gentoo reorg: the proposal

[Denis Dupeyron]

On 6/25/06, George Shapovalov <george@g.o> 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@g.o mailing list