[gentoo-science] unsubscribe

[gentoo-science] unsubscribe

[asclark]

 


-- 
gentoo-science@lists.gentoo.org mailing list

[gentoo-science] unsubscribe

[Frederico Moraes Ferreira]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 26 bytes --]

[gentoo-science] unsubscribe

[John Lips]

[gentoo-science] unsubscribe

[askclark]

-- 
gentoo-science@gentoo.org mailing list

[gentoo-science] unsubscribe

[askclark]

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[C Y]

--- Olivier Fisette <ribosome@gentoo.org> wrote:

> Familiarity with one or more scientific packages already in 
> Portage, and willfulness to maintain them up-to-date and 
> bug-free would be a plus. We currently have no maintainer for 
> important packages such as GNU Octave, Maxima or the Staden 
> Package. A problem I have with scientific software is that I 
> find it hard to test when it applies to a field I am not 
> familiar with. This is probably the case with everybody in the 
> sci herd. ;-)

I have some familiarity with Maxima, in fact I was mixed up with the
original creation of that ebuild (although I was not responsible for
the last complex ebuild dependancy magic that finally made it work.)  I
have played a minor role in the development of Maxima itself (some
documentation work and bug finding, primarily).  I don't know nearly
enough about the details of ebuilds to offer comprehensive advice, but
I can say with confidence that the ebuilds for various lisps Maxima
uses are going to outpace the release schedule for Maxima, so either
someone needs to keep creating patches to Maxima or preserve the older
lisps with exact version dependancies for a static Maxima to keep
working.  If the better idea is judged to be patch from cvs as needed,
I would advise waiting for 5.9.2 before starting that, since there are
a LOT of patches since 5.9.1.  (As is, it would be simplier to just use
a cvs tarball instead.)

I would also advise that some more focus be turned on Axiom, which is a
competitor to Maxima and a very powerful program indeed - in some
respects it is unique among computer algebra systems.  It's design
lends some hope to the idea of systematically incorporating new
mathematical abilities into it, which is a big deal.  It retains deep
awareness of things like mathematical types, and unlike Maxima is much
more fully documented :-/.  A cvs ebuild exists and works, with some
edits of the final axiom script produced, but I would like to see a
stable one too.

Unfortunately, I have no significant familiarity with Octave's build
process, having used it only once or twice for minor applications.

> Since we have time constraints ourselves, we understand potential 
> recruits may only have a few hours during one day of the week to 
> do Gentoo development, and that is Ok. However, if you don't 
> think you will be able to dedicate at least an hour or two a 
> week on average, I am not sure it would be profitable to invest 
> time and efforts in the mentoring process.

Perhaps we could have a "support team" behind someone with official
Gentoo developer status - people could point out significant ebuilds
with most logic in place to the developer, help work out quirks in the
programs/ebuilds, and generally speed things up?  Certainly the
developer would bear final responsibility but this way those of us with
five hours every month or so could help out too, particularly for
specialty packages.  (BTY, if some genius could figure out brl-cad I
would be grateful - it's going to take me a year at this point :-/.)

There are a fair number of at least partial ebuilds for useful
scientific software stuck in bugzilla - brl-cad and acl2 come
immediately to mind, and I know there are others.  Plus a fair number
that don't have ebuilds where it would be useful to have them.  Gentoo
is alreay one of the best for scientific software, due to compiling
things being easy and our ebuild pool, but we could definitely do
better.

My machine is probably a poor test machine - what gentoo environment
would we need to maintain?

Cheers,
CY


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] Re: Scientific herd leadership

[Marcus D. Hanwell]

[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]

On Monday 22 August 2005 08:48, C Y wrote:
> Perhaps we could have a "support team" behind someone with official
> Gentoo developer status - people could point out significant ebuilds
> with most logic in place to the developer, help work out quirks in the
> programs/ebuilds, and generally speed things up?  Certainly the
> developer would bear final responsibility but this way those of us with
> five hours every month or so could help out too, particularly for
> specialty packages.  (BTY, if some genius could figure out brl-cad I
> would be grateful - it's going to take me a year at this point :-/.)

I was wondering myself if some people in here might be receptive to the idea 
of a support team, much like the arch testers we have for the amd64 porting 
team. It often leads on to people becoming devs, but is a great way to help 
out when you can.

Tony Murray is filling that kind of role unofficially with all the work he 
puts into the boinc and setiathome ebuilds, whilst I review, test, improve 
and commit them once they are up to standard. I also have good contact with 
the quickplot developer who has integrated my patches upstream and helped 
significantly with the ebuilds for that package.

I think these relationships are important, and I personally nurture them as 
much as possible. Many scientific packages are very involved and having 
people help test and work out problems can significantly increase our 
efficiency as a team.
>
> There are a fair number of at least partial ebuilds for useful
> scientific software stuck in bugzilla - brl-cad and acl2 come
> immediately to mind, and I know there are others.  Plus a fair number
> that don't have ebuilds where it would be useful to have them.  Gentoo
> is alreay one of the best for scientific software, due to compiling
> things being easy and our ebuild pool, but we could definitely do
> better.

The problem comes down to manpower and a need to recruit some more people to 
the team. Having a support team similar to the arch testers could certainly 
help in our case if those people were not ready to become devs/didn't have 
the time. Once a package has been committed they would also need to help with 
version bumps and fixing bugs with the new packages ideally.
>
> My machine is probably a poor test machine - what gentoo environment
> would we need to maintain?

Just an up to date Gentoo install is fine. If you are testing some more 
experimental stuff (I test new baselayout, glibc, gcc and other core stuff 
sometimes) then a chroot might also be adviseable. Scientific apps just 
require an up to date system.

Thanks,

Marcus
-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-science] unsubscribe

[John Tee]

Marcus D. Hanwell wrote:
> On Monday 22 August 2005 08:48, C Y wrote:
> 
>>Perhaps we could have a "support team" behind someone with official
>>Gentoo developer status - people could point out significant ebuilds
>>with most logic in place to the developer, help work out quirks in the
>>programs/ebuilds, and generally speed things up?  Certainly the
>>developer would bear final responsibility but this way those of us with
>>five hours every month or so could help out too, particularly for
>>specialty packages.  (BTY, if some genius could figure out brl-cad I
>>would be grateful - it's going to take me a year at this point :-/.)
> 
> 
> I was wondering myself if some people in here might be receptive to the idea 
> of a support team, much like the arch testers we have for the amd64 porting 
> team. It often leads on to people becoming devs, but is a great way to help 
> out when you can.
> 
> Tony Murray is filling that kind of role unofficially with all the work he 
> puts into the boinc and setiathome ebuilds, whilst I review, test, improve 
> and commit them once they are up to standard. I also have good contact with 
> the quickplot developer who has integrated my patches upstream and helped 
> significantly with the ebuilds for that package.
> 
> I think these relationships are important, and I personally nurture them as 
> much as possible. Many scientific packages are very involved and having 
> people help test and work out problems can significantly increase our 
> efficiency as a team.
> 
>>There are a fair number of at least partial ebuilds for useful
>>scientific software stuck in bugzilla - brl-cad and acl2 come
>>immediately to mind, and I know there are others.  Plus a fair number
>>that don't have ebuilds where it would be useful to have them.  Gentoo
>>is alreay one of the best for scientific software, due to compiling
>>things being easy and our ebuild pool, but we could definitely do
>>better.
> 
> 
> The problem comes down to manpower and a need to recruit some more people to 
> the team. Having a support team similar to the arch testers could certainly 
> help in our case if those people were not ready to become devs/didn't have 
> the time. Once a package has been committed they would also need to help with 
> version bumps and fixing bugs with the new packages ideally.
> 
>>My machine is probably a poor test machine - what gentoo environment
>>would we need to maintain?
> 
> 
> Just an up to date Gentoo install is fine. If you are testing some more 
> experimental stuff (I test new baselayout, glibc, gcc and other core stuff 
> sometimes) then a chroot might also be adviseable. Scientific apps just 
> require an up to date system.
> 
> Thanks,
> 
> Marcus

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] unsubscribe

[Patrick Kursawe]

- please have a look at the headers for unsubscribe information.
- please don't write unsubscribe requests to the list.
- please don't quote the full text when you just want to unsubscribe.

Thanks,

Patrick	
-- 
gentoo-science@gentoo.org mailing list