1 |
On Thu, 2006-06-08 at 15:22 -0700, Donnie Berkholz wrote: |
2 |
> Chris Gianelloni wrote: |
3 |
> > No, but the ebuilds are also checked by the team in question, that |
4 |
> > actually knows the packages, versus a couple of developers that will be |
5 |
> > overworked, dealing with packages that they are completely unfamiliar |
6 |
> > with and have no experience with. I just don't see the two as equal in |
7 |
> > any way. I also do not see how this helps Gentoo development. |
8 |
> |
9 |
> Being able to maintain these ebuilds in version control rather than |
10 |
> random attachments to bugzilla is a huge improvement. |
11 |
|
12 |
Of course they would be, to the team in question. To a few random |
13 |
developers being responsible for *any* kind of package, it won't make |
14 |
much difference since their familiarity level is very near zero. |
15 |
|
16 |
Good examples of this *working* are php, webapps, or even vmware. |
17 |
|
18 |
Bad examples would be this overlay. Instead of a directed and focused |
19 |
overlay, designed to ease testing and development on otherwise intrusive |
20 |
changes to the tree, it is a dumping ground for ebuilds that either |
21 |
weren't good enough, or weren't interesting enough for inclusion. |
22 |
|
23 |
Either that, or they're ebuilds related to an already-established |
24 |
project where the team members simply don't have the time. This is |
25 |
probably the only case where the ebuilds in question might make it into |
26 |
the tree after being in this overlay. |
27 |
|
28 |
This overlay is a dumping ground for the barely-wanted, and little more. |
29 |
As I have said, I don't see it actually improving the situation nearly |
30 |
as much as it will be detrimental to it. |
31 |
|
32 |
-- |
33 |
Chris Gianelloni |
34 |
Release Engineering - Strategic Lead |
35 |
x86 Architecture Team |
36 |
Games - Developer |
37 |
Gentoo Linux |