1 |
понеділок, 26. червень 2006 14:44, Denis Dupeyron Ви написали: |
2 |
> Is the plan to have one subproject for each sci-* category ? |
3 |
That is one possibility. My stance is "whatever makes sense" - projects are |
4 |
the means to organize, so I'd just follow the herd structure. However the |
5 |
projects are more visible (that web page and some blurb after all..), so |
6 |
following the categories makes a good sense as well. But not limited to. |
7 |
|
8 |
For example there were a few initiatives proposed earlier on, such as HPC - |
9 |
high performance computing. That one did not go far however under Scientific |
10 |
Gentoo, but I think the more natural place for it would have been |
11 |
under -cluster anyways (and that one seems to be reasonably active anyways). |
12 |
There were talks about "closer involvment with academia", but nothing even |
13 |
close to a sustainable idea ever came out of it (not that much time was spent |
14 |
on that either), still, this just shows potential projects. |
15 |
|
16 |
So, we can have Scientific Gentoo at top level consisting of active |
17 |
subprojects (Scientific Overlay could be one such that is presently active, |
18 |
for example) and maintainance subprojects - that's a rough idea that we can |
19 |
fill with particulars if enough interest arises.. |
20 |
|
21 |
> > sci-biology: 58 |
22 |
> > rather large, may be worth splitting more, no particular suggestions yet |
23 |
> > sci-chemistry: 50 |
24 |
> > may be worth splitting up as well. One suggestion is to make a category |
25 |
> > for |
26 |
> > sci-mathematics: 34 |
27 |
> > Ok size. There were calls to split it into symbolic and numeric, also |
28 |
> > -proof |
29 |
> |
30 |
> I'm not sure we should go from not enough herds to too many in one |
31 |
> single step. I suppose the people managing the different subcategories |
32 |
Incidentally I was thinking about this as well :), see comment #2 in bug |
33 |
#138049 that I just created. |
34 |
|
35 |
> will be the same anyway, so I fail to see the point here. Or is there |
36 |
> some other problem you're trying to address that I don't see ? My |
37 |
Actually yes - one of the major goals of this reorg is to create sufficiently |
38 |
small herds, so that people are not afraid to join. For example plasmaroo |
39 |
maintains many electronics packages but he is not on sci herd, but agreed to |
40 |
join if we split electronics off. So, while now it seems herds will have |
41 |
mostly the same people listed, we may expect this to change when others, not |
42 |
in sci, start to add themselves to smaller groups.. |
43 |
|
44 |
Right now sci is kind of a "stale community", as everybody just supports |
45 |
mostly his ebuilds and roughly knows who touches what. However this structure |
46 |
is not exposed (via normal ways), and that at 300+ packages, thus creating a |
47 |
non-trivial barrier of entry. One of my primary goals is to lover this |
48 |
barrier.. |
49 |
|
50 |
> I believe the problem is less about the number of packages, and more |
51 |
> about the very specific topics touched by science apps. I would be |
52 |
[...] |
53 |
> them. Splitting categories into more sub-categories won't change that |
54 |
> ratio. So I'd suggest we split packages based on topics, not on |
55 |
> numbers. |
56 |
Yes, so I am not going to push for anything. I just wanted to "test waters" |
57 |
here - on whether there is a feeling that some category should be split or |
58 |
not. As such, sci-biology will likely stay - there were no comments on that |
59 |
one. However there was an interest in splitting off sci-crystallography from |
60 |
chemistry for example, creating -physics and possibly splitting math-proof |
61 |
from sci-math. It is clear that herds should be created, to represent |
62 |
developer's wishes, categorisation should be decided based on how many |
63 |
packages are there for each and on the desire of actual maintainers to |
64 |
perform such action. |
65 |
|
66 |
> > sci-electronics: 34 |
67 |
> |
68 |
> I confirm that you can count on me for anything that's in sci-electronics. |
69 |
Thanks! So, this is a clear candidate for the herd to be created soon then :). |
70 |
|
71 |
|
72 |
> > sci-misc: 19 |
73 |
> > Size is Ok, but, if we follow the idea, should probably stay under sci |
74 |
> > (herd) devs: |
75 |
> > cryos, hansmi?, phosphan, ribosome, kugelfang?, pbienst, blubb? |
76 |
> |
77 |
> Agreed. But it should be clear who maintains each of them, or that |
78 |
> will become nobody. What I mean is that for any package in the other |
79 |
It won't be worse than it is now anyways :), but the way to regulate this is |
80 |
exactly as you suggest below: |
81 |
|
82 |
> categories, the name of the (sub-)herd in the metadata is usually |
83 |
> sufficient. For packages in this category, and in sci-libs by the way, |
84 |
> we could require there is at least one dev name. |
85 |
|
86 |
|
87 |
|
88 |
> We talked about this on irc already, but it's worth mentioning it |
89 |
> again on this list. Be careful that adding new packages or categories |
90 |
> before getting the benefits of the reorganization, like hopefully |
91 |
> getting more devs onboard, will just add more work for the current |
92 |
> devs. This may definitely scare potential recruits (not talking about |
93 |
> the current ones that may leave or lose interest due to too much |
94 |
> work). |
95 |
Well, of course, the recruitment should start early, as it takes quite some |
96 |
time. Besides, what better material to train a recruit on is there than the |
97 |
ebuilds he submitted? That was my usual mentoring practive and it seems to |
98 |
work well :). |
99 |
Please see bug #138021 (this is addressed to all devs). I listed the three |
100 |
people who expressed interest in becoming maintainers and have made |
101 |
contributions. I can mentor one, but we need two more mentors.. |
102 |
|
103 |
> |
104 |
> > Any comments on the structure? Also, while sci-xxx is a "natural" name |
105 |
> > for the category (considering our present layout) it is somewhat |
106 |
> > cumbersome for the herd. I guess sci- part may be dropped, then, should |
107 |
> > the rest stay spelled out or people would prefere shortcuts, like math |
108 |
> > for mathematics, etc? |
109 |
> |
110 |
> Good idea. It could be argued that sci-electronics could be more |
111 |
> properly called tech-electronics, for example. The same for the maybe |
112 |
> future sci-cad category. So dropping the ambiguous prefix is an |
113 |
> elegant solution to this. |
114 |
Um, are you talking about herd or category names here? Categories will not |
115 |
change, except for some possibly being split (they were around for far too |
116 |
long if any reason is necessary). Herd names can be almost arbitrary - they |
117 |
are not visible from outside and devs will know what they are woring on :). |
118 |
So, as far as herds are concerned, this is mostly a matter of taste.. |
119 |
|
120 |
Addressing the categories yet again: I think we could really benefit from a |
121 |
more rich hierarchy, by creating category names like say sci/math/proof or |
122 |
sci/chemistry/crystallography (and not requiring all leafs to be the same |
123 |
depth), but this is out of question, as portage would have to support that |
124 |
and this just won't happen any time soon (provided this will not be killed |
125 |
outright by screams to go to a flat "tree" of package names only and any |
126 |
categorization done in metadata - yes, that was for real last time this was |
127 |
discussed :)) |
128 |
|
129 |
George |
130 |
|
131 |
> As a conclusion, assuming the above details can be worked out / |
132 |
> clarified, I'm very much in favor of the proposed plan. |
133 |
> |
134 |
> Denis. |
135 |
|
136 |
-- |
137 |
gentoo-science@g.o mailing list |