Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 9 Jan 2023 12:45:46 -0300
From:   Arnaldo Carvalho de Melo <acme@kernel.org>
To:     Ian Rogers <irogers@google.com>
Cc:     linux-perf-users <linux-perf-users@vger.kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Google Summer-of-Code 2023
Message-ID: <Y7w2qshoCEjKKVlz@kernel.org>
References: <CAP-5=fWxF6in4vQyGuh=0kpAYEXAYZN_KobXCY=TX2oxssZ+HQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAP-5=fWxF6in4vQyGuh=0kpAYEXAYZN_KobXCY=TX2oxssZ+HQ@mail.gmail.com>
Precedence: bulk

Em Mon, Jan 09, 2023 at 07:28:26AM -0800, Ian Rogers escreveu:
> Hi,
> 
> The Linux Foundation will apply to be a mentor organization for the
> Google Summer-of-Code again this year. That application process starts
> on January 23rd. For the perf tool applying as part of the Linux
> Foundation, we have a good record of getting the contributors we ask
> for as part of the program. Contributors are very welcome! For the
> program we need mentors and project ideas. For mentoring the workload
> is to review changes, to attend the office hours with the contributor
> and to fill-in the 2 evaluations. For the project suggestions,
> anything goes. I've included links to last year's suggestions at the
> bottom. If you have ideas for projects then please reply to this
> email!
> 
> Last year there was confusion over whether people working in industry
> could be part of the program. Our answer was yes in terms of support,
> but they wouldn't qualify for the GSoC funding. I'll try to make this
> clear on our wiki, if it isn't already on the Linux Foundation's.
> 
> We'd like to continue having the requirements that applications have:
> 1) what the project will be,
> 2) a weekly time plan.
> To make the program run more smoothly this year, we're also going to
> add a requirement that the contributor has sent a patch to the mailing
> list. The patch doesn't need to do very much, say a documentation
> improvement, but I'd like to be strict and say that any application
> not meeting this bar be rejected. Thoughts about this, improvement
> ideas, and thoughts on what are good requirements are appreciated.

A project like perf, being out there for quite a while, accumulates tech
debt, such being a fact of life for any project.

This being so common, I'd encourage people to try and propose to fix
things not of their liking when trying to build, cross-build, use these
tools.

Being able to at least voice what you dislike, and possibly get some
money out of trying to fix it, out in the open, what an opportunity!

Go and try to fix things!

Thanks Ian for year after year to go and take the SOC opportunity to
improve perf.

- Arnaldo
 
> Thanks,
> Ian
> 
> https://wiki.linuxfoundation.org/gsoc/google-summer-code-2022
> https://wiki.linuxfoundation.org/gsoc/2022-gsoc-perf