1 |
Dear Michał,
|
2 |
|
3 |
Michał Górny <mgorny@g.o> writes:
|
4 |
|
5 |
> I would like to ask our this year's GSoC mentors a single question: |
6 |
> why weren't the GSoC proposals given proper discussion on our regular |
7 |
> mailing lists *before* they were accepted? |
8 |
|
9 |
> I can understand that most developers in Gentoo don't really care about |
10 |
> GSoC. However, both projects we have this year [1] involve major |
11 |
> changes to ::gentoo that -- by policy -- require prior RFC. In case |
12 |
> of the BLAS/LAPACK project there was a RFC *after* the project was |
13 |
> accepted, that was never fully answered. In case of the MPI project, |
14 |
> I'm not aware of any public RFC or announcement. |
15 |
|
16 |
The proposal has been discussed in regular mailing lists.
|
17 |
|
18 |
https://archives.gentoo.org/gentoo-science/message/4d0186acdce6df538a2740e0f1146ae6
|
19 |
|
20 |
At the proposal stage it was not sent to gentoo-dev, because I thought
|
21 |
only science project was relevant to BLAS/LAPACK. Later we find it to
|
22 |
be affecting more ebuilds, thus the RFC was sent to gentoo-dev.
|
23 |
|
24 |
https://archives.gentoo.org/gentoo-dev/message/d917547f7a9e1226fca63632a1e02026
|
25 |
|
26 |
> I believe such decisions put all of us in a very bad position. There is |
27 |
> a major work going on, almost secretly. In the end, we will either be |
28 |
> forced to accept the result even if it doesn't meet our expectations, or |
29 |
> reject it and turn GSoC into some kind of grotesque situation. |
30 |
|
31 |
Michał, you were overreacting to the word "GSoC" since our original RFC
|
32 |
at gentoo-dev. Please, just ignore GSoC when you are executing your
|
33 |
experise of QA. Gentoo should be developed independently, regardless of
|
34 |
whether any development effort is supported by 3rd party.
|
35 |
|
36 |
> The former is of course unacceptable from my point of view. It would |
37 |
> mean that one or two developers are able to abuse paid programs such |
38 |
> as GSoC to unilaterally push their preferences into Gentoo. We would be |
39 |
> forced to accept them unconditionally just because 'it's a done deal'. |
40 |
|
41 |
See above.
|
42 |
|
43 |
> The latter means the students has wasted their summer doing work that's |
44 |
> not going anywhere. This is certainly demotivating and a bad PR for |
45 |
> Gentoo. I suppose it also reduces our chance of getting into GSoC |
46 |
> again, if Google finds out that GSoC is spent on code going to trash. |
47 |
|
48 |
That's why we are working together to find the best solution and reach a
|
49 |
consensus.
|
50 |
|
51 |
> So, again, why do single developers unilaterally decide on which |
52 |
> projects third party money is spent, and never bother discussing whether |
53 |
> those projects are really applicable beforehand? |
54 |
|
55 |
I will leave this question to our GSoC manager.
|
56 |
|
57 |
Personally I don't regard the GSoC selection and decision process
|
58 |
interesting to all the Gentoo devs. If you are interested in GSoC and
|
59 |
would like share your ideas to recruit student enthusiasts, you are more
|
60 |
than welcomed to join our team.
|
61 |
|
62 |
> [1] |
63 |
> https://summerofcode.withgoogle.com/organizations/6416323580526592/ |
64 |
|
65 |
Cheers,
|
66 |
Benda |