Today I talked a bit with Rex from Fedora's KDE team about their experiences with KDE's releases this last year and issues around backporting features. It really wasn't much different from what other downstream groups seem to be going through, and it is becoming ever clearer to me that we need some processes and tools in place to make the gathering of information and then channeling that into communication in place.
Nearly all our downstreams, while appreciating the improvements we've put in place over the last couple years, ask us to communicate even more. What do they want us to communicate, exactly, and how? That, it seems, is much harder for them to articulate clearly.
When it comes to them communicating in the opposite direction, there seems to be a lot of desire but little follow through on that in the good times and a scampering about without a lot of direction when challenges arise.
I'd like to know what the release goals, the release challenges and the release deviations (from upstream) are in the pipes. Preferably without having to visit each irc channel or set up conference calls with distribution representatives twice a year.
On the one hand I feel bad for our downstreams because we're obviously not their only upstream and nearly all of them could use more human resources as it is. On the other hand, it's pretty evident that we waste a lot of resources by not communicating more effectively.
It seems we could do well with an efficient mechanism of communication and tracking. Bugzilla's really not the tool for it, and it's not a matter of creating Gantt charts either. (Thankfully.) I think the patch server I wrote about a few years back is still a good idea, but that's really just for patches and doesn't address issues of coordination and communicating logistics.