[Soc-coordination] upstream involvement

[Daniel Pocock]

On 10/04/13 09:41, Nicolas Dandrimont wrote:
> Hi!
>
> * Daniel Pocock <daniel at pocock.com.au> [2013-04-10 08:56:04 +0200]:
>
>> Hi,
>>
>> I just want to get some feedback on the extent that we can involve
>> upstreams, either formally (as named mentor) or informally (e.g.
>> collaborating through upstream mailing list, contributing to upstream
>> source tree).
> I think upstream collaboration is a great thing for students to learn: Debian
> wouldn't exist without upstreams, and collaborating with them is key to
> improving not only Debian, but Free Software as a whole. However, see the
> caveat.
>
>> I've proposed three project areas and I've already had enquiries from
>> some excellent candidates for all of them.
> That's great.
>
>> The overriding goal of each project is to fix some gap in the Debian
>> eco-system, but some of the work may go into the upstream projects.  For
>> example, Debian has two TURN servers, neither of them supports
>> database-backed (SQL, RADIUS or LDAP) user/password storage or any other
>> distributed mechanism in Debian, so an interested student could really
>> work on either of those projects and it would fill that gap.  (Simply
>> making another TURN server would not fill a gap in Debian.)
> I feel that this specific example mostly fills a gap in upstream projects
> rather than in Debian, and I don't see how this prevents Debian from creating a
> "turn-key" solution for WebRTC.
In this case, it was a trivial example, and we would have to see the
proposals from students before having any detailed discussion about it

However, just to comment on making it a "turn-key" TURN solution, if
you'll excuse the pun, people who already have password hashes for
Apache DIGEST (which is well supported on Debian) can potentially use
them as an auth database for TURN - then they could just drop in a TURN
server package and enable WebRTC for all their Apache users.  This is
the type of convenience that I'm hoping Debian can deliver one day, and
it will enable any other web application in Debian to offer WebRTC.

> So, in my opinion, engaging with upstream to make the software packageable more
> easily, or to fullfill a Debian-specific requirement is okay, but making a
> project that only benefits upstream as a Debian project is not.
Just to make it clear: I'm not suggesting that any of my proposed
projects would be managed in a way that does not relate to Debian, I
don't think that would be reasonable at all.  The aim is simply to build
bridges between Debian and upstream, with a focus on areas of mutual
benefit.

> I understand this is part of a bigger project, but I feel that asking this of
> the student among Debian-specific tasks would make it too big a project.
>
>> One related issue then is the number of projects/students that Debian
>> will support: is there any hard limit on that, or is it only limited by
>> the number of mentors who come forward?
> The slot assignment is made by Google after the student application period
> closes. We, as admins for the organization, make a request to Google for some
> "hard" requirement, plus a number of "supplementary", nice to have slots.

Do you have any clues or guidance about these numbers?  Did Google
always fill the hard requirement in previous years, for example?  Does
GSoC as a whole operate within a fixed budget across all the projects -
are we effectively competing against other organisations to get those slots?

> We should make the slot requests according to those guidelines:
> (well, I don't know yet if the other co-admins agree with that, so take it as
> my feeling for now)
>  - We can't double-book projects, so we will ask mentors to rank proposals for
>    their projects and ask at most one slot per project.
>  - We won't overcommit mentors. I don't think it is reasonable for us to ask
>    for more than two slots for a given mentor. Heavy co-mentoring might change
>    that opinion.


Just to clarify my own intentions: I have proposed three project areas
for discussion, but I am not single-handedly commiting to mentor all
three areas.  As a minimum, I would be happy to mentor one student in
one area, or co-mentor several students across all those areas.  Now
that Debian is officially part of GSoC 2013, I am actively contacting
people inside and outside Debian to help build the mentoring team.  Once
we see the areas that more mentors and students commit to, then we can
find a way to move forward within the guidelines you've proposed. 
That's why it's really important for me to understand how to set
people's expectations and encourage the students to focus on the areas
that Debian will want to see.