* David Kalnischkies <david@kalnischkies.de> [2016-03-16 13:42:58 +0100]: > Hi, > > I would like to propose the following project with me as student and > Michael Vogt as proforma mentor, but before officially applying want to > gather some opinions about me and applying for said project: > > > = Project: APT↔dpkg communication rework = > > APT-based tools like apt-get, aptitude, synaptic, … work with the user > to figure out how their system should look like after they are done > installing/removing packages and their dependencies. The actual > installation/removal of packages is done by dpkg with the constrain that > dependencies must be fulfilled at any point in time (e.g. to run > maintainer scripts). > > Historically APT has a super micro-management approach to this task which > hasn't aged that well over the years mostly ignoring changes in dpkg and > growing into an unmaintainable mess hardly anyone can debug and everyone > fears to touch – especially as more and more requirements are tacked > onto it like handling cycles and triggers, dealing with "important" > packages first, package sources on removable media, touch minimal groups > to be able to interrupt the process if needed (e.g. unattended-upgrades) > which not only sky-rocket complexity but also can to be mutually > exclusive as you e.g. can't have minimal groups and minimal trigger > executions at the same time. > > The idea is to introduce an architecture similar to the "External > Dependency Solver Protocol" (EDSP) allowing different implementations > (and hence strategies) to be used interchangeably starting with the > current one and a second doing the minimal amount of work and instead > trying to work closer together with dpkg versions from this millennium > (yes, that is how old that code is). > > *Confirmed Mentor*: Michael Vogt > *Contact*: deity@lists.debian.org and #debian-apt Interesting project, thanks! > = David Kalnischkies (me) = > > I was a GSoC student back in 2010 already with "MultiArch in APT" (for > Debian if you haven't guessed that much) which converted me from a semi- > regular contributor to one of the current main developers, so me > applying again would certainly fail the outreach aspect. > > I am entertaining the idea of applying in the light of the "flip bits > instead of burgers" aspect through as I think that it would benefit > Debian greatly if someone could be convinced to invest a substantial > amount of time into it, but nobody had such an amount of free time > available and that is unlikely to change given the projects scope and > unappealing work involved, which I would declare (way) too big for > a newcomer to APT to have a realistic stab at – based also on previous > more limited projects the APT team had mentored in this area. > > > As said, I would like to ask for opinions about the sensibility of me > applying given this situation to avoid wasting time on both sides in > case a formal appliance is downright futile. *dons GSoC admin hat* If you're eligible to the program (which, if you're still a student, I believe you are), it doesn't make sense to not consider your application, as GSoC isn't restricted to new contributors (Outreachy is, however). When and if we need to consider which strong applications to pick (for instance if Google provides us with less slots than we have strong applicants for), then we will need to put the merits of each individual application in the balance (utility to Debian vs. outreach vs. quality of the application). Please send in your application, and we'll cross that bridge when we get there, shall we? Cheers, -- Nicolas Dandrimont BOFH excuse #403: Sysadmin didn't hear pager go off due to loud music from bar-room speakers.
Attachment:
signature.asc
Description: Digital signature