1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Thomas Cort wrote: |
5 |
> On Thu, 27 Jul 2006 22:19:14 -0400 |
6 |
> Luis Francisco Araujo <araujo@g.o> wrote: |
7 |
> |
8 |
>> The users explicitly compromise to (just to make it clear): [1,2,3,4] |
9 |
> |
10 |
> People who participate in open projects like Gentoo come and go. What |
11 |
> happens if/when the proxy maintainer decides to leave? Who will take |
12 |
> care of the package? Maybe the mailing list could also be used to find |
13 |
> users to proxy maintain abandoned packages? |
14 |
> |
15 |
Good point. |
16 |
|
17 |
Definitely, the mailing list could be used to address this case too. |
18 |
|
19 |
I see two possible situations in the best case: |
20 |
|
21 |
1 - The developer sends the request to the mailing list asking for |
22 |
somebody interested to continue proxy-maintaining the packages. Any |
23 |
interested developer could step in. |
24 |
|
25 |
2 - The proxy-user *could* be interested to become official developer to |
26 |
maintain this package too. |
27 |
|
28 |
As long as there exist an interested user to maintain the package i |
29 |
think it's a matter of time to find a proxy-developer. (Any mechanism to |
30 |
inform us which packages are in this state would be useful too, probably |
31 |
a monthly message to the list?) |
32 |
|
33 |
Now if the user isn't interested anymore , and i think this would be the |
34 |
'worst' of the case, could be addressed in the following manner: |
35 |
|
36 |
1- He could notify to the mailing list for any user interested to |
37 |
continue maintaining the package(s). |
38 |
|
39 |
2- If no user steps in, the developer would still represent officially |
40 |
the package inside the tree. Now, this package _ideally_ shouldn't have |
41 |
any bug (the user should have taken care of all of them right?), so |
42 |
practically, this package shouldn't be any serious menace to the tree, |
43 |
and therefore, the developer doesn't need to update the package if he |
44 |
doesn't want to. If a bug appears , the developer can: a) Fix it , b) |
45 |
mask the package , c) After b, remove the package. This being the |
46 |
*worse* of the case as i said. |
47 |
|
48 |
Now, i also see an interesting problem here. |
49 |
|
50 |
I can notice we (as developers) make sort of an agreement when we become |
51 |
a developer, but not when we leave the project. This is the main cause |
52 |
we keep having so many packages unmaintained. I think that whatever we |
53 |
do, if we don't find a solution to this situation, gentoo will continue |
54 |
to suffer of this problem. And this idea is just an attempt to alleviate |
55 |
some of it. |
56 |
|
57 |
>> I know there already exist some developers working as proxy, well, i |
58 |
>> appreciate if they got any comment or observation about this idea. This |
59 |
>> is just a way of giving some organization to this kind of cooperative |
60 |
>> mechanism at some degree. And an 'official' representation inside Gentoo |
61 |
>> if we agree with it. |
62 |
> |
63 |
> I work with a user (Kai Huuhko) to maintain media-sound/quodlibet, |
64 |
> media-libs/mutagen, and media-plugins/quodlibet-*. I have a dev overlay |
65 |
> on overlays.gentoo.org where Kai and I both have commit access. We both |
66 |
> work on the ebuilds in the overylay and exchange ideas over e-mail. |
67 |
> After the ebuilds are complete and tested, I commit them to the official |
68 |
> tree. Kia helps with bugs too. So far it has worked very well for us |
69 |
> and we haven't had any problems with the arrangement. Having a helper |
70 |
> saves me time and energy, which allows me do other Gentoo related tasks. |
71 |
> |
72 |
> -Thomas |
73 |
|
74 |
Nice, we have something similar inside the Haskell herd. It looks like |
75 |
we are not the only ones doing good then. |
76 |
|
77 |
Probably making this mechanism more 'organized' and 'official', would |
78 |
encourage more developers to work with it. |
79 |
|
80 |
- -- |
81 |
|
82 |
|
83 |
Luis F. Araujo "araujo at gentoo.org" |
84 |
Gentoo Linux |
85 |
-----BEGIN PGP SIGNATURE----- |
86 |
Version: GnuPG v1.4.4 (GNU/Linux) |
87 |
|
88 |
iD8DBQFEyYr4dZ42PGEF17URAovbAKCwSlJ8657WQpLPhRamAZ4SRrUdSgCgvMS2 |
89 |
ZS8ybMME+hXrByoct5BQh8Y= |
90 |
=31YO |
91 |
-----END PGP SIGNATURE----- |
92 |
-- |
93 |
gentoo-dev@g.o mailing list |