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

[George Shapovalov]

понеділок, 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.

-- 
gentoo-science@g.o mailing list