Re: Please avoid noisy merge commits in frameworks
On 19 February 2012 13:36, Stephen Kelly wrote: > > Hi there, > > I was reviewing the changes in the frameworks branch from yesterday. > Something I noticed was that there are a lot of merge commits that don't > need to exist. > > Please use `gitk` to see them. > > The unneeded merge commits actually make it harder to follow frameworks for > me. It breaks things like using `gitk --first-parent` which should show only > the commits in frameworks. If you now try that out, you will see that the > people who made the unneeded merges actually hide commits from the people > that didn't. See for example that if you run `gitk --first-parent` commit > 011b6115d2dd91e9104095f3a5065e80009ea1a7 from David is not shown. > > This is also the reason you should not cherry-pick from 4.8 into frameworks > by the way. If you cherry-pick, then 4.8 commits show up in `gitk --first- > parent` when trying to look at only the frameworks branch. That means they > are just noise, so please keep that in mind too. > > To help out: > > * Do not use git pull when working on frameworks. Use git pull --rebase > instead. > > * Alternatively (preffered) configure git to always add an implicit --rebase > to the pull command: > http://d.strelau.net/post/47338904/git-pull-rebase-by-default > > * Use gitk --all to see what would happen if you push. You should never have > to create merge commits. If you do, then please clean it up before pushing. Yes, I realised after the fact that I had created one of these so sorry about that. I've already now switched to using --rebase. If one does accidentally create one of these merge commits, how can they fix it before they push? -- Matt Williams http://milliams.com
Re: Review Request: Workaround for the hang (freeze) when opening VLC's file dialog under KDE...
On 4 February 2011 17:05, Tom Albers wrote: > - Original Message - >> It >> is when I have to unnecessarily type more than I have to. Seriously >> this is getting to be annoying and I do not mean you personally. These >> rigid and brittle coding styles. One project says no braces for single >> line statements and another says the complete opposite. I have no >> problem with some common sense coding style rules, but please spare me >> from such nonsense micro management of each and every line of code, >> specially since the people working on kdelibs should in the least be >> well versed about the pitfalls of using or not using braces, even for >> single line statements. > > For new code, we very much like to follow: > http://techbase.kde.org/Policies/Kdelibs_Coding_Style > > Which can be different in other area's within KDE, which I hope one day will > not be the case. > > And before you ask, yes, I very much would like a 'astyle' run on all the > code in kdelibs to settle this once and for all. And then how about a .kateconfig file (http://kate-editor.org/2006/02/09/kateconfig-files/) to help 'enforce' this? -- Matt Williams http://milliams.com
Re: "Cornelius's grand plan" - Merging KDElibs into Qt
2010/10/31 Alexander Neundorf : > On Sunday 31 October 2010, todd rme wrote: >> On Sun, Oct 31, 2010 at 9:26 AM, Michael Jansen > wrote: > ... >> > 1. Small improvements to the Qt Libraries >> > >> > Those are the so called convenient classes. Classes the have been added >> > to the >> > KDE Libs because of some shortcomings of the Qt Classes or to add some >> > convenience methods. I guess classes like KUrl and KIcon (at least parts) >> > fall >> > into that category. >> > >> > The classes in this category do not add additional functionality, >> > requirements >> > or anything else to the Qt Classes. >> >> I think this sounds like the place to start, for several reasons: > > I don't think the place to start is merging something into Qt. > _We_ can't merge something ourselves, it must be accepted. So we would be > stuck at the first step. > > IMO the place to start must be to reorganize our libraries so that we can > clearly separate these different types, i.e. "enhancements which should be in > Qt", "addons", "platform". > Once we have this (I would estimate something like a year of work), we may > start to try to get some of the enhancements into Qt. > And if it doesn't get accepted then, still no problem, since by then it will > have the form of a smallish library with very few or no dependencies beside > the Qt libs. Absolutely. I think that this is the most sensible and practical approach to take. -- Matt Williams http://milliams.com
Re: "Cornelius's grand plan" - Merging KDElibs into Qt
On 31 October 2010 12:37, Modestas Vainius wrote:
> Hello,
>
> On sekmadienis 31 Spalis 2010 14:04:28 Matt Williams wrote:
>> On 31 October 2010 11:53, John Tapsell wrote:
>> > On 31 October 2010 11:33, Mark Kretschmann wrote:
>> >> Hey all,
>> >>
>> >> after reading the whole thread that started with Chani's mail ("why
>> >> kdelibs?"), I think the noise level has become a bit too much there.
>> >> Cornelius had proposed this rather daring idea:
>> >>
>> >> http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2
>> >
>> > Sounds great. This should probably be done by picking a specific
>> > technology in KDE, and adapting it and merging it to work in Qt.
>> >
>> > A wonderful place to start would be kioslaves imho. This is something
>> > which has a real advantage, is relatively self-contained, and would
>> > provide a big advantage. Possibly it needs to be merged more with the
>> > Qt API though.
>>
>> So, if we decided that we wanted to merge KIO slaves into Qt, what
>> would the steps we go through be? If we're going to be doing this with
>> a number of classes we need to have a process which ensures that the
>> code is Qute enough, KDE still compiles against it (with minimal/no
>> code changes) etc.
>
> With my packager hat on:
>
> But what happens when you (KDE) decide that you really need a new feature of
> kioslaves for the next release. But the next Qt release is not due in 7 months
> or you (again) have trouble merging changes back to Qt with patience running
> out? Sure, developers compiling from source can patch Qt, install differently
> configured builds to different prefixes with/without specific features etc.
> But what are poor packagers supposed to do? Phonon situation all over again?
> It was *really* bad and my mind is still recovering from that experience. I
> really doubt I'm ever going to trust such merges to Qt again.
>
> In my opinion, KDE should keep libraries small, *modular* and develop them in-
> house. Try not to attach binaries and esp. daemons to the libraries. Maybe
> strip KDE branding from library names to gain wider acceptance. Only this way
> you as a project will be in control of release schedules and feature sets.
Basically, what you're suggesting is to move as much (well, within
reason of course) of kdelibs 'upstream' into kdesupport. I think I
agree that this could be the way to go (at least for the short/medium
term).
It doesn't solve our BIC/SIC problem (unless as I asked before: does
moving the real code out into kdesupport and keeping wrapper classes
in kdelibs solve either of those?) so we'd still need to make this a
KDE5 thing. Or would we just have to make it libkdecore.so.6 bump
while keeping KDE Platform/SC at version 4? It would be breaking our
BC promise but maybe we could get away with it? :)
--
Matt Williams
http://milliams.com
Re: [Kde-games-devel] Re: klickety moved to kdereview
2010/10/31 nihui : > hi, Henrique Pinto > klickety now has the ksame mode in its codebase. The purpose is to replace > ksame with klickety in kdegames module. It seems that there were no changes > in ksame for a long time. Since you are the maintainer of ksame, I need your > comments on this move. It would be nice that you could also work on the > klickety-ksame mode. > > I found that Matt Williams is the current module coordinator according to > http://techbase.kde.org/Projects/Release_Team > so matt, please review both klickety and ksame and determine whether to give > the permission to include klickety and remove ksame. Ok, sorry for the extremely late reply on this and my general lack of activity recently. I've had a look at the game and I agree with what has already been said. I think that the game should be moved into the main SVN module (before the hard freeze on the 11th). What are other people's thoughts on moving it in ASAP? And removing KSame? Reiterating what Mauricio said, we shouldn't be blocking games for silly reasons. This a well written game with an enthusiastic developer who has been in good communication with us and has followed the rules. I do admit responsibility for this though. I'm still marked down as the module release manager and I have been really rather lax on that job in the last year or so. Perhaps it's time I stepped down and let someone else take up the job. Only if there is someone else who is willing to step up though -- I'm happy to carry on if there's no-one else. -- Matt Williams http://milliams.com
Re: "Cornelius's grand plan" - Merging KDElibs into Qt
On 31 October 2010 11:53, John Tapsell wrote:
> On 31 October 2010 11:33, Mark Kretschmann wrote:
>> Hey all,
>>
>> after reading the whole thread that started with Chani's mail ("why
>> kdelibs?"), I think the noise level has become a bit too much there.
>> Cornelius had proposed this rather daring idea:
>>
>> http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2
>
>
> Sounds great. This should probably be done by picking a specific
> technology in KDE, and adapting it and merging it to work in Qt.
>
> A wonderful place to start would be kioslaves imho. This is something
> which has a real advantage, is relatively self-contained, and would
> provide a big advantage. Possibly it needs to be merged more with the
> Qt API though.
So, if we decided that we wanted to merge KIO slaves into Qt, what
would the steps we go through be? If we're going to be doing this with
a number of classes we need to have a process which ensures that the
code is Qute enough, KDE still compiles against it (with minimal/no
code changes) etc.
Obviously things like this will be BIC? Even with wrapper classes in
KDE? So I guess we can't just jump and do this for KDE 4.6 -- it's
going to force us into taking some very big steps like jumping to KDE5
or at least boosting the soversion of the libs.
--
Matt Williams
http://milliams.com
