1 |
Sébastien Fabbro wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> I would like to call for help for the sci team. Lately, we are taking |
5 |
> care of sometimes old packages, sometimes packages that we don't use but |
6 |
> are quite popular so we want to keep in the tree. Our time is limited, |
7 |
> bug list is barely reducing, and requests for new packages are piling |
8 |
> up. |
9 |
> |
10 |
> There are plenty of interesting projects the sci team could start. But |
11 |
> we just don't do because we are understaffed. Examples of such projects |
12 |
> are: grid-aware tools, homepage page renewal, more docs, test-suites for |
13 |
> packages, more collaboration with hp-cluster. I also know some widely |
14 |
> used packages are not in the tree because they need a lot of time to |
15 |
> package/maintain. In my field such examples are: iraf and midas in |
16 |
> sci-astronomy, geant-4 in hep, R-packages, many numerical libraries, |
17 |
> etc... |
18 |
> |
19 |
> So what could we do to get more help: call for new recruits, convince |
20 |
> more devs to join the sci herd, get proxied packages, more overlay |
21 |
> maintainers? (in the past, there was a similar thread [1]). I could |
22 |
> train a new dev in anyone interested, I would have more time in 2 weeks. |
23 |
> |
24 |
> Regards, |
25 |
> |
26 |
> -- |
27 |
> Sébastien |
28 |
> |
29 |
> [1] http://thread.gmane.org/gmane.linux.gentoo.science/272 |
30 |
> |
31 |
I've been following this thread, and I'll have to admit I'm often |
32 |
tempted to volunteer as a dev in the sci herd. But I just never seem to |
33 |
take the step from hard-core volunteer tester. I'm not sure why, but I |
34 |
think for now it's still about all I have time to do -- test stuff, file |
35 |
bugs, encourage the existing devs, etc. A few more specific comments: |
36 |
|
37 |
1. I'm not sure the idea of integrating, say, R packages, into Portage |
38 |
is a good one. Debian has a lot of R packages in their repository, but |
39 |
that's mainly because one developer, Dirk Eddelbuettel, took that on as |
40 |
a personal mission. For that matter, I don't know that Portage really |
41 |
*needs* to have "tight" integration with any other package management |
42 |
systems. In other words, does a CPAN Perl package really need to be |
43 |
wrapped in an ebuild, or could a Gentoo user just as easily install CPAN |
44 |
packages directly? The same goes for Ruby gems -- it's only marginally |
45 |
more convenient for a Rubyist to have gems in Portage, and you'll never |
46 |
have them *all. If you have the developer resources, sure, why not, but |
47 |
aren't there better things the developers could be doing? In any event, |
48 |
I use R and its packages heavily and don't see the need to "emerge |
49 |
Rcmdr" -- R's native package management system is fine. So is Ruby's |
50 |
"rubygems" package management system. |
51 |
|
52 |
2. Don't be afraid to kick something out of the distro if nobody wants |
53 |
to maintain it. It's no big deal to install a package from upstream |
54 |
source. As far as I'm concerned, in most cases the only difference is |
55 |
that it ends up in /usr/local instead of in /usr and I have to manually |
56 |
load the dependencies. |
57 |
|
58 |
3. I think the distinction between testing/unstable but in the tree and |
59 |
testing/unstable but in an overlay is a good one. As one of the |
60 |
documents says, things in the overlay *will* break your system. I |
61 |
haven't had one break to the point of needing a rebuild in a couple of |
62 |
years, but I've come close. You have to back stuff up and be careful |
63 |
anyhow, so why not have the software available? :) |
64 |
-- |
65 |
gentoo-science@g.o mailing list |