Merge lp:~jtv/launchpad/recife-policy-mixin into lp:~launchpad/launchpad/recife
| Status: | Merged |
|---|---|
| Merged at revision: | 9179 |
| Proposed branch: | lp:~jtv/launchpad/recife-policy-mixin |
| Merge into: | lp:~launchpad/launchpad/recife |
| Diff against target: |
688 lines (+408/-78) 11 files modified
lib/lp/registry/interfaces/product.py (+1/-5) lib/lp/registry/model/distribution.py (+2/-1) lib/lp/registry/model/product.py (+14/-21) lib/lp/registry/model/projectgroup.py (+3/-2) lib/lp/translations/browser/pofile.py (+12/-17) lib/lp/translations/interfaces/potemplate.py (+6/-0) lib/lp/translations/interfaces/translationpolicy.py (+53/-2) lib/lp/translations/model/potemplate.py (+9/-24) lib/lp/translations/model/translationgroup.py (+20/-6) lib/lp/translations/model/translationpolicy.py (+104/-0) lib/lp/translations/tests/test_translationpolicy.py (+184/-0) |
| To merge this branch: | bzr merge lp:~jtv/launchpad/recife-policy-mixin |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Brad Crittenden (community) | 2010-11-08 | Approve on 2010-11-08 | |
|
Review via email:
|
|||
Commit Message
TranslationPoli
Description of the Change
= TranslationPolicy mixin =
In my ongoing work for the Recife feature branch, the ITranslationPolicy is growing from a placeholder for two pieces of configuration data into a place where translation policy is derived from that configuration data. Product, ProjectGroup, and Distribution all implement the interface.
At this point I'm extending the interface further and introducing TranslationPoli
I'm not actually making much use of the new class yet, but I have prototypes that move the related decision-making into the TranslationPoli
For testing I just ran all Translations tests except the windmill ones (which crash firefox on my system):
{{{
./bin/test -vvc lp.translations
}}}
Needless to say, these all pass. There were one or two tiny pieces of lint left, but none that I caused or dare fix.
Jeroen
| Robert Collins (lifeless) wrote : | # |
| Jeroen T. Vermeulen (jtv) wrote : | # |
Okay: I'm reworking this to be a dedicated class.
| Jeroen T. Vermeulen (jtv) wrote : | # |
The rework gets too big. I'll have to leave that for a separate branch.
| Brad Crittenden (bac) wrote : | # |
Hi Jeroen,
This branch continuing your work looks good. I understand your desire to not do the conversion from a mixin in this branch,but as follow on work.
In getTranslationP
Please run the copyright and import sort tools on your branch b/c I didn't pay any attention to sorting, etc.
Other than that the branch looks good.
| Jeroen T. Vermeulen (jtv) wrote : | # |
Hi Brad. Thanks for the review!
The restrictions POTemplate are such that one of {productseries, distroseries} is always None and the other is not. An attempt to do it differently would result in a database error, or possibly an assertion failure even before it gets to that. The fields are initialized once and then never changed, so there are no reasonable transient states that might deviate from the rule either.
Will run copyright and import sort tools. Thanks for the reminder.
Jeroen

I think this would be better as a dedicated class not a mixin. Other than that it seems reasonable to me.