On Fri, Jan 26, 2018 at 12:24:26PM +0100, Miriam Ruiz wrote: > 2018-01-26 12:02 GMT+01:00 Colin Watson <cjwat...@debian.org>: > >> Finding someone performing the daunting task of actually switching code, > >> documentation and existing databases over on the other hand… I at least > >> don't see me enthusiastically raising my arm crying "let me, let me, …". > > > > I don't blame you! > > Might that be a candidate project for GSOC?
I debated with myself if I should add a comment about gsoc/outreach, so as the "don't mention it" faction won due to length, let me give the opposition a chance to comment now: I don't think so. The size might be alright, but the task itself… The tasks should usually be something the mentors could and would do themselves (in less time), but propose them as interesting projects instead to trap unsuspecting students into not only completing their project, but hopefully sticking around now that they know the drill. This task on the other hand… the potential mentor isn't terribly excited about it: Big warning sign. The bigger problem is through that it is a dead end: As a student you will learn stuff about the now obsolete libdb, you are working on apt-ftparchive which is on life support (personally, I only touch it as testing apt is just easier if it comes with its own archive tool; for the same reason we have an libapt-based webserver… tends to be hard to convince other projects to implement broken behaviour so you can test against it) and after the project is done your knowledge isn't applicable to any other apt part… The visibility of your task isn't that great either: I did MultiArch in APT years ago and people are still complaining about it! That project on the other hand… not a lot of users – and the few you have will either never notice that you did something or stumble over a bug and complain that you did something – usually with a ~2 years delay as basically nobody is running a big archive on a Debian unstable box (no idea why…). For newbie motivation reasons you want the exact opposite. So that task feels more like: Nobody wants to do it, so lets convience Google/our sponsors to pay a GSoC/Outreach student to do it. (S)he wont like it, but we got the job done – other orgs do this, but I don't want Debian to do it, even if it has shortterm benefits (for me/us). If someone has money to burn we can probably find someone to do the job, we don't have to waste our perhaps once in a lifetime chance to make a student a longtime open source contributor with this task. I guess you can kill both birds with one stone if you go for a "write libdb-api-compatibility layer for your favorite other db", but that wouldn't really be a Debian task anymore. Without even thinking a split- second about the feasibility of this, that might be the more realistic way of deprecating libdb as I would imagine that most tools still using it aren't using it because its so great, but because the code exists and nobody feels like changing it. To finish the view point of apt-ftparchive: I guess at the time the libdb remove is immanent we will just remove the database support and be done. apt-ftparchive is hardly the only tool capable of producing an archive and most of these tools have a focused upstream… the apt client needed a server to start rolling, but nowadays this server side hustle is more a brake than an accelerator. Best regards David Kalnischkies
signature.asc
Description: PGP signature
