[Soc-coordination] upstream involvement

[Nicolas Dandrimont]

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.

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.

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.

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.
 - Finally and most importantly, we will only request slots for projects that
   have a chance of succeeding, and that will directly benefit Debian.

Hope this helps clear things up!

Cheers,
-- 
Nicolas Dandrimont

"We all know Linux is great...it does infinite loops in 5 seconds."
(Linus Torvalds about the superiority of Linux on the Amsterdam
Linux Symposium)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20130410/e092bbc4/attachment.pgp>