On Wed, Jan 17, 2018 at 04:34:48PM +0900, Stephen J. Turnbull wrote:
Colin Watson writes:
I possibly should have explained our situation in a little more detail.
Well, I was pretty clear on your requirements, it turns out. I don't, and I believe I'm in agreement with the rest of the team here, need to know why you want something (at least not at this "let's see if we can hash out the requirements and the design a bit" stage). After all, even if we end up WONTFIXing it, it's open source and we're happy to talk about how you might do something even if we won't do it for you!
I appreciate that approach. At the same time, I also asked because I suspected I didn't quite understand the design principles involved. Thanks to both you and Barry for clarifying the intent of IArchiver; I'll drop that idea.
Postorius wouldn't come into it in our case
That's an interesting detail. Thing is, at present Postorius *is* the "control panel" for the whole suite (all the best bands are run by their bassists, you know), so we would bring it up if you left it out.
I'm not ruling out using it in future, but right now I think we'd prefer to stick with the approach of having the "control panel" integrated tightly into LP.
However, if you don't want to use Postorius, I think the mailman-client functionality will make it strightforward to implement your UI within Launchpad, and it now includes a nicer CLI so if you prefer to implement core and Hyperkitty functionality before the Launchpad side, mailman-client will allow you to test core features at that stage.
Indeed. And I'd managed to miss the existence of mailmanclient, so thanks for bringing that up.
I'd been thinking more of a new enum in HyperKitty for the visibility state, since it does seem like quite an archiver-specific thing.
Well, there is an enum in core for it already. I'm not sure how that works currently (specifically, how you go about telling Hyperkitty if that changes). Keeping that in sync is an issue (at least for us), since Postorius can query it, IIRC.
I just looked into what HK does, and I notice that it syncs the archive policy from Core as part of a regular update job. So I think the answer is that we just use that: perhaps set the ArchivePolicy to private and arrange that nobody has the ability to view it other than maybe list owners, or possibly add a new item to ArchivePolicy that's something like "deactivated" or "hidden". At any rate that looks a lot more tractable since most of the mechanism already exists.
Thanks,
-- Colin Watson [cjwatson@ubuntu.com]