1 |
Marcus D. Hanwell wrote: |
2 |
|
3 |
>On Monday 22 August 2005 08:48, C Y wrote: |
4 |
> |
5 |
> |
6 |
>>Perhaps we could have a "support team" behind someone with official |
7 |
>>Gentoo developer status - people could point out significant ebuilds |
8 |
>>with most logic in place to the developer, help work out quirks in the |
9 |
>>programs/ebuilds, and generally speed things up? Certainly the |
10 |
>>developer would bear final responsibility but this way those of us with |
11 |
>>five hours every month or so could help out too, particularly for |
12 |
>>specialty packages. (BTY, if some genius could figure out brl-cad I |
13 |
>>would be grateful - it's going to take me a year at this point :-/.) |
14 |
>> |
15 |
>> |
16 |
> |
17 |
>I was wondering myself if some people in here might be receptive to the idea |
18 |
>of a support team, much like the arch testers we have for the amd64 porting |
19 |
>team. It often leads on to people becoming devs, but is a great way to help |
20 |
>out when you can. |
21 |
> |
22 |
> |
23 |
Yeah, it's a good idea -- my tastes are widely varying, though, |
24 |
including science and computer music, Ruby on Rails, and just learning |
25 |
in general. For myself, I'm probably closer to knowing what's "under the |
26 |
hood" in R than any other package; I've been using it since 1.1 or |
27 |
thereabouts. In the case of R, I beta test the upstream tarballs |
28 |
whenever I have the spare time. But the R ebuild itself isn't |
29 |
particularly tricky, nor is there a lot of work maintaining portability |
30 |
of it across the Gentoo-supported architectures. Their issues are the |
31 |
same as those of most open-source packages -- x86-64 and GCC 4. :) |
32 |
|
33 |
In the end, we're all volunteers anyhow in this game. We do what we can |
34 |
when we can, as long as it's legal and ethical. So I'm going to keep |
35 |
spending at least four hours a week doing exactly what I'm doing now, |
36 |
whether or not I get some kind of "formal" status or "recognition" -- |
37 |
just the learning and having the quality software available when I need |
38 |
it is enough! |
39 |
|
40 |
>Tony Murray is filling that kind of role unofficially with all the work he |
41 |
>puts into the boinc and setiathome ebuilds, whilst I review, test, improve |
42 |
>and commit them once they are up to standard. I also have good contact with |
43 |
>the quickplot developer who has integrated my patches upstream and helped |
44 |
>significantly with the ebuilds for that package. |
45 |
> |
46 |
>I think these relationships are important, and I personally nurture them as |
47 |
>much as possible. Many scientific packages are very involved and having |
48 |
>people help test and work out problems can significantly increase our |
49 |
>efficiency as a team. |
50 |
> |
51 |
> |
52 |
It's also important to have lines of communication/liasons with the |
53 |
upstream package developers. Since most of Gentoo is built from source, |
54 |
it could take as little as a few hours for an upstream release to make |
55 |
it into Portage unstable/testing and onto a Gentoo user's system. Good |
56 |
news and bad news can travel at the same speed. :) In my case, I've been |
57 |
the "user" in the development chain of TeXmacs and Common Music. There's |
58 |
no way on Earth I could have done that in Fedora or even Debian. |
59 |
(Actually, in the case of TeXmacs, I did try to file a bug in Debian on |
60 |
the TeXmacs/R bug I found, but never did figure out their bug filing |
61 |
system. And those folks at TeXmacs never *have* fixed the bug, either! :( ) |
62 |
|
63 |
-- |
64 |
M. Edward (Ed) Borasky |
65 |
|
66 |
http://www.borasky-research.net/ |
67 |
http://borasky-research.blogspot.com/ |
68 |
|
69 |
http://pdxneurosemantics.com |
70 |
http://pdx-sales-coach.com |
71 |
http://algocompsynth.com |
72 |
|
73 |
-- |
74 |
gentoo-science@g.o mailing list |