Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
Scott Kitterman wrote: > It is probably worth a discussion on packagers to share cross-distro ideas > about what kdelibs feature patches to ship with 4.8. Having some > commonality at least among the distros seemslike a good idea to me. Please move this to kde-packager. It's off topic for kde-core-devel, and kde-packager is where the distro people sit. Thanks in advance. Kevin Kofler
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
Kevin Kofler wrote: >Andrea Diamantini wrote: >> Ok, let's wait 18 months to see private browsing fixed. Going to >update >> bug reports... > >Try nagging distros to backport your (or your contributors') patches. >Unfortunately, it looks like trying to convince the kdelibs maintainers >at >KDE is a lost cause, as you can see from this and other threads. :-( >They >just don't care about their users anymore, instead focusing only on >some >ideal future. > >I talked to my fellow Fedora KDE packagers on IRC today and it looks >like >we'll be "backporting" (or rather, applying, since 4.x is what they got > >developed against) the kde#54300 patches. > >Of course, whenever you ask distros to backport features, it helps if >you >can already offer a patch(set) against 4.x (as is the case for the >kde#54300 >patches), since backporting from Frameworks is more work. (Whether the >patch >is against 4.8, 4.7 or even 4.6 usually won't matter, as long as it's >4.x.) It is probably worth a discussion on packagers to share cross-distro ideas about what kdelibs feature patches to ship with 4.8. Having some commonality at least among the distros seemslike a good idea to me. Scott K
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
Andrea Diamantini wrote: > Ok, let's wait 18 months to see private browsing fixed. Going to update > bug reports... Try nagging distros to backport your (or your contributors') patches. Unfortunately, it looks like trying to convince the kdelibs maintainers at KDE is a lost cause, as you can see from this and other threads. :-( They just don't care about their users anymore, instead focusing only on some ideal future. I talked to my fellow Fedora KDE packagers on IRC today and it looks like we'll be "backporting" (or rather, applying, since 4.x is what they got developed against) the kde#54300 patches. Of course, whenever you ask distros to backport features, it helps if you can already offer a patch(set) against 4.x (as is the case for the kde#54300 patches), since backporting from Frameworks is more work. (Whether the patch is against 4.8, 4.7 or even 4.6 usually won't matter, as long as it's 4.x.) Kevin Kofler
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Saturday 12 November 2011 12:26:11 Sebastian Kügler wrote: > On Wednesday, November 09, 2011 15:28:48 andrea diamantini wrote: > > I think that every app using cookies would like to have this patch > > merged > > ASAP, expecially browsers. This will help/fix/improve features like > > "private browsing" and so on. So please don't let us wait for the "big > > Universe reordering" to have it. :) > > To me, this is typically a "nice to have" feature. Sure, very cool stuff, > but does it warrant changing the plans we made this Summer to move to > Frameworks5 as fast as we can? > > I don't think it does, therefore, I'm against breaking the feature freeze > and have us rather concentrate on making the "Big Universe Reordering" > happen. (There are people waiting for that to happen, too, after all.) > > The mantra should be "If you want a new feature in kdelibs, help us making > the next feature release of it happen". Ok, let's wait 18 months to see private browsing fixed. Going to update bug reports... -- Andrea Diamantini, adjam GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 09, 2011 15:28:48 andrea diamantini wrote: > I think that every app using cookies would like to have this patch merged > ASAP, expecially browsers. This will help/fix/improve features like > "private browsing" and so on. So please don't let us wait for the "big > Universe reordering" to have it. :) To me, this is typically a "nice to have" feature. Sure, very cool stuff, but does it warrant changing the plans we made this Summer to move to Frameworks5 as fast as we can? I don't think it does, therefore, I'm against breaking the feature freeze and have us rather concentrate on making the "Big Universe Reordering" happen. (There are people waiting for that to happen, too, after all.) The mantra should be "If you want a new feature in kdelibs, help us making the next feature release of it happen". -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
Am Thu, 10 Nov 2011 16:54:33 +0100 schrieb andrea diamantini : > 2011/11/10 Aaron J. Seigo > > actually, Qt5 is irrelevant to most of the work that needs to be > > done in frameworks. we can, and are, working against Qt4 right now. > > most of the work > > is modularization and modernization (while preserving source > > compatibility) > Ok, stupid question then. Why aren't we releasing this as kdelibs 4.8? Stupidly assumed answer "ABI" Cheers, Thomas
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
2011/11/10 Aaron J. Seigo > On Wednesday, November 9, 2011 23:44:21 Andrea Diamantini wrote: > > 4.x is where I'm living/fighting/coding/writing now. > > for apps and workspaces, that is perfect. we don't want to disrupt app and > workspace development while we get kdelibs prepped for the next major > release. > > > I'm sorry to say, in my mind next version of kdelibs is 4.8. > > your mind is wrong. whatever the version number might end up saying > (probably > to keep packagers and users from confusion) it'll be the 4.7 code base with > continued bug fixes applied :) > > > And it will be based on the upcoming (not yet released) Qt 4.8. > > sure; but this is a non-relevant detail. > > > Thinking about "frameworks" without having yet a decent idea of what > will be > > Qt5 is impossible for me. > > actually, Qt5 is irrelevant to most of the work that needs to be done in > frameworks. we can, and are, working against Qt4 right now. most of the > work > is modularization and modernization (while preserving source compatibility) > Ok, stupid question then. Why aren't we releasing this as kdelibs 4.8? > > we are merging some things upstream into Qt5, and the things that are > merged > upstream are going into a small temporary library call libinqt (lib in qt > ;). > when Qt5 arrives, that library will go away and we will be able to move to > basing frameworks on Qt5. between now and then there is a lot of work on > the > modularization and modernization work. > > for instance, Sune's proposal to improve KNotification requires absolutely > nothing from Qt5. having that done before Qt5 arrives would actually be a > bonus as we wouldn't have to juggle too many different kinds of changes at > once. > > i do recognize that there is not enough documented plans and direction for > frameworks 5. there are a handful of wiki pages but they do not contain > enough > information; too much of that still resides in the heads of just a few > people. > > to help address that, i'm hosting an irc meeting in a couple weeks with > people > currently working on frameworks 5 with the aim of pulling together clearly > documented goals, tasks and milestones. the date has not been fixed yet, > once > it is i will announce it here as well so interested parties can join. > > i hope that with further documentation and clairty of goals that others > will > be able to see how they can get involved with frameworks and why now is a > good > time to do so. > > I hope that, too :) > -- > Aaron J. Seigo > humru othro a kohnu se > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 > > KDE core developer sponsored by Qt Development Frameworks >
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Thursday 10 November 2011 10:14:58 Aaron J. Seigo wrote:
> On Wednesday, November 9, 2011 23:44:21 Andrea Diamantini wrote:
> > And it will be based on the upcoming (not yet released) Qt 4.8.
>
> sure; but this is a non-relevant detail.
Indeed...
> > Thinking about "frameworks" without having yet a decent idea of what will
> > be Qt5 is impossible for me.
Qt5 is nearing feature freeze, and there is a pretty decent idea of what it
will be like. If I remember correctly, the release of 5.0 is currently planned
for Spring 2012, around April. That is not far in the future, and we're not
talking vaporware here.
Mostly, it's going to be source compatible (save some easily scriptable
changes like header/class renaming), the merging of QtMobility into Qt proper
(probably irrelevant for most of KDE), and modularization (again, irrelevant
from KDE's perspective when it comes to source compatibility and porting).
There's also the switch to QtQuick2, which also is irrelevant to most of KDE.
This is not going to be like the Qt3 -> Qt4 transition which required major
rewrites for consumers. In fact, those of us already working with Qt5 feel
right at home. At least for me it doesn't feel any different than developing
for Qt4.
> actually, Qt5 is irrelevant to most of the work that needs to be done in
> frameworks. we can, and are, working against Qt4 right now. most of the work
> is modularization and modernization (while preserving source compatibility)
>
> we are merging some things upstream into Qt5, and the things that are merged
> upstream are going into a small temporary library call libinqt (lib in qt
> ;). when Qt5 arrives, that library will go away and we will be able to move
> to basing frameworks on Qt5. between now and then there is a lot of work on
> the modularization and modernization work.
That is in fact the major part of the frameworks effort, as I understand it.
And it is important to identify, separate and port the things that should go
from kdelibs into Qt5 *now*, as things that require BIC or even source changes
need to be done before Qt's feature freeze, i.e. before 2012. If that deadline
is missed, there won't be another opportunity for the lifetime of Qt5. Thus,
the more people now helping with modularizing kdelibs and upstreaming whatever
makes sense to upstream, the better. At least from the perspective of someone
who would love to see useful KDE technologies as a part of the Qt framework,
to easily use it even on platforms that still don't support KDE deployment
easily :)
> for instance, Sune's proposal to improve KNotification requires absolutely
> nothing from Qt5. having that done before Qt5 arrives would actually be a
> bonus as we wouldn't have to juggle too many different kinds of changes at
> once.
And the actual porting to Qt5 won't require much effort or time then, I'd
expect. Maybe on the build system side, but certainly not on the code side.
Even less so for the things sitting on top of Frameworks.
BR,
~ Sput
--
Manuel "Sputnick" Nickschas ("Sput" on Freenode) | (o<
Member of the Quassel IRC Project - http://quassel-irc.org| //\
Come visit us in #quassel!| V_/_
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 9, 2011 23:44:21 Andrea Diamantini wrote: > 4.x is where I'm living/fighting/coding/writing now. for apps and workspaces, that is perfect. we don't want to disrupt app and workspace development while we get kdelibs prepped for the next major release. > I'm sorry to say, in my mind next version of kdelibs is 4.8. your mind is wrong. whatever the version number might end up saying (probably to keep packagers and users from confusion) it'll be the 4.7 code base with continued bug fixes applied :) > And it will be based on the upcoming (not yet released) Qt 4.8. sure; but this is a non-relevant detail. > Thinking about "frameworks" without having yet a decent idea of what will be > Qt5 is impossible for me. actually, Qt5 is irrelevant to most of the work that needs to be done in frameworks. we can, and are, working against Qt4 right now. most of the work is modularization and modernization (while preserving source compatibility) we are merging some things upstream into Qt5, and the things that are merged upstream are going into a small temporary library call libinqt (lib in qt ;). when Qt5 arrives, that library will go away and we will be able to move to basing frameworks on Qt5. between now and then there is a lot of work on the modularization and modernization work. for instance, Sune's proposal to improve KNotification requires absolutely nothing from Qt5. having that done before Qt5 arrives would actually be a bonus as we wouldn't have to juggle too many different kinds of changes at once. i do recognize that there is not enough documented plans and direction for frameworks 5. there are a handful of wiki pages but they do not contain enough information; too much of that still resides in the heads of just a few people. to help address that, i'm hosting an irc meeting in a couple weeks with people currently working on frameworks 5 with the aim of pulling together clearly documented goals, tasks and milestones. the date has not been fixed yet, once it is i will announce it here as well so interested parties can join. i hope that with further documentation and clairty of goals that others will be able to see how they can get involved with frameworks and why now is a good time to do so. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday 09 November 2011 16:45:55 Aaron J. Seigo wrote: > On Wednesday, November 9, 2011 15:28:48 andrea diamantini wrote: > > I think that every app using cookies would like to have this patch > > merged > > ASAP, expecially browsers. > > This will help/fix/improve features like "private browsing" and so on. > > So please don't let us wait for the "big Universe reordering" to have > > it. :) > help us make the "big universe reording" happen and everyone will get these > kinds of changes sooner. > > frameworks needs to happen. to happen, it needs people working on it. if we > continue to allow ourselves to work on 4.x instead well, the math is > simple. > the problem here is that people do not yet consider frameworks to be the > next version of kdelibs. it has not yet sunk in that, yes, indeed kdelibs > 4.x is done. bug fixes are welcome and encouraged, of course, and are > merged into frameworks. > > but we need to shift into a mindset where framework _is_ the next version of > kdelibs. not something for someone else to work on and give us in some far > distant undetermined future, but for us to work on so we can have it sooner > rather than later. 4.x is where I'm living/fighting/coding/writing now. I'm sorry to say, in my mind next version of kdelibs is 4.8. And it will be based on the upcoming (not yet released) Qt 4.8. Thinking about "frameworks" without having yet a decent idea of what will be Qt5 is impossible for me. But probably it's me, because I usually start coding after 10pm... -- Andrea Diamantini, adjam GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 9, 2011 17:53:58 Alexander Neundorf wrote: > But it will be not before Qt 5.0. the question is "how long after", and the best answer is "as little delay as possible". Qt 5.0 is scheduled for some time in 2012. > Personally, I don't have a problem if not too many people work on the personally, i do. there is lots of work to be done that doesn't require waiting on the build system changes. if we serialize on "build system" -> "modularize" -> "modernize where needed" we'll be lucky to have something out for 2014, forget 2012. to remind us of history: remember how some figured we might just skip doing a 3.4 release? then we recanted (and that time for good reasons, as Qt4 was a rocky path) and did a 3.4 .. and then 3.5 .. and then lots of 3.5.x releases with fewer good reasons to do so, slowing down development of the 4.x series. i know i sound like a broken record here: we should learn from the past rather than repeat it. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday 09 November 2011, Aaron J. Seigo wrote: > On Wednesday, November 9, 2011 15:28:48 andrea diamantini wrote: > > I think that every app using cookies would like to have this patch merged > > ASAP, expecially browsers. > > This will help/fix/improve features like "private browsing" and so on. > > So please don't let us wait for the "big Universe reordering" to have it. > > :) > > help us make the "big universe reording" happen and everyone will get these > kinds of changes sooner. > > frameworks needs to happen. to happen, it needs people working on it. if we > continue to allow ourselves to work on 4.x instead well, the math is > simple. > > the problem here is that people do not yet consider frameworks to be the > next version of kdelibs. it has not yet sunk in that, yes, indeed kdelibs > 4.x is done. bug fixes are welcome and encouraged, of course, and are > merged into frameworks. > > but we need to shift into a mindset where framework _is_ the next version > of kdelibs. not something for someone else to work on and give us in some > far distant undetermined future, but for us to work on so we can have it > sooner rather than later. But it will be not before Qt 5.0. Personally, I don't have a problem if not too many people work on the frameworks yet, since the cmake stuff for frameworks is not yet done by far. And things will still change there. This is easier if there are not that many people there yet. Alex
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 9, 2011 15:28:48 andrea diamantini wrote: > I think that every app using cookies would like to have this patch merged > ASAP, expecially browsers. > This will help/fix/improve features like "private browsing" and so on. > So please don't let us wait for the "big Universe reordering" to have it. :) help us make the "big universe reording" happen and everyone will get these kinds of changes sooner. frameworks needs to happen. to happen, it needs people working on it. if we continue to allow ourselves to work on 4.x instead well, the math is simple. the problem here is that people do not yet consider frameworks to be the next version of kdelibs. it has not yet sunk in that, yes, indeed kdelibs 4.x is done. bug fixes are welcome and encouraged, of course, and are merged into frameworks. but we need to shift into a mindset where framework _is_ the next version of kdelibs. not something for someone else to work on and give us in some far distant undetermined future, but for us to work on so we can have it sooner rather than later. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
I think that every app using cookies would like to have this patch merged ASAP, expecially browsers. This will help/fix/improve features like "private browsing" and so on. So please don't let us wait for the "big Universe reordering" to have it. :) 2011/11/8 Aaron J. Seigo > On Monday, November 7, 2011 19:32:15 Dawit A wrote: > > >> Well this is over a month too late, but I have a enhancement change > > >> for kcookiejar that needs to go into kdelibs/kioslave for KDE 4.8. The > > >> patch has actually been pending for a merge since KDE 4.6. See > > >> https://bugs.kde.org/show_bug.cgi?id=54300. > ... > > Right. The patch simply moves the idea of session cookies from being a > > global configuration option to a site specific option. That is it gets > > rid of the all or nothing approach currently employed. That gives the > > user a lot more control of how they deal with cookies. > > can you explain why it must go into 4.8? it's been waiting since 4.6, and i > didn't find a description of what requires it in 4.8 ... > > as far as i can see, it's a feature enhancement that isn't strictly > required > by anything (though it is very nice to have indeed), so it should go into > the > frameworks branch. > > -- > Aaron J. Seigo > humru othro a kohnu se > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 > > KDE core developer sponsored by Qt Development Frameworks >
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Wednesday, November 9, 2011 01:22:54 Dawit A wrote: > That is fine for the kdelibs portion, but what do you suggest be done > with the kde-baseapps portion of the patch ? Wait until 4.8 gets > branched ? creating a frameworks branch in kde-baseapps may be a solution; we'll likely want to branch during porting, and if we don't (for whatever reason) then we can easily merge such a branch into master at that point. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Tue, Nov 8, 2011 at 11:18 AM, Aaron J. Seigo wrote: > On Monday, November 7, 2011 19:32:15 Dawit A wrote: >> >> Well this is over a month too late, but I have a enhancement change >> >> for kcookiejar that needs to go into kdelibs/kioslave for KDE 4.8. The >> >> patch has actually been pending for a merge since KDE 4.6. See >> >> https://bugs.kde.org/show_bug.cgi?id=54300. > ... >> Right. The patch simply moves the idea of session cookies from being a >> global configuration option to a site specific option. That is it gets >> rid of the all or nothing approach currently employed. That gives the >> user a lot more control of how they deal with cookies. > > can you explain why it must go into 4.8? it's been waiting since 4.6, and i > didn't find a description of what requires it in 4.8 ... > > as far as i can see, it's a feature enhancement that isn't strictly required > by anything (though it is very nice to have indeed), so it should go into the > frameworks branch. That is fine for the kdelibs portion, but what do you suggest be done with the kde-baseapps portion of the patch ? Wait until 4.8 gets branched ? With all the pending framework changes coming, I would be surprised if the patch would not end up falling through the cracks. I hate to see some one's good work, which I am is useful to many users, go to waste like that. Anyways, I personally do not have any specific reason for this patch going into the 4.8 release except to state that I won't have the time to see it merged past that release point. Someone else would have to pick it up and do it, which I very much doubt will happen. There are very few developers that are interested in working on the low level stuff in KDE.
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Monday, November 7, 2011 19:32:15 Dawit A wrote: > >> Well this is over a month too late, but I have a enhancement change > >> for kcookiejar that needs to go into kdelibs/kioslave for KDE 4.8. The > >> patch has actually been pending for a merge since KDE 4.6. See > >> https://bugs.kde.org/show_bug.cgi?id=54300. ... > Right. The patch simply moves the idea of session cookies from being a > global configuration option to a site specific option. That is it gets > rid of the all or nothing approach currently employed. That gives the > user a lot more control of how they deal with cookies. can you explain why it must go into 4.8? it's been waiting since 4.6, and i didn't find a description of what requires it in 4.8 ... as far as i can see, it's a feature enhancement that isn't strictly required by anything (though it is very nice to have indeed), so it should go into the frameworks branch. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: New Feature for kdelibs (Was: The case for a kdelibs 4.8)
On Mon, Nov 7, 2011 at 5:09 PM, Allen Winter wrote: > On Monday 07 November 2011 10:18:15 AM Dawit A wrote: >> On Fri, Sep 30, 2011 at 9:54 AM, David Faure wrote: >> > On Thursday 29 September 2011 20:01:00 Kevin Kofler wrote: >> >> But one of my points is that we need features too, not just bugfixes. >> >> Continuing 4.7.x releases solves the problem of bugfixes just fine, but >> >> entirely fails to address the issue of features. >> > >> > But who is (or would be) working on features in kdecore | kdeui | kio | >> > kfile? >> >> Well this is over a month too late, but I have a enhancement change >> for kcookiejar that needs to go into kdelibs/kioslave for KDE 4.8. The >> patch has actually been pending for a merge since KDE 4.6. See >> https://bugs.kde.org/show_bug.cgi?id=54300. >> >> Unfortunately, I do not know how to proceed with committing the >> kdelibs portion of the patch without actually polluting the kdelibs >> 4.7.4 version. Waiting for the final December release of the final KDE >> 4.7.4 is one approach, but then the commit would be too late for the >> feature freeze. We either need to exempt kdelibs from the upcoming >> feature freeze or I need an exemption to commit these changes past the >> freeze times currently established for KDE 4.8 >> > Right. > I do think we are open to feature changes in kdelibs for the upcoming 4.8 > release. > > But those need to be handled on a case-by-case basis and investigated and > discussed. > We (the Release Team) need to know about such features very soon as freezes > are coming. > > I'm CC'ing the release-team on this. > > In this particular case, I looked at the patches involved and think we > should allow them > into kdelibs-KDE/4.7 branch... Mainly it looks like this patch adds the > ability to make > site cookies act like session cookies. Right. The patch simply moves the idea of session cookies from being a global configuration option to a site specific option. That is it gets rid of the all or nothing approach currently employed. That gives the user a lot more control of how they deal with cookies.
