Merge lp:~terceiro/lava-manifest/crowd-config into lp:~linaro-validation/lava-manifest/trunk
Proposed by
Antonio Terceiro
Status: | Rejected |
---|---|
Rejected by: | Antonio Terceiro |
Proposed branch: | lp:~terceiro/lava-manifest/crowd-config |
Merge into: | lp:~linaro-validation/lava-manifest/trunk |
Diff against target: |
34 lines (+2/-12) 3 files modified
buildout-production-crowd.cfg (+0/-12) buildout-production.cfg (+1/-0) buildout.cfg (+1/-0) |
To merge this branch: | bzr merge lp:~terceiro/lava-manifest/crowd-config |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Paul Sokolovsky | Abstain | ||
Tyler Baker | Pending | ||
Linaro Validation Team | Pending | ||
Review via email: mp+176838@code.launchpad.net |
Description of the change
Always have django-
Related: https:/
To post a comment you must log in.
Unmerged revisions
- 171. By Antonio Terceiro
-
make djando-
crowd-auth- backend a hard dependency always
Antonio, well, that's something which we discussed with you during first days - should we hardcode Crowd dependency and burden every install (including 3rd party) with it? As you remember, I first did it this way, because it's, well, easier. And I understand that OpenID is done this way, but OpenID is open standard of choice for cross-authentic ation. And Crowd is one of many proprietary solutions. It's clear that we can't put support for dozen of adhoc and proprietary auth mechanism into (core) LAVA, so should we add even 1 into core (even if that's what we use). This all is also aggravated by the fact that Django Crowd auth backend we use is not in the best shape - it's fork of a fork, with not completely clear licensing and uncertain upstreaming opportunities - just another reason I didn't want to install it on each and every user system.
So, when (briefly) discussing this with you and Tyler during Connect, I got impression that you look positively into splitting Crowd support as a separate config. I actually wanted to sit together with you and Tyler and make sure that we made explicit decision, but that didn't happen. So, due to reasons above, I went ahead with the split-off, hoping that Tyler will review it for being ok. Due to all that, I can only abstain in reviewing this patch - it looks correct for what it does, but I can't be authoritative if this is good distribution-wise. I'd suggest pulling Tyler into discussing that.