I'm not sure fixing this in the packaging is the right solution here. If we have a patch to add the new classes (plural, there is the field model and the form model), then we will have to update the upstream code to match that (everywhere where it's imported plus in all the migration files where it's used). This mean that the packaging for Quantal (which will also use the same 1.2 upstream version) will have to contain that patch too. This leads me to the conclusion that changing this upstream is probably better. This would mean embedding a copy of the needed classes in our code and using them instead of the ones provided by Django.
Also, if we keep trunk as is, we will have a problem when upgrading from quantal to raring because one version will use the version of the field in Django and the other our own copy. A solution would be to have a DB migration in raring but, for reasons we already discussed (see the dev ml), we don't want the DB migrations to diverge like that. So the solution would be to keep using own version of the field (i.e. something like maasserver.generipfield.GenericIPAddressField), which, in trunk, could be a simple copy (as in GenericIPAddressField=django.db.models.fields.GenericIPAddressField) of the version in Django. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to maas in Ubuntu. https://bugs.launchpad.net/bugs/1130232 Title: Implement GenericIpAddressField in MAAS rather than django. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1130232/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
