Fwd: Re: Fwd: KDE Frameworks Release Cycle

[Lisandro Damián Nicanor Pérez Meyer]

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.
- 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.
- 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.

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.

I think the corollary here is that this change will make upstream's work 
easier, but definitely not downstream's.