[Soc-coordination] upstream involvement
nicolas.dandrimont at crans.org
Wed Apr 10 07:41:06 UTC 2013
* Daniel Pocock <daniel at pocock.com.au> [2013-04-10 08:56:04 +0200]:
> 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
> I've proposed three project areas and I've already had enquiries from
> some excellent candidates for all of them.
> 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
- 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!
"We all know Linux is great...it does infinite loops in 5 seconds."
(Linus Torvalds about the superiority of Linux on the Amsterdam
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the Soc-coordination