On 10/04/13 09:41, Nicolas Dandrimont wrote: > Hi! > > * Daniel Pocock <[email protected]> [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. _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination
