On Wednesday 30 April 2014 at 09:19:57, Raymond Wooninck wrote:
It seems that you really have a big issue with openSUSE because of
bluedevil. At the moment that the Gnome team indicated that they didn't had
any choice than to ship Bluez5 (as that the Gnome version only would
support Bluez5), I
(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
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
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
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
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
On Wednesday 30 April 2014 10:17:23 Sune Vuorela wrote:
On Tuesday 29 April 2014 23:20:21 Lisandro Damián Nicanor Pérez Meyer wrote:
The result will be that we will need to freeze at some point and do our
best to keep up with patches for stable releases. Or maybe even drop KF5
for stable
On Wednesday 30 April 2014 10:41:30 Raymond Wooninck wrote:
For openSUSE it will definitely bring problems as that we wouldn't be able
to release any maintenance updates anymore for the KDE Desktop with this
Release Cycle. As Sune indicated, if KF5 is updated then the other
components like
On Wednesday 30 April 2014 11:28:26 Àlex Fiestas wrote:
Having a release every month will allow distributions to package fresher
versions of frameworks since we will virtually remove the synchronization
problem.
As an example, Opensuse released 13.1 with KDE 4.8.5 iirc, which already had
no
On Wednesday 30 April 2014 12:04:15 Raymond Wooninck wrote:
On Wednesday 30 April 2014 11:28:26 Àlex Fiestas wrote:
Having a release every month will allow distributions to package fresher
versions of frameworks since we will virtually remove the synchronization
problem.
As an example,
On Wednesday 30 April 2014 12:26:14 Àlex Fiestas wrote:
Here you have the link to the release that released with an almost out of
support version:
https://en.opensuse.org/Archive:Features_12.2#KDE_Plasma_Workspaces
As you can see, the link shows the features of OpenSuse 12.2 featuring
On April 30, 2014 6:26:14 AM EDT, Àlex Fiestas afies...@kde.org wrote:
On Wednesday 30 April 2014 12:04:15 Raymond Wooninck wrote:
On Wednesday 30 April 2014 11:28:26 Àlex Fiestas wrote:
Having a release every month will allow distributions to package
fresher
versions of frameworks since we
On Wednesday 30 April 2014 07:50:02 Scott Kitterman wrote:
The difference is that you will do proper testing with all the QA in
place on
each distros, we don't have such thing upstream beyond the tests.
As for the mess, each distro picks their version as you said and you
(as in
distros)
On Wednesday 30 April 2014 13:44:50 Raymond Wooninck wrote:
So, you will not simply update to 4.14.X but instead do cherry-picking of
the bug fixes? Because that would be the same with Frameworks.
You got that one wrong :) We push the 4.14.x release as a full maintenance
update. So if
Hi,
(Disclaimer: I'm not a KDE packager, just a user and an occasional
contributor)
It is, you (as in opensuse) just have to get over the drama of having small
features in on each release.
Let's try to analyze a bit why some distros have this panic to new versions
containing features
On April 30, 2014 9:56:30 AM EDT, Àlex Fiestas afies...@kde.org wrote:
On Wednesday 30 April 2014 07:50:02 Scott Kitterman wrote:
The difference is that you will do proper testing with all the QA in
place on
each distros, we don't have such thing upstream beyond the tests.
As for the mess,
On Wednesday 30 April 2014 16:22:43 Ralf Jung wrote:
Hi,
(Disclaimer: I'm not a KDE packager, just a user and an occasional
contributor)
It is, you (as in opensuse) just have to get over the drama of having
small
features in on each release.
Let's try to analyze a bit why some
On Wednesday 30 April 2014 17:24:42 Àlex Fiestas wrote:
This is a problem that already exists, for example in bluedevil I have had
enormous problems because distros would have either an ancient version or a
git snapshot.
I was already waiting for this story to re-appear again.
Current
On Wednesday 30 of April 2014 17:24:42 Àlex Fiestas wrote:
...
So with frameworks I think we can compromise with something like last 5
releases and turn off auto reporting for anything older than that (this
is just an example).
This essentially means distros (non-rolling ones at least) would
On Wed, Apr 30, 2014 at 6:19 PM, Raymond Wooninck tittiatc...@gmail.com wrote:
So with frameworks I think we can compromise with something like last 5
releases and turn off auto reporting for anything older than that (this
is just an example).
So in other words, this means that you are
On Wednesday, April 30, 2014 15:51:56 Àlex Fiestas wrote:
On Wednesday 30 April 2014 13:44:50 Raymond Wooninck wrote:
So, you will not simply update to 4.14.X but instead do cherry-picking
of
the bug fixes? Because that would be the same with Frameworks.
You got that one wrong :)
On Wed, April 30, 2014 11:28:26 Àlex Fiestas wrote:
As for the backporting, you could use bugzilla (even via api) to get a list
of everything that has been fixed, get the SHA and backport it
automatically, that will ease a lot the process.
Is there any reason we can't do this? Even if it's a
On Wed, April 30, 2014 15:51:56 Àlex Fiestas wrote:
So, I understand that for big releases you wouldn't trust us on no
regressions, but please take into account that these releases will be a
completely different monster.
Finally, could you (or any packager with similar concerns) explain to
23 matches
Mail list logo
