Fwd: KDE Frameworks Release Cycle

[Aaron J. Seigo]

On Wednesday, May 21, 2014 17:29:10 Michael Pyne wrote:
> Sort of (and I would volunteer to do this for the one module I maintain).
> But not every frameworks module has an assigned volunteer, and not all
> volunteers would necessarily also want to maintain a separate stable
> branch.

imho this would be a less-than-good approach for 2 reasons:

* maintainers are usually key developers; so it would be back to the 
developers themselves backporting their own patches. the key idea in having 
such a stable branch maintainer is that they serve a gatekeeper role between 
developers and the backport landing. it's a kind of forced peer-review sanity 
check where every backport to stable gets explicitly justified. more than 
anything else, this will make backporters think a bit harder about those 
patches which should lead to more conservative, high-quality backports being 
proposed.

* it distributes the task amongst N people. that means many points of failure 
that must be tracked: if one framework lags in stable maintenance, it will 
reflect on the entirety of the Frameworks effort. it also means when submitting 
a patch for backporting, the developer needs to know who is the maintainer for 
that specific module. it would be far more streamlined to have just one or two 
people responsible for merging all proposed backports across Frameworks.

KDE is very used to working on decentralizing and spreading out tasks, which 
usually is definitely the better approach. in the case of backports and stable 
branch maintenance, it seems to not be the best approach (explaining KDE's 
struggles with that, perhaps). a more centralized approach for Frameworks is 
probably better, counter-intuitively in the context of the status quo.

(as an aside, i don't think this exact same approach/reasoning can be applied 
to _all_ KDE projects .. Frameworks has unique aspects to it)

> But beyond that, there's also the possible issue that all of these stable
> branches when integrated together would still have regressions. You'd really
> still want to have an "integration manager" to volunteer to ensure the
> units of Frameworks still work well when combined.

yes, that too.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140523/ee07ac81/attachment.sig>