[HyperKitty] #70: Not marking read
by HyperKitty
#70: Not marking read
--------------------+--------------------------
Reporter: langdon | Owner:
Type: defect | Status: new
Priority: major | Milestone: Beta version
Version: | Keywords:
--------------------+--------------------------
I am not sure if this is a bug or a feature request (not being overly
familiar with the requirements). I would expect hyperkitty to be tracking
read/unread for (at least) threads to help me keep track of where I am.
--
Ticket URL: <https://fedorahosted.org/hyperkitty/ticket/70>
HyperKitty <http://mm3test.fedoraproject.org>
The HyperKitty Django app provides a web interface to access GNU Mailman archives.
9 years
TODOs for Mailman suite 3.0, PyCon sprint plans
by Sumana Harihareswara
I chatted with Barry a few days ago to clarify what we need to do if we
want to release the Mailman suite, version 3.0, at the end of the PyCon
sprints. The sprints are April 13th-16th, 11 weeks from now. I used what
he said to update the TODO list for Mailman core, the client, Postorius,
HyperKitty, the bundler, and the suite as a whole:
http://wiki.mailman.psf.io/DEV/Mailman%203.0
If there are pieces that we ought to finish when we're together in
person, maybe they ought to go here:
http://wiki.mailman.psf.io/DEV/PyCon%202015%20Sprint
--
Sumana Harihareswara
http://brainwane.net
9 years, 3 months
Setting up Kittystore database impossible
by epirat07@gmail.com
I am trying to set up the Kittystore database as describe in the docs
with the following command:
kittystore-updatedb -p . -s settings -d
The problem is that this runs the migrations without ever initializing
the database, so it fails:
sqlalchemy.exc.OperationalError: (OperationalError) no such table:
patch u'\nDROP TABLE patch' ()
(Even when I create the table patch manually with sqlite3, it will fail
on the next migration, as it expects a lot of Tables which have never
been created)
9 years, 3 months
bug tracker, demo, and PyCon sprints
by Sumana Harihareswara
Hi! Thank you for working on HyperKitty! I'm hoping to help out, and I
have a few questions:
* I see open bugs listed at https://fedorahosted.org/hyperkitty/report/1
. Is that the issue tracker we currently use? Are all of those active
bugs still available for new developers to work on, or are some of them
actually solved in the current codebase? If we think the answer is "some
of these bugs are obsolete" then I'd like to know that, and I can go
through and triage them.
* Where can I see a recent version of HyperKitty (with test data)? I
know about https://lists.stg.fedoraproject.org/archives/ but I'm not
sure whether it is running the latest code.
Thank you! Also, I hope to see some of you at the PyCon sprints, April
13th - Thursday, April 16th 2015, in Montréal; I know some Mailman
developers plan to meet there and aim to finalize and release the full
Mailman 3 suite:
https://mail.python.org/pipermail/mailman-developers/2015-January/024147....
Regards,
--
Sumana Harihareswara
http://brainwane.net
9 years, 3 months
Merging HyperKitty and KittyStore
by Aurelien Bompard
Hey y'all,
After giving it much thought, I'm about to start merging HyperKitty and
KittyStore. But before I do that, I'll present you my arguments and would
be very happy if you had comments on them or on this change in general.
After all, I can't see all ends :-)
Arguments for the merge:
- Doing database requests in two different ORMs (Django/SQLAlchemy) is
error-prone, because results are sometimes similar in behavior and
sometimes not.
- Kittystore is just a library anyway, which reads HK's configuration, and
Mailman is hooked into HyperKitty directly, so it's all very linked (can't
be on different VMs).
- Sharing the caching engine is a real pain
- The class API in KS's store.py has to be regularly updated to accomodate
for HyperKitty's needs, and is currently just a large number of methods
returning the result of simple requests, often where only parameters
differs. It's going to be a maintenance nightmare.
- Noone else uses KittyStore, and if someone wants an access to the stored
email it's either going to be via REST, or we'll extract and design the API
then, when we have real requirements and not supposed ones.
- HK and KS must evolve at the same time to keep compatibility, so there's
no interest in separating one from the other to make the installation and
upgrade more flexible
- KS will now require a REST server and a background daemon to serve it,
and HK already has that.
- HK needs to have background operations capabilities to generate archive
mboxes, so background operations currently in KS can be migrated there
- Configuration and installation will be much easier, and the system will
be simpler to understand for administrators
Arguments against the merge:
- Load from long-running operations in Kittystore will not impact the
webserver (except for shared resources like CPU or DB server)
- The "push" path coming from mailman is better conceptually separated from
the "pull" path coming from the web
- Another application could, one day, import KS and query the DB without
importing HK (but today the API is not stable enough)
- If the webserver is down, Mailman can still archive the messages
(comment: but failure to archive is already backed up by the shunt queue in
mailman, and this argument is obsoleted by the new requirement of a REST
server in KS)
- Permissions on KS's REST server will be simpler since it can just listen
on localhost (comment: that's easy to limit in Django too)
Any other comments on those arguments? Am I missing something?
Thanks !
Aurélien
9 years, 3 months