hyperkitty's hackability

[Michael Burns]

Greetings hyperkitty-devel,

As I mentioned in a recent Fedora Infra thread [0], Mozilla is keenly interested in
Mailman 3 and HyperKitty in particular. As we make plans for the new year, I'd love to
get a feel for the state of HyperKitty and what its outlook is for 2013.

Obviously, bugs 21 [1] and 22 [2] are the big ticket items that require a lot of
groundwork to be laid before they get tackled. That being said, is there a plan of attack
for getting those features developed, or is that too far in the future still?

Besides those biggies, I'd love to hear how hackable y'all think the codebase is
to outsiders that might want to contribute. Are there any architectural changes in the
pipeline that we might want to wait to land into Trunk before getting involved?

Put another way: if you could snap your fingers and get an extra set of development hands,
what kind of work would it be most helpful for those hands to get dirty working on? UX/UI
frontend stuff, python hacking on hyperkitty's backend, or are there still
improvements needed in mailman3 itself to make hyperkitty's job easier?

Cheers!

[0] https://lists.fedoraproject.org/pipermail/infrastructure/2012-December/01...
[1] https://fedorahosted.org/hyperkitty/ticket/21
[2] https://fedorahosted.org/hyperkitty/ticket/22

-- 
Michael Burns
Mozilla IT

[Aurelien Bompard]

Hey Michael,

>  Obviously, bugs 21 [1] and 22 [2] are the big ticket items that
> require a
>  lot of groundwork to be laid before they get tackled. That being said, is
>  there a plan of attack for getting those features developed, or is that too
>  far in the future still? 
Well, my intention was to first have a working and at least
feature-equivalent archiver as soon as possible because Mailman 3 was
supposed to be released very soon. That was back in september, and
Mailman 3 is not out yet.
You're right, those features require quite a bit of work before they
can be tackeled, but if you think Mozilla will need them soon I guess
I'll start working on them in a separate branch. I think I can have a
working version using the local mail server rather soonish, maybe even
for FUDCon. That will not be enough because I suspect we'll run into
antispam problems (SPF for example) sending emails on behalf of the
user. The solution may lie in using the Sender header, but that takes
precedence in MS Outlook, so it's not ideal. I'll look into that
later.

>  Besides those biggies, I'd love to hear how hackable y'all
> think the
>  codebase is to outsiders that might want to contribute. Are there any
>  architectural changes in the pipeline that we might want to wait to land
>  into Trunk before getting involved? 
Nothing too big in my opinion. I'm considering moving my last big
feature, thread sorting, from HyperKitty to KittyStore for performance
reasons, and that will cause a schema change, but I keep track of that
and provide upgrade scripts.
There's something not-too-nice : HyperKitty uses Bazaar as its VCS on
fedorahosted, and KittyStore uses Git on Github. We'll need to sort
this out at some point, but it shouldn't block you from sending
patches, annoying as it is.

>  Put another way: if you could snap your fingers and get an extra set
> of
>  development hands, what kind of work would it be most helpful for those
>  hands to get dirty working on? UX/UI frontend stuff, python hacking on
>  hyperkitty's backend, or are there still improvements needed in mailman3
>  itself to make hyperkitty's job easier? 
I'd go with frontend stuff. For example tickets #9, #28 and #32 (those
last two should be easy). I've added a few items that were in my local
todo list, I'll try to use Trac's tickets more in the future.

URLs: https://fedorahosted.org/hyperkitty/ticket/9 &
https://fedorahosted.org/hyperkitty/ticket/28 &
https://fedorahosted.org/hyperkitty/ticket/32

The main trick with HyperKitty is the separation between the UI
(hyperkitty, Django-based) and the backend (kittystore, Python only).
HyperKitty "imports" KittyStore in the Python sense and calls its API.
We don't want to expose too much of the underlying ORM (Storm).
Actually, as little as possible :-)

It does have a varying level of roughness around the edges, so please
feel free to ask when something's not clear.

You are very welcome in the team !

Aurélien