On Sunday, May 04, 2014 16:27:44 Luigi Toscano wrote: > 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).
Maybe this should be considered seriously ? If we have more than 50 libraries, do all of them need a full new release every month ? As Luigi says, some of the smaller libraries may not see many changes at all, and maybe only "old style" patch level releases for them would be good enough ? Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel