1 |
Hi Chris, |
2 |
|
3 |
On 3/23/06, Chris Bainbridge <chris.bainbridge@×××××.com> wrote: |
4 |
> Developers are using overlays, however, the majority of users aren't. |
5 |
|
6 |
True. But does that have to be the audience for overlays? |
7 |
|
8 |
> If the usage of overlays is to increase, then remote overlay support |
9 |
> should be added to emerge. Additionally, in order for users to be able |
10 |
> to contribute to the overlays, it would help if they had anonymous |
11 |
> read access. |
12 |
|
13 |
I forgot to mention that anonymous read access would be available, |
14 |
although we'll have to see how that impacts the hardware. We may need |
15 |
to raise some funds / scrounge some extra kit to make o.g.o scale if |
16 |
it proves wildly popular. |
17 |
|
18 |
As for remote overlay support ... try using layman to see if that's |
19 |
enough for today. If we find we need more support in future, we can |
20 |
revisit the situation. |
21 |
|
22 |
We're not trying to get all users to use overlays instead of the |
23 |
Portage tree. We're just creating a social space where non-devs who |
24 |
want to contribute can work more easily with existing devs. |
25 |
|
26 |
> The safety net was intended for developers. |
27 |
|
28 |
Then it's a change in topic. Please start a new thread on here for it. |
29 |
|
30 |
> Packages often get broken |
31 |
> in unexpected ways - something depends on it, a patch is conditional |
32 |
> on some USE flag or arch etc. It would be useful to get an email 5 |
33 |
> minutes after a commit saying "you broke something", rather than a bug |
34 |
> report being filed a week later. |
35 |
|
36 |
How does that differ from the service that autorepoman already |
37 |
provides? Maybe you need to be talking directly to Mark and the QA |
38 |
team about this. |
39 |
|
40 |
> I don't think it is unrealistic to expect that if a user puts a lot of |
41 |
> work into an ebuild, and it works, then it should somehow end up in |
42 |
> the tree. |
43 |
|
44 |
Okay, that's something I'd like to nip in the bud right there. |
45 |
|
46 |
Something "working" is not the only criteria that Gentoo requires for |
47 |
a package to go into the tree. I'm sure you already know that. If we |
48 |
don't have a developer willing to maintain the package, it doesn't |
49 |
belong in the tree. |
50 |
|
51 |
It's not sustainable to have "fire-and-forget" packages lying around. |
52 |
|
53 |
One problem I've seen with recruitment is devs who don't "stick", who |
54 |
stop contributing after a short period of time, and who fade away. |
55 |
I'm not saying they're the only answer, but overlays can be used to |
56 |
see whether someone will make a sustained effort over a decent period |
57 |
of time, before they are recruited. |
58 |
|
59 |
> Rejecting isn't very nice, |
60 |
|
61 |
Agreed. |
62 |
|
63 |
> the amount of effort and barriers to become a dev are too great |
64 |
|
65 |
I can't agree with you there. I believe we can make it easier, and do |
66 |
so without changing the amount of effort or the deliberate barriers we |
67 |
have today. |
68 |
|
69 |
> so we end up with good ebuilds not being added. |
70 |
|
71 |
Good ebuilds aren't enough. |
72 |
|
73 |
> Adding the ebuilds to overlays is one option, but |
74 |
> then other users will be expected to find an overlay with their |
75 |
> package in, and then add it to make.conf. As the number of overlays |
76 |
> increases, the amount of effort in synchronising dependencies and |
77 |
> dealing with other problems between them will increase. |
78 |
|
79 |
Perhaps. Perhaps not. |
80 |
|
81 |
But that's only one aspect of overlays - it's not the whole shebang. |
82 |
There are developers and teams that use overlays to maintain packages |
83 |
that are in the tree, and then they push the packages from the overlay |
84 |
to the tree when the packages are ready for wider testing. |
85 |
|
86 |
> Maybe in the real world managing the relationships between overlays |
87 |
> won't be as big a problem as it appears it could be. |
88 |
|
89 |
Take layman out for a spin, and let the author know how well it helps with this. |
90 |
|
91 |
> Not much - time is a great constraint, and writing emails takes much |
92 |
> less time than writing code... |
93 |
|
94 |
I appreciate your honesty there :) |
95 |
|
96 |
Best regards, |
97 |
Stu |
98 |
|
99 |
-- |
100 |
gentoo-dev@g.o mailing list |