-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello.
I'd like to discuss my plans for 0.2 release for the validation dashboard a.k.a. launch control. I would like to have a roughly two-week development cycle. This will ensure that we don't get carried away with large features taking lots of time without planning them ahead of time. I would also like each release to feature some user-visible improvements (features or bug fixes) as well as backend infrastructure improvements (better tests, better internals, new feature elements that take >1 cycle to develop). I would like to reuse the proposal laid out by James Westby that defines how the infrastructure team plans future work and mix it a little with the original blueprint for the dashboard. What this means in practice is that each release should bring us closer to the feature set outlined in the blueprint _and_ introduce features/changes requested via the stakeholder process. I think this will work fine until we finish all of the features originating in the blueprint. For the upcoming 0.2 release (currently scheduled exactly two weeks after 0.1) I'd like to focus on the following topics: * Support for migrations south. South allows us to change the database on upgrades and plays nice with distributed version control. South is like rails migrations and is in general a very good thing. Without it we will soon start rolling out upgrade scripts that are just an ugly reimplementation of the idea. * Support for background (asynchronous) bundle processing. Currently the bundle is deserialized immediately during the put() request. This does not scale very well and we should really do this in the background. There are several solutions on how to implement background processing for Django apps and I'd like to select something _really_ simple until it is obvious we need more. There is a project called django-chronograph that essentially allows to use cron-like tasks inside django. Chronograph itself is triggered from cron (or some other external cron-like program) and then proceeds to process jobs defined within django apps. For this cycle I'd like to add chronograph dependency and move deserialization into a periodic task. * Better information about failed bundle imports. Currently there are some issues with the way databrowse application works (it seems to choke on OneToOne fields and GeneralRelation fields. This makes it impossible (AFAIR) to navigate to bundle deserialization information from the bundle itself and in general makes it hard to know what went wrong. I'd like to provide a basic set of views that show streams and bundles and provide a clear indication of deserialization errors there. This would be based on existing work on bundle stream views so it should fit in this cycle. * Better unit tests for django views. As discussed with James Westby we should have several approaches to each view we offer. We should test for the contents of the django rendering context (the data that goes in the template) _and_ scrub some of the HTML output to see we didn't make a typo in the template or other similar issue. In general we should add the front-facing view tests and I'd like to spend some time on this. * Initial work for JSON validator. There is a branch with generic JSON schema validator. I'd like to finish this branch (add several missing validators we need) and make it possible to include this validator in 0.3. It would change how we do deserialization from JSON to the database. It would no longer require us to use launch_control.models.* (so less dependency on client side code, something we wanted to have to be able to release them separately in the future). It would also dramatically improve the error messages. I would not merge the branch into trunk yet but rather merge several extra branches into the .json-schema branch itself and get those reviewed as usual. * Initial support for user authentication. I would like to add sign-in/sign-out elements to the web UI. This will allow us to have private/team streams and while not exciting in the short term it is a required step to getting full support for private (and non-anonymous) test data in the system. A roughly identical list of planned changes is also here in my redmine instance: http://suxx.pl/redmine/projects/launch-control/roadmap That is all. Please tell me what you think. Best regards Zygmunt Krynicki -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMnwZ1AAoJEKkR4hQBRI+lXmQIAJ+JUlYfz1bHWbEc47GqNZ/I w1JwFHDpmKNsDRvNAeYgYC1IRFSIhf8XiKOgCwWya4HHePmL5gTDA8AaTCz3R5zj mgNHOqawYLnx5reaffYDAKY8L4mDFknScUV5M416YIBvy//Cgfn4yJ4oY0e+3Lkv 6Z1fP607mokZzZNGYb1GOel51JZ4JpCnZqI+UJSOaIvLv2S2zyVtB9dhzNNCWNlf cFwtacwBEG7lTrftB98NzzkvHRkD76Qwt596wEpdaQqHe4oiqP2fUC+9+0X7XPkW XYJzRTKMA6M5dJNohtC5PChqhfR2JohSTiV+LMFyMh/smWqg1k4IrslsC69kXqI= =ZWBF -----END PGP SIGNATURE----- _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
