KDE Frameworks Release Cycle

[Alexander Neundorf]

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