On Wednesday 02 December 2009 18:57:45 Lubos Lunak wrote:
it repeatedly happens that there is a change introduced in the distribution that affects others yet those are not told at all or too late to do something about it.
Examples would be the removal of X configuration including keyboard layout from YaST as a consequence of deprecating Sax2, meaning that it is now not possible to change keyboard layout for KDM/XDM, or the upgrade of PackageKit to a newer version that no longer had PolicyKit as a dependency but instead started requiring its newer and backwards incompatible version polkit-1, requiring rewritting KDE support from scratch (which is the reason why KDE in 11.2 uses polkit-gnome). In the first case, I don't remember that mentioned anywhere, in the latter case, the kupdateapplet maintainer was notified (where it didn't really matter) but not the KDE maintainers. Others could probably come up with their own examples.
I'd prefer if such things didn't happen again, or at least if they were known in advance. And it even seems doable, because some changes already are announced, e.g. new gcc version, the switch to linking with --as-needed, etc.
Therefore I want to suggest that announcing important changes in the distribution that affect other components of the distribution becomes mandatory.
I'd go a step further and say these important changes should be presented, discussed and agreed on a fixed schedule, aligned with the roadmap milestones. Right now we have freezes for kernel/toolchain, then everything goes until a bit later, then translations. I've never been privy to the old dist meetings, having just passed on what will be happening in KDE during the release development window to the relevant managers, and I expect that for much of the community that want to be a part of making openSUSE the development process is even more obscure, consisting mostly of announcements from Coolo before deadlines. How about opening the Technical Project Manager's batcave and sharing what all the critical components and teams are that have input into release design, setting up a couple of rounds of meetings or email to present all these potential Outside Context Problems [1] that can spoil each other's release cycles, and making the rules clear to deter late breaking changes? I'm not talking about SLE levels of paperwork here. Will [1] http://en.wikipedia.org/wiki/Excession#Outside_Context_Problem -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org