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