I hope that a few opinionated engineers can help identify where some un-owned code should live.
Some of you have seen my branches update code to import from true module locations instead of canonical.launchpad.interfaces. I am landing these because my efforts to remove even a few lines from the c.l.i interfaces were results in cyclic import hell. I then started a long march to update all callsites that wrongly import from c.l.i. This 32,000+ line branch also failed from cyclic imports. I am landing smaller branches that fix what can be fixed, and reveals the underlying problems. I believe the single greatest problem are the modules in canonical.launchpad.interfaces. I know that some efforts to move them failed because of cyclic import complications. I think the proper course is to continue fixing the bad callsites, while moving the unclaimed modules in a trial and error fashion. I personally think Account and EmailAddresses are the most common problem because of their coupling with Person. Here is a list of unowned modules that need homes: account.py The foundations team has proposed deleting it or renaming it. If it really is to be nothing more than OpenId identifiers, then I image it should live in lp.services.openid authserver.py ? authtoken.py The foundations team created this for OpenID integration, but we changed plans again. I think this can be deleted or some of it returned to LoginToken emailaddress.py EmailAddress was Launchpad's means of managing identity, then it was subordinated to Account. If the foundation's team does intend to decouple EmailAddress from Account, I think EmailAddress belongs in lp.registry. If we continue to believe it is about identity, the lp.service.identity might be a place for it. Account could also go to this location. gpghandler.py lp.services.gpg launchpad.py Most of this belongs to lp.app. I favour moving it there then moving the exceptions later. launchpadstatistic.py lp.app librarian.py lp.services.librarian logintoken.py I do not think this is used for login anymore. I think it is a ConfirmationToken and that the primary use of it is by lp.registry. looptuner.py lp.services.looptunner lpstorm.py lp.services.storm mailbox.py lp.services.mail, looks like the migration was not completed mail.py lp.services.mail, looks like the migration was not completed message.py lp.services.mail, but we use this in a broader sense, maybe lp.services.message? oauth.py lp.services.oauth openidconsumer.py lp.services.openid packagerelationship.py lp.soyuz pathlookup.py lp.services.webapp schema.py ? searchservice.py lp.services.search temporaryblobstorage.py lp.services.librarian validation.py lp.services.validation, but could be lp.services.field -- __Curtis C. Hovey_________ http://launchpad.net/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
