On Saturday, July 13, 2013 09:50:21 Luca Beltrame wrote: > Aaron J. Seigo wrote: > > 1. packagers seem to feel that if upstream doesn’t do the actual commit to > > the upstream repository, then upstream is not maintaining their software > > To be honest, that's not always true.
Good :) > At least the major distributions and a > few of the minors have packagers that hold KDE developers accounts. The Yes ... > problem is, as I can see, numbers (those people are a minor percentage of > $DISTRO_CONTRIBUTORS and they also do packaging) Which is why I wrote: "we should try to recruit more people from the user community of downstream distributions who have the skills necessary to merge patches and test. some distributions do this already.” > and sometimes expertise (I > can touch CMake files and perhaps do little adjustments in C++, but nowhere > near fixing complex bugs). Backporting usually does not require that level of skill with C++. When it does, we can certainly call on upstream developers to help out. Most of the changes that would appear in these extended bug fix releases would be just that: backports. A bug fixed in x.y.z should appear in x.y+1, after all. A significant % of code changes in bug fix releases tend to be backported fixes. Exceptions to that most often occur where the code has changed significantly in a future release in such a way that the bug simply no longer exists in that future release; we’ve done that a few times over the years in Plasma Desktop by replacing a plasmoid (for instance) completely. Then backporting is not so much of an option without taking the whole new plasmoid (which usually isn’t a good idea). In which case, one may just have to live with the bug in the older versions. The question is whether the above is a reason to not have 3 month release cycles? (Or whatever # of months is agreed on, where that # is less than 6) -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.