:date: 2018-06-12 ====================== Tuesday, June 12, 2018 ====================== I did :ticket:`2402` (Site subscriptions instead of stars): I removed the stars, meetings and deploy plugins from :ref:`noi` and added a new model for "site subscriptions" (:class:`lino_xl.lib.tickets.Subscription`). This removed the fields :attr:`Ticket.reported_for` and `Ticket.fixed_for`. I deployed my changes to :ref:`jane`. Why the hell do I do this? I kick away three plugins into which Tonis and I had invested considerable time and energy. Okay they are not kicked away since they remain in :ref:`xl`. But Jane was their only production usage, and taking them out of production makes them inactive, which might lead to their death in the future. It's the kind of change which were impossible if we were a democratically managed team because I wouldn't dare to do it. I would never find the time to fully explain and discuss why I do it. I try to enumerate at least the reasons why I do it: I do this as a preparation for :ticket:`2408`. I tidy up and remove unused features that distract the end-user. Nobody ever starred a single ticket. Meetings and deployments were no longer used in practice. .. program:: pm dump2py The :xfile:`restore.py` process got killed while loading 15000 rows to the `github_commit` table. I worked around this by simply not loading this table because anyway this are only cached information and will be updated once per hour. This incident means that the default value for :option:`--max-row-count` should maybe change from 50000 to e.g. 10000. I did not automatically migrate existing stars into site subscriptions, I just manually created subscriptions for the active users. I started to test whether notifications work as expected. It's possible that I introduced some regression bugs. I observed that certain changes to a ticket were appearently not notified even before the upgrade : direct changes in a database field (e.g. the title of a ticket) and actions like e.g. change the state or assign_to_me.