Fwd: Re: Fwd: KDE Frameworks Release Cycle

[Michael Pyne]

On Thu, May 1, 2014 11:13:47 Harald Sitter wrote:
> On Thu, May 1, 2014 at 1:33 AM, Michael Pyne <mpyne at kde.org> wrote:
> >> Also ideally, we should break with this tendency of "upstream/downstream"
> >> and you should become upstream, I would love to see opensuse (and others)
> >> keeping the release you picked maintained in a branch.
> > 
> > I think this is wishful thinking. I mean, it would be nice to have happen
> > as well, but they can't all have that much extra manpower lying around
> > with nothing to do. Work they do to act as a virtual upstream is work
> > they can't do for their downstream duties, so you're asking them to stop
> > doing something they're doing now to pick up for kde.org duties.
> > 
> > They could just as fairly ask for us to start handing downstream packaging
> > chores.
> 
> But it isn't extra work or different work. It is the work a distro
> does anyway. As a distribution you pick a KDE platform release to use
> in your next distro release and unless your support cycle perfectly
> matches KDE's you then end up pushing patches to this version for your
> distribution exclusively because there's not going to be another
> official release of that platform version.

Where do those patches that get backported by distros come from? Normally KDE 
developers, no? So we still have to originate the patches in the first place.

So let's assume that the distros using a given Frameworks version as a base 
all band together to maintain their own LTS of that set to reduce the 
workload. We're asking them to take the patches we author, and backport to 
their common repository. And to do that they must not accidentally backport 
their own distro-specific customizations (if they're cooperating with other 
distros for maintenance). And they must also remove any features added in the 
interim if necessary, or get a policy exception/review for each such backport. 
If they do remove a feature, it may end up being required for some future 
"bugfix-only" commit that they should backport, which would mean that from 
their perspective the bugfix-only commit is really a bugfix+feature commit.

We can help automate this by adding keywords like BACKPORT: or BUG:, that's 
true, but you still need at the very least a manual review to determine if new 
features were added, since we leave it indeterminate. And each distro will 
probably have slightly different policies about what upstream bugfixes are 
acceptable for their own updated packages, which means that they may not even 
necessarily be able to cooperate on maintenance. And $DEITY only forbid that a 
bugfix-only patch in Tier 3 ends up silently relying on a previous 
feature+bugfix commit in Tier 1 of the same Frameworks version. And none of 
this has touched on the possibility of new library additions in the Frameworks 
delta between their baseline and where the bugfix is (and possibly needs).

I'm not as sure this would be a ton of work *in practice* as I was thinking 
yesterday, but even still, there's quite a "wow" factor associated with that, 
and it raises the potential for a ton of custom integration work just to 
backport patches, work that wasn't anywhere near as extensive with KDE 4.

I suspect that the non-rolling distros would on average simply not backport 
anything at all but the most serious or simplest bugfixes, assuming they can 
review every patch across our 50+ frameworks.

This would help solve our development problems to be sure, but I still really 
think that if anyone is going to be doing backporting (as opposed to distro 
customizations or integrations) it should be actual @kde.org developers either 
doing it or at least reviewing it. Failing that, we should make a concerted 
effort to determine if there's some other thing we can feasibly do to help our 
packagers out, whether that be commit message tags, "Tier {1..4} backport 
maintainers" to sanity review their backports, hosting cherry-picked stable 
branches, etc. As it stands we've just unilaterally attempted to transfer a 
lot of the work to the distributions, and the eventual consequences of that 
are predictable in a relatively straightforward fashion IMHO.

Regards,
 - Michael Pyne