Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 15:36:10 Àlex Fiestas wrote: On Wednesday 30 April 2014 08:16:48 Scott Kitterman wrote: I get what you're asking for. What I'm trying to make clear is you aren't going to get it. Well, I'd say we try. Isn't there a chance Frameworks 5 WILL be quite relevant for Ubuntu? It would be smart of them to leverage these libraries for the Qt applications and phone stuff they are building... I understand the KDE Applications and Plasma are not that interesting for them, perhaps, but for sure the libraries should be. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
On Thu, May 1, 2014 at 1:33 AM, Michael Pyne mp...@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). HS ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On May 1, 2014 4:06:07 AM EDT, Jos Poortvliet jospoortvl...@gmail.com wrote: On Wednesday 30 April 2014 15:36:10 Àlex Fiestas wrote: On Wednesday 30 April 2014 08:16:48 Scott Kitterman wrote: I get what you're asking for. What I'm trying to make clear is you aren't going to get it. Well, I'd say we try. Isn't there a chance Frameworks 5 WILL be quite relevant for Ubuntu? It would be smart of them to leverage these libraries for the Qt applications and phone stuff they are building... I understand the KDE Applications and Plasma are not that interesting for them, perhaps, but for sure the libraries should be. No idea. You'd have to ask someone at Canonical. Whether they are or not doesn't affect this discussion. Stuff they develop themselves doesn't get the kind of exemption it's been suggested would be appropriate for KF5 and they've got all kinds of CI, automated tests, etc. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
Harald Sitter wrote: On Thu, May 1, 2014 at 1:33 AM, Michael Pyne mp...@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. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
I think this is so far the more insightful thing I have read so far. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Wednesday 30 April 2014 21:39:36 Alexander Neundorf wrote: Especially with all the KF5 bits is versioned bound to each others (so that to fix a bug in one component, you need to update *everything* - are you assuming that or is this indeed the case ? Do all frameworks depend on the same version of all other frameworks, or do they have specific required versions ? I haven't checked how it is done, I have only asked around how it is supposed to be done. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
On Thu, May 1, 2014 11:13:47 Harald Sitter wrote:
On Thu, May 1, 2014 at 1:33 AM, Michael Pyne mp...@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
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE Frameworks Release Cycle
On Thu, May 1, 2014 21:20:06 Sune Vuorela wrote: On Wednesday 30 April 2014 21:39:36 Alexander Neundorf wrote: Especially with all the KF5 bits is versioned bound to each others (so that to fix a bug in one component, you need to update *everything* - are you assuming that or is this indeed the case ? Do all frameworks depend on the same version of all other frameworks, or do they have specific required versions ? I haven't checked how it is done, I have only asked around how it is supposed to be done. The only dependency is that a Tier can depend on a lower Tier. Other than that we've essentially just announced that we're only vouching for the quality of Frameworks as a whole at a given version, although BC and SC compatibility guarantees will be there. Obviously in practice something like kio-5.5 might work just fine with kcoreaddons-5.3, but that's not a guarantee we're advertising in general with Frameworks unless it's listed somewhere else. Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
