Struggles in Transparency: KFW 3.2.2
Last week was an eye-opening experience at least for those of us on the core team. I think we began to really appreciate how much of a shift this is going to be and how many small things were involved.
A lot of our release process is focused around being efficient for a small team. We’re going to need to introduce significant communications in order to make sure people not at MIT understand what is going on and are sufficiently involved in the process. I think the big challenge of this effort will be to find a way to do so without bogging down an already manpower-intensive release process to the point where it does not meet our efficiency goals.
There were a couple of issues that popped up during the KFW 3.2.2 discussion last week. First, a long-standing process has been to give the release engineer flexibility to defer requests to pull specific changes into a point release. The release engineer is responsible for deciding that some change was submitted to the point release too late and will need to wait until the next point release. They make a tradeoff between the value of the fix and the possibility that the fix will break something. There hasn’t previously been a notification of the decision to defer a pull-up request; there has been no need. However we ran into a situation where we needed such a mechanism. We’ve agreed to update our procedures.
MIT has had a long term policy of treating release schedules as confidential. We don’t want to get into a situation where someone is depending on a release coming out by a specific date, we have to slip and they run into trouble. We have worked with specific close partners to learn dependencies on our schedule and where possible we have met those dependencies. We have a good track record of meeting partner dependencies that we’ve committed to. However especially in the case of KFW, this model is inadequate. External contributors need to know when testing needs to happen. Being much more public about release schedules will be important for the consortium and for other external contributors as well. This is proving to be a bit rough to implement. However I think we made good progress on understanding what needs to happen last week; the challenge is to put it into practice for future releases.