Date: Sun, 28 Jul 2013 22:50:28 +0000 From: Matthew Windsor <mbw500@york.ac.uk> To: soc-status@freebsd.org Cc: Justin Edward Muniz <jmuniz@freebsd.org>, Eitan Adler <eadler@freebsd.org> Subject: GSoC Status: Week 6 and Half-Term Summary Message-ID: <CAFxS2ChZUvA6c3uQz%2BtFGrzw_LhM%2BLKJjskkqpmOPm4V=7S0tw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi there, The last soc-status report of the half-term and before I go on a slightly badly timed but pre-warned-in-proposal holiday is here. Most of the changes brought in this week are sorely untested and the last few might have broken off a few features that worked previously; as I said in the last commit I did, I'll have a look on Monday to see if anything can be quickfixed before the mid-term evaluation is up. Null-pointer asserts have been added into most of the existing code (r255055, r255056, r255077, r255099); obviously these aren't major improvements but hopefully they've instilled me with a more proactive outlook to adding in assertions in future and might trap some of the more stupid bugs I'm introducing as I go along. I wrote a very quick shell-script test for SearchFile (r255100) that compares its output to that of pkgng. More comprehensive testing is long overdue and something I definitely want to touch on in the next term. In r255152 I started working on UpdatePackages, but due to a misinterpretation of the pkgng API what I actually implemented here was UpdateSystem... which I then got confused with UpgradeSystem which is a different PackageKit action involving distribution releases. (Argh!) r255153, r255127, r255231 and r255240 continue this confusion. UpdateSystem hasn't been tested much (mainly because of it failing and the events system not picking up the error to report it correctly), but in previous pseudo-UpdatePackage issues it did seem at least to be solving correctly. At r255231 I finally started using full-length commit messages, as I realised while looking at svnweb that mine were below average in terms length and detail. >From r255264 and including r255265, r255266 and 255285, I've been working on replacing the query-based job resolution (as in, each action ending in a job goes through query/rquery first and then pours the resulting packages into their own jobs) with a system based on making one job and then checking its solution for PackageID failures. In the process, I've redone the current job-based actions (InstallPackages/UpdateSystem/RemovePackages) to use the new job system and also created UpdatePackages. This is the source of quite a bit of breakage in the current system, I fear, as it has been slightly rushed in order to have it done for this status update. I intend to give it a once-over tomorrow and do some informal fix-ups. Unfortunately I didn't get around to making the backend reject PackageIDs with no version, but this will probably be done tomorrow. So, at the end of the half-term, the backend has a lot of code implemented covering the core features of install/update/remove/search-by-name/get-details-of-package, and many of the common patterns (query-based actions, job-based actions, package manipulation, packageID manipulation) have been identified and abstracted. What remains really for the next half-term is to squish bugs (and there are *many* bugs, some of them show-stopping), round out the remaining functions, polish the code and ready it for a ports release with pushing to PackageKit as a possibility once it's ready. Finally, here is what I think will be the rough, minimal outline of work for next term (I'll have a more detailed overview before I head off on Tuesday): (Week: Goal) 6: Quickfixes on week 5 implementation 7: Remove query-based jobs; improve events system to provide correct errors on job failure; more in-depth checking for any issues remaining from the jobs change. 8: GetDepends, SearchDetails and GetRequires; at this stage with the exception of Cancel the backend should be at feature parity with ports. In-depth attempts to fix the install crash bug. 9: Try implementing Cancel, RepoEnable (text file hackery probably), and WhatProvides. Otherwise, tests. 10: Tests for each idempotent action. 11: Tests, where possible, for non-idempotent actions, jail/VM if possible. 12: Create a port and upload to ports tree. Also, final call for updating PackageKit: if possible, updating; if not, contingency and cleanup. Between soft and hard deadline: Contingency ~ Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFxS2ChZUvA6c3uQz%2BtFGrzw_LhM%2BLKJjskkqpmOPm4V=7S0tw>