Attendees

Fujiwara
Kambe
Aharen
Michal
Jelte

ISC All-Hands

Most of the people from ISC are currently at the ISC All-Hands meeting. Today will be the last day, and they will be traveling back soon. I expect a few of them to return thursday, but am not too sure about it.

Current problems

Nobody is blocked on current problems right now

Tickets

There are a number of tickets that are dependent on other tickets, but given the total number of unassigned and open tickets this should not cause a problem for people trying to pick up new work. A bigger problem is the current lack of progress within this sprint, only 3 closed tickets so far. A lot of tickets are in review, and two are about done, but there are also a lot of unassigned tickets where work has not even started yet. Hopefully there is more done that we can currently see and once the ISC people return there will be some progress visible.

Open Issues

We probably do want to support dlopen'ed datasource backends at some point. However, this does require a bit of modification of the API (it has to be a C api). Michal suggested that there are some ways to do it, for instance there is a 'initialize-yourself-call' (we can look at how KDE does this for example). Jelte thinks that once we have a good factory function, changing that side of the code to use dlopen should not be too hard. There is general consensus that this work can be deferred. Fujiwara-san states that support for this is good, but not necessary.

Module-dependencies in Boss

Michal suggests that doing inter-module-dependencies ("module X needs module Y to run") is less work in the long term if we make this a part of the specfiles (as opposed to hardcoding it in boss). Not only should it be pretty simple in terms of what is needed in the spec, it is also necessary for future module developers so they do not have to change the boss code to implement their module deps.

Another option for now is to skip dependencies completely, and make it the responsibility of the administrator. We can create a feature ticket for future development of this, and for now simply state which modules need which other modules.

Jelte suggests that we might have more complicated dependencies that just 'module X'; an xfrout module could be dependent on Auth module, but we could also have a 'mini-auth' which only serves SOA records, in which case xfrout would be dependent on either of those auths, but not specifically on any of them. Michal suggests that this would certainly be future work (as in, year five work). People agree.

For now it is agreed to not do them at all, and add a ticket to add support for this later.