1 |
> On Sat, Mar 24, 2007 at 01:46:45PM +1100, Jonathan Adamczewski wrote: |
2 |
>> Paludis is a tool used for working with the Gentoo Portage tree - there |
3 |
>> is no problem with it being part of a Gentoo Google Summer of |
4 |
>> Code project as it will benefit the Gentoo project and its users. |
5 |
> |
6 |
> Why not simply solve the situation by making paludis the mentoring |
7 |
> organisation instead of Gentoo? |
8 |
|
9 |
You assume that the paludis folks applied for mentoring org status and |
10 |
were accepted; which didn't happen. |
11 |
|
12 |
The Gentoo SoC team is aware of lingering issues regarding projects like |
13 |
pkgcore and paludis and whatnot. I'd prefer we rank applications (and |
14 |
applicants) based on the merits of their application as opposed to some |
15 |
arbitrary political system. If it happens that someone submits a very |
16 |
well thought out idea with defined goals, milestones, has a design plan |
17 |
and seems to have decent merit but happens to be say, a paludis related |
18 |
project; well I guess the other people should have submitted better |
19 |
proposals. In the end most of the ranking and chosing of projects is a |
20 |
huge judgement call by the SoC team and the mentors each year anyway. |
21 |
|
22 |
Personally I think python bindings for paludis push the boundaries of |
23 |
'does this project affect gentoo' while say, the project idea for 'adding |
24 |
an ebuild development tool for paludis' does not push the boundaries. One |
25 |
is only tangentially related (paludis happens to be a tool that uses |
26 |
ebuilds) and the other could be more of a cross-project project, with 1 |
27 |
gentoo mentor and 1 paludis mentor. However my opinon (and most of this |
28 |
ensuing discussion) is probably better served for when applications are |
29 |
actually ranked. So in closing, we know, some of us don't care, we will |
30 |
disuss it during ranking. |
31 |
|
32 |
-Alec |
33 |
|
34 |
-- |
35 |
gentoo-dev@g.o mailing list |