1 |
On Wed, 2006-03-22 at 22:03 +0000, Stuart Herbert wrote: |
2 |
> To answer Daniel's other question, about bugs.g.o ... trac on |
3 |
> overlays.g.o will have its bug tracking system disabled. We already |
4 |
> have one bug tracking system - bugs.g.o - and that's sufficient. |
5 |
|
6 |
Umm... no? |
7 |
|
8 |
If some random developer goes out there and creates his own fork of |
9 |
catalyst in his overlay, I sure don't want to receive a *single* bug on |
10 |
it. Ever. |
11 |
|
12 |
If you're already using Trac, you should keep the bug tracking enabled, |
13 |
so the bugs stay with the overlay. Once something moves into the |
14 |
official tree, then it can use bugs.gentoo.org for its bug tracking. |
15 |
This means developers that don't wish to participate in the overlays are |
16 |
not forced to waste their time troubleshooting problems in these |
17 |
overlays and can focus on our *core* product, the portage tree. |
18 |
|
19 |
I have no problem with someone, for example, making their own fork of |
20 |
catalyst for testing new stuff and then, after extensive testing, |
21 |
submitting it "upstream" to the official repository, but forcing me to |
22 |
waste my time trying to figure out that some random developer out there |
23 |
has made a fork that does something different from the official version |
24 |
when a user has a bug is completely counter-productive. |
25 |
|
26 |
-- |
27 |
Chris Gianelloni |
28 |
Release Engineering - Strategic Lead |
29 |
x86 Architecture Team |
30 |
Games - Developer |
31 |
Gentoo Linux |