Hello,
On Tuesday 12 May 2015 09:22:12 David Faure wrote:
> On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote:
> > I think there are two possibilities:
> > * "master" is the development branch and we have a separate "release"
> > branch
> > => contributors have it easier because that is per
On Tue, May 12, 2015, at 09:22 AM, David Faure wrote:
> On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote:
> > I think there are two possibilities:
> > * "master" is the development branch and we have a separate "release"
> > branch
> > => contributors have it easier because that is perhap
On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote:
> I think there are two possibilities:
> * "master" is the development branch and we have a separate "release"
> branch
> => contributors have it easier because that is perhaps more common,
> and the people releasing need to know that they s
On Mon, May 11, 2015, at 02:42 PM, David Faure wrote:
> On Monday 11 May 2015 11:57:02 Christian Mollekopf wrote:
> > But that doesn't necessarily mean they can't be part of the same
> > distribution mechanism.
> > If you simply take a snapshot of all frameworks every month, then it
> > shouldn'
On Monday 11 May 2015 11:57:02 Christian Mollekopf wrote:
> But that doesn't necessarily mean they can't be part of the same
> distribution mechanism.
> If you simply take a snapshot of all frameworks every month, then it
> shouldn't matter if
> they changed or not. If no change has been made, th
On Mon, May 11, 2015, at 12:31 AM, David Faure wrote:
> On Monday 11 May 2015 00:13:27 Christian Mollekopf wrote:
> > > Are you volunteering, or just making demands for others to do work for
> > > you?
> >
> > I'm volunteering to do the maintenance and release engineering for the
> > libraries
On Monday 11 May 2015 00:13:27 Christian Mollekopf wrote:
> > Are you volunteering, or just making demands for others to do work for
> > you?
>
> I'm volunteering to do the maintenance and release engineering for the
> libraries that matter to me,
> and I'm also prepared to work out a proposal on
On Sun, May 10, 2015, at 11:13 PM, David Faure wrote:
> On Sunday 10 May 2015 22:31:10 Alexander Neundorf wrote:
> > There I have Qt available, as Christian says, it feels like a system
> > library, our application is built on it.
>
> Well, I wish you would see KF5 as a natural extension of Qt,
On Mon, May 11, 2015, at 12:05 AM, Albert Astals Cid wrote:
> El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va
> escriure:
> > On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote:
> > > El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va
> > >
>
El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va
escriure:
> On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote:
> > El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va
> >
> > escriure:
> > > On Sunday, May 10, 2015 15:39:02 David Faure wrote:
>
On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote:
> El Diumenge, 10 de maig de 2015, a les 22:33:30, Christian Mollekopf va
> escriure:
> > On Sun, May 10, 2015, at 03:39 PM, David Faure wrote:
> > > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> > > > * I'd consider Qt to
On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote:
> El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va
> escriure:
> > On Sunday, May 10, 2015 15:39:02 David Faure wrote:
> > > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> > > > * I'd consider Qt to be
El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va
escriure:
> On Sunday, May 10, 2015 15:39:02 David Faure wrote:
> > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> > > * I'd consider Qt to be a lower level library. Qt mostly provides
> > > fundamentals just like
El Diumenge, 10 de maig de 2015, a les 22:33:30, Christian Mollekopf va
escriure:
> On Sun, May 10, 2015, at 03:39 PM, David Faure wrote:
> > On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> > > * I'd consider Qt to be a lower level library. Qt mostly provides
> > > fundamentals just li
On Sunday 10 May 2015 22:31:10 Alexander Neundorf wrote:
> There I have Qt available, as Christian says, it feels like a system
> library, our application is built on it.
Well, I wish you would see KF5 as a natural extension of Qt, therefore "a
system library" too, if you want to call it that.
>
On Sun, May 10, 2015, at 03:39 PM, David Faure wrote:
> On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> > * I'd consider Qt to be a lower level library. Qt mostly provides
> > fundamentals just like libc or the STL,
> > and it's therefore okay for me to just work with what I have availa
On Sunday, May 10, 2015 15:39:02 David Faure wrote:
> On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> > * I'd consider Qt to be a lower level library. Qt mostly provides
> > fundamentals just like libc or the STL,
> > and it's therefore okay for me to just work with what I have availabl
On Sunday, 10 May 2015 15:39:02 CEST, David Faure wrote:
Qt *is* splitted. It's just that the splitted libs are released together.
The splitting of Qt is not "full and complete", however. Modules tend to
use each other's internal APIs, and that's the biggest reason for not
supporting random m
On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote:
> * I'd consider Qt to be a lower level library. Qt mostly provides
> fundamentals just like libc or the STL,
> and it's therefore okay for me to just work with what I have available.
I hope you can understand that the decision on how Qt (o
On Sat, May 9, 2015, at 01:27 PM, David Faure wrote:
> On Saturday 09 May 2015 13:08:35 Alexander Neundorf wrote:
> > we pretend it's all independent libraries but still they all depend on the
> > latest version of all other libs.
>
> It's a question of the definition of "independent".
>
> E.g.
On Saturday 09 May 2015 13:08:35 Alexander Neundorf wrote:
> we pretend it's all independent libraries but still they all depend on the
> latest version of all other libs.
It's a question of the definition of "independent".
E.g. KCoreAddons and Solid are independent because you can use either one
On Friday, May 08, 2015 10:32:22 Christian Mollekopf wrote:
> On Tue, May 5, 2015, at 05:38 PM, Martin Gräßlin wrote:
...
> > The versioning would be a complete mess: each framework having
> > a
> > different version number, some doing bug fix releases, some don't.
>
> ...that "complete mess" is j
On Tuesday, May 05, 2015 11:33:03 Christian Mollekopf wrote:
> Hey David,
>
> Sorry for the late response.
>
> On Wed, Apr 29, 2015, at 08:34 PM, David Faure wrote:
> > On Tuesday 28 April 2015 12:17:00 Christian Mollekopf wrote:
> > > Our dependency tree is now indeed reduced, but if we want to
On Wed, May 6, 2015, at 01:42 PM, Jan Kundrát wrote:
> Hi Christian,
Hi Jan,
> I think that the stuff you're looking for (reducing version churn) can
> also
> be provided by having stable branches for selected parts of KF5.
>
> IMHO this can be quite an elegant solution given the usual cat-he
On Tue, May 5, 2015, at 05:38 PM, Martin Gräßlin wrote:
> On Tuesday 05 May 2015 17:30:05 Mario Fux wrote:
> > Am Dienstag, 05. Mai 2015, 13.46:16 schrieb Martin Gräßlin:
> > > > If master is always releasable, you should indeed only merge into master
> > > > with a change of a version number.
> >
Hi Christian,
I think that the stuff you're looking for (reducing version churn) can also
be provided by having stable branches for selected parts of KF5.
IMHO this can be quite an elegant solution given the usual cat-herding
problem of FLOSS where people just do what they want to do. Those wh
> > Ok, they are not that obvious too me. Wouldn't it be possible to add
> > something like maintainerManagesVersionOnItsOn=false to a file in all the
> > frameworks (isn't there already a file in each frameworks for stuff like
> > platforms, etc.?) and modify the release-scripts (David or anybody
On Tuesday 05 May 2015 17:30:05 Mario Fux wrote:
> Am Dienstag, 05. Mai 2015, 13.46:16 schrieb Martin Gräßlin:
>
> Morning
>
> [snip]
>
> > > If master is always releasable, you should indeed only merge into master
> > > with a change of a version number.
> > > If you don't want to maintain diff
Am Dienstag, 05. Mai 2015, 13.46:16 schrieb Martin Gräßlin:
Morning
[snip]
> > If master is always releasable, you should indeed only merge into master
> > with a change of a version number.
> > If you don't want to maintain different versions for whatever reason
> > (and I think that's an entir
On Tuesday 05 May 2015 13:40:24 Christian Mollekopf wrote:
> On Tue, May 5, 2015, at 01:31 PM, Martin Gräßlin wrote:
> > On Tuesday 05 May 2015 13:20:25 Christian Mollekopf wrote:
> > > On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote:
> > > > On Tuesday 05 May 2015 11:33:03 Christian Molleko
On Tue, May 5, 2015, at 01:31 PM, Martin Gräßlin wrote:
> On Tuesday 05 May 2015 13:20:25 Christian Mollekopf wrote:
> > On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote:
> > > On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote:
> > > > What the regular releases IMO should be doing,
On Tuesday 05 May 2015 13:20:25 Christian Mollekopf wrote:
> On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote:
> > On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote:
> > > What the regular releases IMO should be doing, is to take the latest
> > > version from the "always releasable" m
On Tuesday 05 May 2015 13:14:08 Christian Mollekopf wrote:
> On Tue, May 5, 2015, at 12:11 PM, Martin Gräßlin wrote:
> > On Tuesday 05 May 2015 11:45:19 Christian Mollekopf wrote:
> > > On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote:
> > > > On Wednesday 29 April 2015 15:00:32 Christian Molle
On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote:
> On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote:
> > What the regular releases IMO should be doing, is to take the latest
> > version from the "always releasable" master branch,
> > and be done with it (and that means not touchin
On Tue, May 5, 2015, at 12:11 PM, Martin Gräßlin wrote:
> On Tuesday 05 May 2015 11:45:19 Christian Mollekopf wrote:
> > On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote:
> > > On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote:
> > > > You don't have to maintain any other combinat
On Tuesday 05 May 2015 11:45:19 Christian Mollekopf wrote:
> On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote:
> > On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote:
> > > You don't have to maintain any other combinations that what you already
> > > do.
> > > Just because the cmake
On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote:
> What the regular releases IMO should be doing, is to take the latest
> version from the "always releasable" master branch,
> and be done with it (and that means not touching the library version,
> because that's not the responsibility of
On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote:
> On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote:
> > You don't have to maintain any other combinations that what you already
> > do.
> > Just because the cmake versions aren't automatically bumped doesn't mean
> > you suddenly
Hey David,
Sorry for the late response.
On Wed, Apr 29, 2015, at 08:34 PM, David Faure wrote:
> On Tuesday 28 April 2015 12:17:00 Christian Mollekopf wrote:
> > Our dependency tree is now indeed reduced, but if we want to update a
> > single library, we are forced to update all libraries, due to
Hey,
> Or the other way around -- if it is at one point indeed working with these
> versions, what will happen is that someone will use a new feature from an
> underlying framework at some point, and forget to upgrade the required
> version. This will happen many times per month, not just once a y
El Dijous, 30 d'abril de 2015, a les 10:35:59, Kevin Funk va escriure:
> On Wednesday, April 29, 2015 21:43:20 David Faure wrote:
> > On Wednesday 29 April 2015 11:24:48 Kevin Funk wrote:
> > > Use-case: Potential contributor working on KDevelop:
> > > - Has KF5 installed from distro packages
> > >
Hi,
I would like to add that there are other much bigger frameworks which have a
lot more
resources at hand and also have one single version under which all of the many
submodules
are released:
Java (Java 6, Java 7, Java 8, ...)
https://en.wikipedia.org/wiki/Java_version_history
.NET (3.0, 3.
On Thursday 30 April 2015 10:35:59 Kevin Funk wrote:
> > QtAnything 5.5 cannot be compiled with QtBase 5.2.
>
> I'm fairly sure you can; let's say build QtWebChannel 5.6 (dev) against
> QtBase 5.4.1. In fact, I just tried again and it worked just fine. QMake
> did not complain.
I would say Qt do
On Thursday 30 April 2015 10:35:59 Kevin Funk wrote:
> However, I think it could be helpful to be able to build master branch of
> $MODULE against a stable version of its dependencies for *development
> purposes*, which currently isn't possible.
OK, that is easily fixable. I can raise the versio
On Wednesday, April 29, 2015 21:45:14 David Faure wrote:
> but they don't
> realize when writing QSignalSpy(obj, &Class::member) that this syntax
> wasn't available in Qt 5.2.
I wasn't aware that this has been added, very useful. Thanks! :-)
--
sebas
http://www.kde.org | http://vizZzion.org |
On Wednesday, April 29, 2015 21:43:20 David Faure wrote:
> On Wednesday 29 April 2015 11:24:48 Kevin Funk wrote:
> > Use-case: Potential contributor working on KDevelop:
> > - Has KF5 installed from distro packages
> > - KDevelop/KDevPlatform compiled from Git
> > - There's a bug in ktexteditor (ti
On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote:
> You don't have to maintain any other combinations that what you already
> do.
> Just because the cmake versions aren't automatically bumped doesn't mean
> you suddenly have to test every conceivable combination of versions.
How can t
On Wednesday 29 April 2015 11:24:48 Kevin Funk wrote:
> Use-case: Potential contributor working on KDevelop:
> - Has KF5 installed from distro packages
> - KDevelop/KDevPlatform compiled from Git
> - There's a bug in ktexteditor (tier 3)
> - Likes to checkout just ktexteditor, fix the issue, compil
Christian,
David isn't the only one with these thoughts. I agree with everything
he said, and was thinking about the dependency zoo also, but couldn't
form the words until I read what he wrote. That's exactly what I was
thinking. It would be like the old rpm dependency hell from early
linux days a
On Tuesday 28 April 2015 12:17:00 Christian Mollekopf wrote:
> Our dependency tree is now indeed reduced, but if we want to update a
> single library, we are forced to update all libraries, due to the
> version-lock caused by periodic bumping of dependencies.
You say at the end of the mail that y
On Wed, Apr 29, 2015, at 01:29 PM, Martin Gräßlin wrote:
> On Wednesday 29 April 2015 12:19:18 Christian Mollekopf wrote:
> > On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote:
> > > On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote:
> > > > On Wed, Apr 29, 2015, at 12:11 AM, Al
On Wednesday 29 April 2015 12:19:18 Christian Mollekopf wrote:
> On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote:
> > On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote:
> > > On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
> > > > On Tue, Apr 28, 2015 at 12:17 PM, Christian
On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote:
> On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote:
> > On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
> > > On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
> > > wrote:
> > >
> > >
> > > Hi Christian,
> > > I und
On Tuesday, April 28, 2015 12:17:00 Christian Mollekopf wrote:
> Hey,
>
> For the Kolab Groupware Server we use some KDE libraries on the server.
> Servers being what they are, the libraries we require are often not
> available by default because the systems are too old, and we end-up
> backportin
On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote:
> On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
> > On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
> > wrote:
> >
> >
> > Hi Christian,
> > I understand your needs, I've seen similar complaints before.
> >
> > Letting f
On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote:
> On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
> wrote:
>
> Hi Christian,
> I understand your needs, I've seen similar complaints before.
>
> Letting frameworks depend on different versions could make sense, but
> I also fear it mig
On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf
wrote:
> Hey,
>
> For the Kolab Groupware Server we use some KDE libraries on the server.
> Servers being what they are, the libraries we require are often not
> available by default because the systems are too old, and we end-up
> backporting
Hey,
For the Kolab Groupware Server we use some KDE libraries on the server.
Servers being what they are, the libraries we require are often not
available by default because the systems are too old, and we end-up
backporting what we need. To make this feasible in pre-framework times I
had to creat
58 matches
Mail list logo
