Kevin Ottens ha scritto: > So, we had a team discussion here with Albert, Aleix, Alex, Alex, Aurélien, > David, Rohan and myself. We juggled with several options, trying to address > the following constraints: > * We don't have many contributors; > * We don't have enough testing in the stable branches, developers tend to > have a hard time to dog food those; > * We don't have enough contributions coming from the application developers > because it takes a lot of time for them to benefit from their changes so they > tend to workaround instead and consider kdelibs more and more as a black box; > going forward we don't want that for KDE Frameworks.
So, I've seen no discussion about this (not on this list, I think it's going on somewhere else) but I would like to rise my concerns with this decision. It can increase the "balkanization" of the version shipped by distribution. This is going in the opposite direction of the advocated "give users a real KDE experience". With no stable branches, distributions will have to randomly choose one branch to stabilize and the risk is that based on their schedule, they will choose different versions, heavily patching them (_more_ than what happens today, where there are few synchronization points). Other big projects with frequent releases, like the Linux kernel or Firefox have stable branches too; not all of the releases, but some of them. Firefox had to provide a "esr" version (long support, one year) because it's not really possible to update an entire stack in long-term supported distributions. And Firefox is mostly a leaf in the dependency tree (with the exception of libnss and libnspr, which can break and broke in the past from one esr to another); here we have an entire bunch of "core" libraries (as in Linux with its long-term branches). I understand that the big concern was about the testing: stable branches did not receive the same attention, but I think that killing them is not the solution; solutions include an increase number of automated tests (unit, integration, scenario) as first step, and a bit of time invested in the rest (manual) testing, with contribution of distributions but not only them. We had a lot of coding sprint, we can organize test sprints as well (which benefits also the main master branch, of course!) I also think that many frameworks will stabilize after the initial rush, so it will. I suspect (just a feeling, not backed by any fact) that Tier1 will stabilize sooner, Tier3 will have more moving part (please note that this is not about ABI/API, which I'm sure will keep the compatibility as it was before). If this is true, it could help in creating "naturally" stable branches; KDocTools is a good example, it's unlikely to have new important changes too frequently, but I guess it will be the same for KI18n and others. Minor point: the original statement of "three releases" for Porting Aids should be fixed to be time based (I guess at least 6 is not 9 months). So, my proposal(s). I think that some kind of long term branch branch is needed. It could be an yearly release (and we could do a testing sprint for that, solving the problem for the "love"), or a bit more frequent, like twice a year (no more!); still at least one release could benefit from a sprint. Collaboration from distribution is needed, so that they can coordinate. In case of yearly releases, if few distributions want to have an official stabilization branch (like in Linux) they will able to create and manage a special branch (with some input from developers). After the initial rush, revise the release schedule in the light of the "stable" frameworks, maybe they can be "naturally" on a stable branch (because no big changes will land in them). Possibility for opting out from the monthly releases for individual frameworks (i.e. still released with the bundle, but no monthly changes). I'm wondering about going this way on KDocTools. Ciao -- Luigi _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel