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