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