Le jeudi 17 février 2022 à 11:09 PM, Albert Astals Cid a
>> écrit :
>>
>> > El dijous, 17 de febrer de 2022, a les 21:16:30 (CET), Carl Schwan va
>> > escriure:
>> >
>> > > Hi :)
>> > > Could we get Kalendar inside KDE Gear? Kalendar is mos
t; > > Could we get Kalendar inside KDE Gear? Kalendar is mostly stabilized
> > > and need a fast release cycle anymore.
> >
> > I am guessing you forgot a "doesn't" before that "need a fast", right?
>
> yeah :)
>
> > > More import
Le jeudi 17 février 2022 à 11:09 PM, Albert Astals Cid a écrit :
> El dijous, 17 de febrer de 2022, a les 21:16:30 (CET), Carl Schwan va
> escriure:
>
> > Hi :)
> > Could we get Kalendar inside KDE Gear? Kalendar is mostly stabilized
> > and need a fast release cycle
El dijous, 17 de febrer de 2022, a les 21:16:30 (CET), Carl Schwan va escriure:
> Hi :)
>
> Could we get Kalendar inside KDE Gear? Kalendar is mostly stabilized
> and need a fast release cycle anymore.
I am guessing you forgot a "doesn't" before that "need a fast&q
Hi :)
Could we get Kalendar inside KDE Gear? Kalendar is mostly stabilized
and need a fast release cycle anymore. More importantly, having our
release in sync with KDE PIM will help a lot in making sure that
a KDE PIM minor release won't break Kalendar silently and this would
also, allow us
On Sunday, May 04, 2014 14:38:01 Martin Graesslin wrote:
...
I think it's great that Kubuntu does downstream testing. But what would be
much better is if Kubuntu would do the testing upstream. E.g. I'm sometimes
too scared to take a patch into the branch as it doesn't get tested. Thus
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
I'm chiming in late on this discussion, but:
On Tuesday 29 April 2014 at 23:20:21, Lisandro Damián Nicanor Pérez Meyer
wrote:
I don't know how other major distros with focus in stability work, but I
think they will be more or less in the same position (I'm thinking in Red
Hat, Centos, Suse
On Wednesday, May 21, 2014 17:29:10 Michael Pyne wrote:
Sort of (and I would volunteer to do this for the one module I maintain).
But not every frameworks module has an assigned volunteer, and not all
volunteers would necessarily also want to maintain a separate stable
branch.
imho this would
Hello,
On Tuesday 20 May 2014 16:38:54 Aaron J. Seigo wrote:
keeping in mind that this thread is not about Plasma or any of the KDE
applications, the expectations and goals of the *Frameworks* developers
_and_ users (app devs) are probably unique in this case.
the Frameworks team would
Good morning crowd
Looks like we've more or less an agreement or idea that could work for most of
us.
- Monthly features releases of KF5 with keyword for bugs to backport.
- 6/12 monthly (still to be decided) stable branches (with optionally a
release script that tags it monthly, is this
On Wednesday, May 21, 2014 10:32:49 Mario Fux wrote:
Good morning crowd
Looks like we've more or less an agreement or idea that could work for most
of us.
- Monthly features releases of KF5 with keyword for bugs to backport.
- 6/12 monthly (still to be decided) stable branches (with
On Wednesday, May 21, 2014 10:17:15 Kevin Ottens wrote:
The aim is the following in my books:
Thanks :)
Obviously the difficult point as certainty goes is the last one, as it is
highly dependent on the amount of contributions which mainly come from
volunteers and on the amount of time
On Wednesday 21 May 2014 11:28:45 Aaron J. Seigo wrote:
On Wednesday, May 21, 2014 10:17:15 Kevin Ottens wrote:
The aim is the following in my books:
Thanks :)
Obviously the difficult point as certainty goes is the last one, as it is
highly dependent on the amount of contributions which
On Wednesday, May 21, 2014 16:12:50 Kevin Ottens wrote:
On Wednesday 21 May 2014 11:28:45 Aaron J. Seigo wrote:
On Wednesday, May 21, 2014 10:17:15 Kevin Ottens wrote:
...
This type of branch got actually
discussed before making the initial proposal, it's not that we don't
like
the
On Wed, May 21, 2014 22:40:07 Alexander Neundorf wrote:
On Wednesday, May 21, 2014 16:12:50 Kevin Ottens wrote:
On Wednesday 21 May 2014 11:28:45 Aaron J. Seigo wrote:
On Wednesday, May 21, 2014 10:17:15 Kevin Ottens wrote:
...
This type of branch got actually
discussed before
On Monday 19 May 2014 22:28:27 Scott Kitterman wrote:
Speaking as a packager for a distro that's in group #2, I don't see this as
any change from your initial proposal.
That's correct...
You're proposal moves us into group #1
... which is what I stated I think.
Chosen extracts:
Going
On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens er...@kde.org wrote:
On Monday 19 May 2014 22:28:27 Scott Kitterman wrote:
Speaking as a packager for a distro that's in group #2, I don't see this as
any change from your initial proposal.
That's correct...
You're proposal moves us into group
only the new status quo forever, I say
let's try and find out.
In the meantime, everyone but the developers will suffer.
Yes, and saying no to every proposal won't change that.
I believe that the only advantage of the current situation (slow release
cycle with a period of 'bugfixes' that go
of the current situation (slow
release
cycle with a period of 'bugfixes' that go untested) seems to be that it
is a
known evil: we're lying about them being stable bugfix releases but the
They are almost completely bugfix. Every now and then something slips through,
but those are mistakes.
We
, and saying no to every proposal won't change that.
I believe that the only advantage of the current situation (slow
release
cycle with a period of 'bugfixes' that go untested) seems to be that it
is a
known evil: we're lying about them being stable bugfix releases but the
They are almost completely
.
In the meantime, everyone but the developers will suffer.
Yes, and saying no to every proposal won't change that.
I believe that the only advantage of the current situation (slow
release
cycle with a period of 'bugfixes' that go untested) seems to be that it
is a
known evil: we're
On Tuesday, May 20, 2014 08:04:59 Kevin Ottens wrote:
On Monday 19 May 2014 22:28:27 Scott Kitterman wrote:
Speaking as a packager for a distro that's in group #2, I don't see this
as
any change from your initial proposal.
That's correct...
You're proposal moves us into group #1
On Tuesday 20 May 2014 07:19:59 Scott Kitterman wrote:
On May 20, 2014 4:19:26 AM EDT, Jos Poortvliet jospoortvl...@gmail.com
So after 5.0, 5.0.1 is released with minor features and bugfixes (but
no mandatory changes in dependencies at all); which continues until
January, when 5.1 comes out,
On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote:
I'm open to discussing change, but so far the change is You're on your own,
get over it. Not a lot to discuss in that.
It's not at all the way it's been thought, it is unfortunate if it is
perceived that way. Looks like I can't frame and
On Tuesday, May 20, 2014 14:07:02 Kevin Ottens wrote:
On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote:
I'm open to discussing change, but so far the change is You're on your
own, get over it. Not a lot to discuss in that.
It's not at all the way it's been thought, it is unfortunate
On Tuesday 20 May 2014 08:00:43 Scott Kitterman wrote:
On Tuesday, May 20, 2014 08:04:59 Kevin Ottens wrote:
On Monday 19 May 2014 22:28:27 Scott Kitterman wrote:
Speaking as a packager for a distro that's in group #2, I don't see this
as
any change from your initial proposal.
Am Dienstag, 20. Mai 2014, 14.09:18 schrieb Scott Kitterman:
Morning Scott
On Tuesday, May 20, 2014 14:07:02 Kevin Ottens wrote:
On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote:
I'm open to discussing change, but so far the change is You're on your
own, get over it. Not a lot to
On May 20, 2014 8:27:39 AM EDT, Kevin Ottens er...@kde.org wrote:
On Tuesday 20 May 2014 08:00:43 Scott Kitterman wrote:
On Tuesday, May 20, 2014 08:04:59 Kevin Ottens wrote:
On Monday 19 May 2014 22:28:27 Scott Kitterman wrote:
Speaking as a packager for a distro that's in group #2, I don't
On Tuesday 20 May 2014 08:52:39 Scott Kitterman wrote:
That's how it comes across to me. There was a lot of negative feedback the
first time and the reaction to that comes across to me as a patronizing
repetition of the initial proposal wrapped up in IMO unfounded assurances
that it would be
On May 20, 2014 8:52:30 AM EDT, Mario Fux kde...@unormal.org wrote:
Am Dienstag, 20. Mai 2014, 14.09:18 schrieb Scott Kitterman:
Morning Scott
On Tuesday, May 20, 2014 14:07:02 Kevin Ottens wrote:
On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote:
I'm open to discussing change, but so
hi ...
it would be interesting to see a true cost/benefit analysis using real data of
the benefits of the monthly bug fix releases.
in support of what Kevin is going after here:
the monthly bugfix releases sound awesome on paper, but they don't always work.
i've seen significant regressions
developers would like to provide regular updates to users
which are tested well (in order to prevent annoying regressions which
ruin the user experience, and possibly, also KDE's reputation).
It has become obvious that the initial 1-month release cycle plan
might not work out fully as expected due
On May 20, 2014 10:38:54 AM EDT, Aaron J. Seigo ase...@kde.org wrote:
hi ...
it would be interesting to see a true cost/benefit analysis using real
data of
the benefits of the monthly bug fix releases.
It would. I've no idea how to do it. My impression is providing them is
popular with our
that the initial 1-month release cycle plan
might not work out fully as expected due to distro policies which will
not change. But in any case, even if a distro would not update the KF5
version that it shipped with initially at all, then at least we would
prevent that code which has seen little to no testing
On Tue, May 20, 2014 16:38:54 Aaron J. Seigo wrote:
in support of what Kevin is going after here:
the monthly bugfix releases sound awesome on paper, but they don't always
work. i've seen significant regressions in recent releases due to patches
being backported with poor judgment, resulting
Hello all,
First of all, my apologies for the long time taken for me to send an email.
So, this release cycle proposal generated more debate among our dear packagers
than we anticipated. I tried to keep up with the thread, but too be honest
it's far too long at that point and also
On Monday, May 19, 2014 15:18:49 Kevin Ottens wrote:
Hello all,
First of all, my apologies for the long time taken for me to send an email.
So, this release cycle proposal generated more debate among our dear
packagers than we anticipated. I tried to keep up with the thread, but too
[Taking k-c-d out, too much cross-posting]
On Monday 05 May 2014 21:54:42 Alexander Neundorf wrote:
If we have more than 50 libraries, do all of them need a full new release
every month ?
Not doing that leads to
1) a huge mess of versioning. The latest available version for each framework
On Thursday, May 08, 2014 22:08:06 David Faure wrote:
[Taking k-c-d out, too much cross-posting]
On Monday 05 May 2014 21:54:42 Alexander Neundorf wrote:
If we have more than 50 libraries, do all of them need a full new release
every month ?
Not doing that leads to
1) a huge mess of
On Sunday, May 04, 2014 02:38:01 PM Martin Graesslin wrote:
I think it's great that Kubuntu does downstream testing. But what would be
much better is if Kubuntu would do the testing upstream. E.g. I'm sometimes
too scared to take a patch into the branch as it doesn't get tested. Thus
On Sunday, May 04, 2014 16:27:44 Luigi Toscano wrote:
Kevin Ottens ha scritto:
So, we had a team discussion here with Albert, Aleix, Alex, Alex,
Aurélien,
David, Rohan and myself. We juggled with several options, trying to
address
the following constraints:
* We don't have many
On Wednesday 30 April 2014 21:56:12 Alexander Neundorf wrote:
On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote:
On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
For non-rolling distros, at some point you have to stop and release. A
mix
of new features and bug fixes
On May 4, 2014 4:25:25 AM EDT, Martin Graesslin mgraess...@kde.org wrote:
On Wednesday 30 April 2014 21:56:12 Alexander Neundorf wrote:
On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote:
On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
For non-rolling distros, at some point
On Sunday 04 May 2014 08:09:21 Scott Kitterman wrote:
On May 4, 2014 4:25:25 AM EDT, Martin Graesslin mgraess...@kde.org wrote:
On Wednesday 30 April 2014 21:56:12 Alexander Neundorf wrote:
On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote:
On Tuesday 29 April 2014 19:23:07 Scott
(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 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
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
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.
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 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
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 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
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 releases :-/
While I don't share the fatalistic point of
Am Mittwoch, 30. April 2014, 04.20:21 schrieb Lisandro Damián Nicanor Pérez
Meyer:
Morning
For Ubuntu I can use the Firefox example. So can you explain why is KF5
different than firefox?
Firefox (and Chromium too) are handled like no other packages in the
archive. It's the best
updates anymore for the KDE Desktop with this Release
Cycle. As Sune indicated, if KF5 is updated then the other components like
Plasma-Next and the Applications needs to be rebuild. This is not the current
setup of the openSUSE maintenance process, nor will this change just for KF5.
This means
Am Mittwoch, 30. April 2014, 10:17:23 schrieb Sune Vuorela:
So quite many users will end up using patched-up versions of KF5
if every distro has its own patched version, bug reporting and
fixing will get much more difficult.
Where should a bug be reported? The only logical choice seems to
be
On April 30, 2014 3:32:02 AM EDT, Mario Fux kde...@unormal.org wrote:
Am Mittwoch, 30. April 2014, 04.20:21 schrieb Lisandro Damián Nicanor
Pérez
Meyer:
Morning
For Ubuntu I can use the Firefox example. So can you explain why
is KF5
different than firefox?
Firefox (and Chromium too)
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 Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
For non-rolling distros, at some point you have to stop and release. A mix
of new features and bug fixes aren't going to be allowed in.
We (Kubuntu) have been delivering KDE SC point releases as post-release
updates to our users for
On Wednesday 30 April 2014 05:24:55 Scott Kitterman wrote:
Since we release on a different schedule, with monthly KF5 releases, we'd
all be interested in supporting different releases.
Which is already the case, I mentioned in another reply that Opensuse has had
releases with X.X.5 (so
On Wednesday 30 April 2014 11:35:54 Àlex Fiestas wrote:
On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
For non-rolling distros, at some point you have to stop and release. A mix
of new features and bug fixes aren't going to be allowed in.
We (Kubuntu) have been delivering KDE
based on 4.11.3,
4.11.4 and 4.11.5. At this moment we are even shipping the kde-workspace
releases as maintenance updates.
Yes, a distribution release cycle might not match with the KDE upstream
release cycle, but that NEVER put us in the position to ship an older
unsupported release
On Tuesday 29 April 2014 21:54:17 Scott Kitterman wrote:
On April 29, 2014 7:30:50 PM EDT, Albert Astals Cid aa...@kde.org wrote:
El Dimarts, 29 d'abril de 2014, a les 19:23:07, Scott Kitterman va
escriure:
On April 29, 2014 2:07:52 PM EDT, Albert Astals Cid aa...@kde.org
wrote:
El
On Wednesday 30 April 2014 12:15:34 Àlex Fiestas wrote:
Not really, the plan is the following:
Update frameworks all the times since it will make everybody life easier and
will improve quality (we strongly believe that, if not we wouldn't do it).
A non rolling-distro can do this without
Martin Gräßlin wrote:
Hello Martin,
Actually I think there is nothing wrong with having something like an
LTS release which is maintained by the distros. I recently read that
This is going to be difficult, to be honest. I can't speak for other distros
but in openSUSE *all* the KDE packaging
cycle might not match with the KDE upstream
release cycle, but that NEVER put us in the position to ship an older
unsupported release. For every distribution release the openSUSE KDE
Community team validates both release cycles and then we set a target
version for KDE. e.g. for the upcoming
On Wednesday 30 April 2014 12:20:51 Luca Beltrame wrote:
Martin Gräßlin wrote:
Hello Martin,
Actually I think there is nothing wrong with having something like an
LTS release which is maintained by the distros. I recently read that
This is going to be difficult, to be honest. I can't
On Wednesday 30 April 2014 12:33:06 Àlex Fiestas wrote:
We are all on the same situation and we have to make the best of it. We
believe that e can do best if we focus on master and make sure master rocks,
it has no regressions etc.
Obviously, if we are able to increase the quality of overall
, our last 4.8.X release was 4.8.5.
openSUSE 12.2 didn't came with maintenance updates, so the target was there to
get the latest possible KDE release in. Based on the timing that was 4.8.4.
But a lot changed since 12.2. Now we have a shorter release cycle for the
openSUSE releases and also we
4.8.4,
our last 4.8.X release was 4.8.5.
Yes, a distribution release cycle might not match with the KDE
upstream
release cycle, but that NEVER put us in the position to ship an older
unsupported release. For every distribution release the openSUSE KDE
Community team validates both release
On Wednesday, April 30, 2014 12:15:34 Àlex Fiestas wrote:
On Tuesday 29 April 2014 21:54:17 Scott Kitterman wrote:
On April 29, 2014 7:30:50 PM EDT, Albert Astals Cid aa...@kde.org wrote:
El Dimarts, 29 d'abril de 2014, a les 19:23:07, Scott Kitterman va
escriure:
On April 29, 2014
On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote:
On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
For non-rolling distros, at some point you have to stop and release. A mix
of new features and bug fixes aren't going to be allowed in.
We (Kubuntu) have been delivering KDE
On Wednesday 30 April 2014 08:24:43 Scott Kitterman wrote:
On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote:
On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
For non-rolling distros, at some point you have to stop and release. A
mix
of new features and bug fixes aren't
that Frameworks want to apply ?
And please remember: this is only about frameworks, not about the
applications or the workspace.
But the proposed release cycle for Frameworks could set an example for the
others. If this is the way frameworks will follow, what would stop the others
from doing
On Wednesday, April 30, 2014 14:39:31 Martin Gräßlin wrote:
On Wednesday 30 April 2014 08:24:43 Scott Kitterman wrote:
On Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote:
On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
For non-rolling distros, at some point you have to
: this is only about frameworks, not about the
applications or the workspace.
But the proposed release cycle for Frameworks could set an example for the
others. If this is the way frameworks will follow, what would stop the
others from doing exactly the same.
Nothing. In the same way nothing would
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.
signature.asc
Description: This is a digitally signed message part.
___
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)
Àlex Fiestas wrote:
On Wednesday 30 April 2014 12:20:51 Luca Beltrame wrote:
[snip]
As for Frameworks, we have ~20 maintainers for ~60 frameworks, and most of
them are not paid to work on it either.
We are all on the same situation and we have to make the best of it. We
believe that e can
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
On Wednesday 30 April 2014 11:00:39 Lisandro Damián Nicanor Pérez Meyer wrote:
This is a point in which I fully agree, and even if it doesn't solves any of
the things we are discussing it's good to acknowledge: we are very low on
man power, both upstream and most of us dowstreamers.
The amount
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
decided on the way that the Frameworks
release cycle will look like and given the responses you are not open to
anything else. So I guess we should just stop the discussion here and we will
see what is going to happen. At least we know where we all stand
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 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, 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 Wednesday, April 30, 2014 11:35:54 Àlex Fiestas wrote:
On Tuesday 29 April 2014 19:23:07 Scott Kitterman wrote:
For non-rolling distros, at some point you have to stop and release. A mix
of new features and bug fixes aren't going to be allowed in.
We (Kubuntu) have been delivering KDE
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
tarballs.
Are you sure that new frameworks releases won't have new library dependencies
not already present in that distribution's baseline?
I do think that any given framework will be that much more likely to integrate
well with the process of the new release cycle. And distributions should
ahoy, quick question that just when we discussed this in kubuntu:
On Sun, Apr 27, 2014 at 3:15 PM, David Faure fa...@kde.org wrote:
* Everything is developed in master, so each release will contain a few new
features and bugfixes;
Of course, going with this type of cycle comes with some
On Tue, Apr 29, 2014 at 2:33 PM, Harald Sitter apachelog...@ubuntu.comwrote:
ahoy, quick question that just when we discussed this in kubuntu:
On Sun, Apr 27, 2014 at 3:15 PM, David Faure fa...@kde.org wrote:
* Everything is developed in master, so each release will contain a few
new
Am Sonntag 27 April 2014, 15:15:32 schrieb David Faure:
We ended up settling on the one month cycle, no branch option because we
think it should address the constraints above. In a more detailed way here
is what we mean by one month cycle, no branch:
* Everything is developed in master, so
Hello,
On Tuesday 29 April 2014 14:33:12 Harald Sitter wrote:
On Sun, Apr 27, 2014 at 3:15 PM, David Faure fa...@kde.org wrote:
* Everything is developed in master, so each release will contain a few
new features and bugfixes;
Of course, going with this type of cycle comes with some
On Tue, Apr 29, 2014 at 3:09 PM, Kevin Ottens er...@kde.org wrote:
Hello,
On Tuesday 29 April 2014 14:33:12 Harald Sitter wrote:
On Sun, Apr 27, 2014 at 3:15 PM, David Faure fa...@kde.org wrote:
* Everything is developed in master, so each release will contain a few
new features and
On Tuesday 29 April 2014 15:18:55 Mark Gaiser wrote:
On Tue, Apr 29, 2014 at 3:09 PM, Kevin Ottens er...@kde.org wrote:
Hello,
On Tuesday 29 April 2014 14:33:12 Harald Sitter wrote:
On Sun, Apr 27, 2014 at 3:15 PM, David Faure fa...@kde.org wrote:
* Everything is developed in master,
1 - 100 of 142 matches
Mail list logo
