Hi. Alex Kavanagh, Merlijn Sebrechts, Tim Van Steenburgh and myself met for the regular charms.reactive development discussions.
As some of us are again finding time for actual coding work, we discussed some smaller fully backwards compatible tasks to move forward with. We identified the work on deprecating interface layers and allowing them to be declared in standard layers as one task that can be immediately worked on. I plan to tackle this unless others beat me to it. I believe this only requires work in charm-tools' 'charm build', and related charms.reactive documentation. Another task is migrating the leadership layer into the base layer or charms.reactive core, per previous discussions. As the existing implementation is ok and not complex, I'm leaving this for anyone who wants to dip their toe into the code base. A simple job is documenting how layers should declare their license information. It seems a convention of LICENSE.layername or similar will work fine here and this just needs to be documented. Renaming states to flags should wait until we have a clearer idea of any necessary API changes. The rename gives us the opportunity to change the API while keeping the old API unchanged for backwards compatibility. Backwards compatibility was a bit of a theme, with Alex mentioning feedback he has received from charmers already having too much legacy code needing rewrites and not needing more. I will discuss my pull request on making the relations base class pluggable with Cory. This should allow us to start exploring flag implementations without the pain of using a charms.reactive fork. This would be an experimental feature rather than one actively supported and documented. A lengthy discussion was had on the triggers proposal ( https://github.com/juju-solutions/charms.reactive/issues/97 ). Some of my assumptions about this were false, as the proposal is actually for a mechanism to allow state/flag changes to be made after every handler (rather than 'preflight' code, run before the main reactive loop is started). Merlijn will work on compelling use cases to convince us on why this new feature would be a benefit. We should try to articulate any pain points with the current charms.reactive framework and bring them to the table. Not everyone is using charms.reactive the same way, and maybe there are issues people are having that need to be tackled. The group will be meeting again in another two weeks. Discussions welcome here or in github issues at https://github.com/juju-solutions/charms.reactive/issues :-) -- Stuart Bishop <stuart.bis...@canonical.com> -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
