Fwd: Re: Fwd: KDE Frameworks Release Cycle

[Harald Sitter]

(sorry that the mail go so long :/)

For everything I am going to say please keep in mind two things:

a) there's barely any distribution that actually releases in alignment
with KDE the feature version release day. So because only the previous
feature release is supported from a KDE POV, the status quo is that
distributions will either look the other way after a release has gone
EOL upstream or they start patching bugs on their own.
b) because of a) people are duplicating their work all the time as
everyone wants to fix bugs in their respective version (which at that
point really is a fork, yes, a fork)

On Thu, May 1, 2014 at 8:27 PM, Lisandro Damián Nicanor Pérez
<perezmeyer at gmail.com> wrote:
> 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.
>> Now how cool would it be if
>> people instead of doing these backports with a one-distribution scope,
>> would do it "upstream" for everyone to use. There's not much overhead,
>> in fact depending on the distribution policy on updates ther would be
>> none whatsoever (e.g. one would do a release "upstream" dubbed KDE SC
>> 4.10.8, based on the maintenance branch maintained by yoloLinux,
>> yoloLinux then goes ahead and channels the new/changed tarballs
>> through their distribution specific update process).
>
> I see your point here, but sadly that's also an ideal situation, and not
> what really happens. Allow me to give you some boundary conditions:
>
> - Not all packagers can understand the languages the software is written
> with → more error prone.

They are upstream bugs, so every distribution developer (I am not
actually talking about packagers specifically ;)) should have an
interest in doing their part as much as possible to get the bug
resolved. To that extent not everyone needs to understand the
languages involved, you just need to have a common ground where
someone from distribution foo will want to help someone from
distribution bar resolve an issue. And that common ground IMHO would
be a release that is relevant to both distribution foo and
distribution bar.

> - We definitely can't know every piece of code. So we are more error prone
> in doing bugfixes. No one better than upstream itself to ACK or not a patch,
> even do it.

We would not ack patches. What we would do is cherrypick accepted
fixes from master into a maintenance branch. There are two crucial
points that make this preferrable over just about anything that is
going on now.

As you mentioned, backporting something without having the original
author or maintainer or a sufficiently involved person look at it is
generally questionable because the backporting person might not fully
comprehend what is going on in a pice of code, and how it fits into
the larger picture. Yet a lot of distributions manage to patch their
packages to resolve bugs, build issues on specific platforms, provide
distribution integration and so forth. Most of the time in my
experience that happens without involvement of an upstream developer
of the piece of software in question, by doing the upstream bits
upstream we force ourselfs to involve the affected upstream
developer(s) in at least that portion of patchery.

Since I'd imagine there not being a maintenance branch for every
single monthly release, but instead have something that every stable
distribution would want to use you expose the entire backport to
substantial peer review and testing. Remembering that most
distributions currently have their kdelibs release of choice go  EOL
before the affected distribution release goes EOL; if one would want a
fix right now, one needs to do it for one specific distribution in a
distribution specific patch set. If we were to do things on KDE git
all distributions can offer QA and review.

> - It's not just pick a patch, apply it, build and push (which already takes
> quite some time). There are many intermediate steps that needs to be done
> just to get the package compiled and ready. Then there's the coordination
> with the stable release team to do the upload, watch for possible FTBFSs in
> all archs, etc.

What was suggested would be:

1) "include in upstream git" - this is essentially a git cherrypick,
followed by a make -j6, followed by a make test (assuming one has a
build setup, which one should have). Possibly the entire thing via
review request to get another dev to approve the cherrypick.

This is done by one person.

2) "pickup new maintenance release into $distribution" - this is
everything else you described (preping the package etc. etc.), this
part would essentially stay the same for everyone.

This is done by at least one person per distribution.

Back to the two intial assumptions: since everyone wants to support
their stable releases for as long as possible only orchestrating
upstream fixes upstream avoids people wasting time.

If 1) is not shared through KDE git (or other means if you will) 1) in
some form or fashion *is* being done by everyone who wants 2). And
that is as true now as it would be with a monthly rolling release
scheme for frameworks.

> I really think it will not be impossible to do *if* we had the human power
> or we did this as our dayjob (and actually that would be super cool), but we
> are already not having enough manpower for what we are doing now.
>
> Looking at another of your mails, you say:
>
>   "But, if you will, just consider for a moment how much bigger the pool
>    of available resources becomes if everyone starts actually doing their
>    things from within KDE rather than every distro doing their own thing,
>    fighting their own war, albeit against the very same foe of bugs and
>    mismatching software versions.
>
> That's also from the ideal of having one/two Linux distros. Sadly that's not
> happening and I don't foresee it will change: we al l have different
> expectations and schedules.

While I don't agree with the notion that 'what has not happened cannot
ever happen', I'll total hijack your schedules argument ;)

Indeed schedules are different for most of us. Which is why I have a
hard time understanding why everyone thinks what we have right now is
a good solution (regardless of whether we are talking about kdelibs or
the workspace). An upstream release (regardless of the patch version)
may be picked up by as little as 0 distributions or by as many as 5
godzillion. Considering that some distributions then additionally
offer other (opt-in) means to upgrade to a different version (OBS
repos, PPAs, etc.), even when a release was picked up by them they may
only make it available via these opt-in things giving the release an
effective user exposure of somewhere between 0 users and 10
godzillion.

So, the work one puts into the stable branch upstream can have next to
no value, or be the most crucial thing ever done in human history.
Which one it is going to be is nigh impossible to know beforehand. An
upstream person backporting fixes therefore might be wasting time, or
spending it very wisely.

If the people who actually play the role of pushing a release to the
masses (i.e. the distribution developers) were to orchestrate what
versions get prolonged support and at what points a release happens
one can easily make sure that every single releases gets maximum user
exposure. Making the time spent backporting that much more efficiently
spent.

HS