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
On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote:
On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens er...@kde.org wrote:
snip
Now, I think we'll have to agree to disagree on something. You believe
there's some rule written in stone somewhere which will make the
everyone will pile up backports
On May 20, 2014 4:19:26 AM EDT, Jos Poortvliet jospoortvl...@gmail.com wrote:
On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote:
On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens er...@kde.org wrote:
snip
Now, I think we'll have to agree to disagree on something. You
believe
there's some rule
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
wrote:
On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote:
On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens er...@kde.org wrote:
snip
Now, I think we'll have to
On Tuesday, May 20, 2014 13:28:29 Martin Gräßlin wrote:
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
wrote:
On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote:
On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens
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
Hi,
2014-05-20 13:19 GMT+02:00 Scott Kitterman:
We've pushed nearly every point release to end users throughout the KDE4
cycle. I use them myself. Your characterization of the KDE4 point releases
doesn't match my experience.
here is just one recent example, where someone pushed a commit to
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
On May 20, 2014 10:41:04 AM EDT, Frank Reininghaus frank7...@googlemail.com
wrote:
Hi,
2014-05-20 13:19 GMT+02:00 Scott Kitterman:
We've pushed nearly every point release to end users throughout the
KDE4 cycle. I use them myself. Your characterization of the KDE4 point
releases doesn't match my
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 the
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
be
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 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
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
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
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 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
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: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
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, 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
On Wednesday 30 April 2014 14:39:31 Martin Gräßlin wrote:
I know that this is a change from how it is right now: but wouldn't it be
better if those who are interested do these branches? Let's face it whatever
we do upstream cannot suite all of our downstreams at the same time.
If I take your
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
On Wednesday 30 April 2014 15:08:55 Raymond Wooninck wrote:
On Wednesday 30 April 2014 14:39:31 Martin Gräßlin wrote:
I know that this is a change from how it is right now: but wouldn't it be
better if those who are interested do these branches? Let's face it
whatever we do upstream cannot
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
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 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
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
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
El Dimarts, 29 d'abril de 2014, a les 15:04:59, Andreas K. Huettel va
escriure:
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
El Dimarts, 29 d'abril de 2014, a les 15:04:59, Andreas K. Huettel va
escriure:
Practically this just means that what used to be the stable branch now
becomes the distribution patch collection.
No, it means that you use the next release as you would do now since it will
have the bug you
El Dimarts, 29 d'abril de 2014, a les 19:55:42, Andreas K. Huettel va
escriure:
El Dimarts, 29 d'abril de 2014, a les 15:04:59, Andreas K. Huettel va
escriure:
Practically this just means that what used to be the stable branch now
becomes the distribution patch collection.
No,
On April 29, 2014 2:07:52 PM EDT, Albert Astals Cid aa...@kde.org wrote:
El Dimarts, 29 d'abril de 2014, a les 19:55:42, Andreas K. Huettel va
escriure:
El Dimarts, 29 d'abril de 2014, a les 15:04:59, Andreas K. Huettel
va
escriure:
Practically this just means that what used to be the
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 Dimarts, 29 d'abril de 2014, a les 19:55:42, Andreas K. Huettel va
escriure:
El Dimarts, 29 d'abril de 2014, a les 15:04:59, Andreas K.
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 Dimarts, 29 d'abril de 2014, a les 19:55:42, Andreas K. Huettel
va
On Tuesday 29 April 2014 21:54:17 Scott Kitterman wrote:
[snip]
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 known (to average computer users) FOSS
On Sunday, April 27, 2014 15:55:07 Albert Astals Cid wrote:
El Diumenge, 27 d'abril de 2014, a les 15:15:32, David Faure va escriure:
FYI.
Interesting fact here that original the mail was just sent to k-f-d and
k-c-d.
I am seeing similar patterns in the plasma land, where they went their
FYI.
-- Forwarded Message --
Subject: KDE Frameworks Release Cycle
Date: Sunday 27 April 2014, 11:51:01
From: Kevin Ottens er...@kde.org
To: kde-frameworks-de...@kde.org
CC: kde-core-de...@kde.org
Hello people,
As you may have noticed, we're covering quite a few tasks here
El Diumenge, 27 d'abril de 2014, a les 15:15:32, David Faure va escriure:
FYI.
Interesting fact here that original the mail was just sent to k-f-d and k-c-d.
I am seeing similar patterns in the plasma land, where they went their own way
with the releasing discussion and only sent to this list
On Sunday 27 April 2014 15:55:07 Albert Astals Cid wrote:
Interesting fact here that original the mail was just sent to k-f-d and
k-c-d.
That was my suggestion, to avoid cross-posting to 4 lists everytime someone
answers, which always creates issues because kde-packager@ is moderated.
I am
Longer answer now that i'm no longer on the move :)
El Diumenge, 27 d'abril de 2014, a les 16:09:27, David Faure va escriure:
On Sunday 27 April 2014 15:55:07 Albert Astals Cid wrote:
Interesting fact here that original the mail was just sent to k-f-d and
k-c-d.
That was my suggestion, to
On Sunday 27 April 2014 17:14:43 Albert Astals Cid wrote:
i'm just stating that both schedules
were discussed outside this list
Ah, sorry, now I understand better the purpose of your email.
Well, it is often the case that discussions that normally happen on mailing-
lists, happen differently
1 - 100 of 101 matches
Mail list logo
