> The complicated nature of the feature is the reason for it, but the point I
> was trying to make was that each of the noisy aspects should be discouraged
> by discouraging merging and encuraging rebasing instead in the documented
> workflows.
A point where i btw. disagree. But i am not willing
On Thursday, February 17, 2011 00:19:56 Stephen Kelly wrote:
> >> What specifically do you mean by "creating useful history" though?
> >> i.e.
> >> what should be done additionally in a rebase workflow to get the
> >> useful
> >> history you refer to?
> >
> > Do this:
> cd /tmp
> git clone git://g
Michael Jansen wrote:
>
>> mjansen might just have been following a 'never rebase public branches'
>> philosphy, but that really doesn't work for me. It was a complicated
>> feature requiring lots of refactoring.
>
> Hehe ... as the one doing the code i would say it was more like
>
> mjans
> mjansen might just have been following a 'never rebase public branches'
> philosphy, but that really doesn't work for me. It was a complicated feature
> requiring lots of refactoring.
Hehe ... as the one doing the code i would say it was more like
mjansen stumbled through unchartered terr
Sorry, knode fails me again. Some keyboard shortcut must be too close to
ctrl+v for me...
Stephen Kelly wrote:
>> Either way is an assumption, but only one of these assumptions involves
>> deliberately discarding data. ;)
If noise is data, you would have a good point.
>>
>> What specifically d
On 16/02/2011, Stephen Kelly wrote:
> Michael Pyne wrote:
>> Either way is an assumption, but only one of these assumptions involves
>> deliberately discarding data. ;)
>>
>> What specifically do you mean by "creating useful history" though? i.e.
>> what should be done additionally in a rebase wor
Michael Pyne wrote:
>
>> People who are interested in ksslsocket will see the commits.
>
> You're thinking of CommitFilter. I'm thinking of the kde-commits mailing
> list (i.e. people who didn't *know* they were interested in ksslsocket
> until they saw a "strange" commit).
I wasn't really. It's
Ben Cooksley wrote:
>
> Ah, you clearly have no understanding of the damage a "flood" or
> "email bomb" causes.
Correct :)
> Prior to git.kde.org being made available for mainstream use, in the
> 1st generation of hooks, a flood occurred.
>
> This flood completely filled ktown's email queue, pr
Aaron J. Seigo wrote:
> On Tuesday, February 15, 2011, Stephen Kelly wrote:
>> http://steveire.com/kdelibs-modular.png
>>
>> * It's broad at the base - Qt developers can pick and choose what they
>> want. There are less interdependencies - you can use the itemviews stuff
>> without also pulling i
On Wednesday, February 16, 2011 22:31:31 Stephen Kelly wrote:
> > An easy way to solve duplicates is to disable sending commit mails for
> > branches other than master, but I personally dislike that solution as
> > it
> > would result in mailing lists like #kde-commits not receiving any
> > emails
David Jarvie wrote:
>>
>> Anyway, I've started a page to document such things at
>> http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there.
>> David Jarvie, could you add something to the KDateTime entry?
>
> Done. I hope it contains enough explanation - if you think it needs mo
John Layt wrote:
> On Monday 14 February 2011 22:35:13 Stephen Kelly wrote:
>> You might think in terms of how much a typical KDE application ends up
>> using, but I'm thinking in terms of how much a typical Qt application
>> ends up using. Gregory is not going to end up using KLocale KConfig
>> K
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6500/
---
Review request for kdelibs and George Goldberg.
Summary
---
KInetD prov
On Thu, Feb 17, 2011 at 10:31 AM, Stephen Kelly wrote:
> Michael Pyne wrote:
>
>> An easy way to solve duplicates is to disable sending commit mails for
>> branches other than master, but I personally dislike that solution as it
>> would result in mailing lists like #kde-commits not receiving any
Michael Pyne wrote:
> An easy way to solve duplicates is to disable sending commit mails for
> branches other than master, but I personally dislike that solution as it
> would result in mailing lists like #kde-commits not receiving any emails
> until the branch is fully landed on master. (I hate t
Aaron J. Seigo wrote:
> Open questions / topics for further discovery:
>
> * documenting best practices for keeping a topic branch in sync with
> master, keeping in mind that later a merge from the topic branch to master
> needs to be done and the git history sould be kept as clean as possible
A
On Wednesday, February 16, 2011 13:45:46 Stefan Majewsky wrote:
> On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo wrote:
> > Only features / topics that are intended from the state to be merged
> > with
> > master should end up in the main repository, however. More experimental
> > and/or long ter
On Wednesday, February 16, 2011 12:05:51 Raphael Kubo da Costa wrote:
> On Wednesday 16 February 2011 10:58:48 John Layt wrote:
> > # ===[ Subject ]===|
> > # ---[ One line only, short meaningful description to show in logs ]---|
>
> Personally,
Why?
Albert
Hey there,
Sune Vuorela writes:
> Hi peoples
>
> I have added prison (git clone kde:prison) to kdereview, targetting
> kdesupport.
>
> Please review.
As said on IRC, the cmake/modules directory is missing the copyright
file, and the FindFoo.cmake modules could be simplified with
FindPackageHand
On Wednesday, February 16, 2011, Stephen Kelly wrote:
> jlayt: I don't see it happening :( For example - currency -
> KLocale just provides too much - we _can_ put it all to Qt, but it will
> take too much effort with no clear benefit - nobody asking for that.
> People are asking us to provide a w
On Wednesday, February 16, 2011, David Jarvie wrote:
> There would be a major benefit from splitting KConfig etc out of kdecore:
> Qt developers could use the stripped down library confident in the
> knowledge that they could use any class in it without having to worry
> about whether they might ac
On Wed, February 16, 2011 11:57 am, John Layt wrote:
> The thing is, most of what is in kdecore date classes really does belong
> in the Qt classes, these are standard things on all platforms that Qt just
> hasn't
> implemented. QLocale is bizarrely incomplete in places. Why wouldn't Qt
> want
>
On Wednesday 16 February 2011 10:58:48 John Layt wrote:
> # ===[ Subject ]===|
> # ---[ One line only, short meaningful description to show in logs ]---|
Personally, I find that starting this short description with the "module",
"library" or wha
On Wed, February 16, 2011 1:44 am, Aaron J. Seigo wrote:
> On Tuesday, February 15, 2011, Stephen Kelly wrote:
>> http://steveire.com/kdelibs-modular.png
>>
>> * It's broad at the base - Qt developers can pick and choose what they
>> want. There are less interdependencies - you can use the itemview
On Tuesday 15 February 2011 18:32:29 John Layt wrote:
> Actually, even more complete minutes, outstanding issues and action points
> can be found at http://community.kde.org/20110213_GitWorkflowAgenda
Following up on my action points for the commit template and config settings.
I've attached a re
John Layt wrote:
> Anyway, I've started a page to document such things at
> http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there.
> David Jarvie, could you add something to the KDateTime entry?
>
> Cheers!
>
I added some links to time zone related bug reports. Surprisingly t
On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo wrote:
> Only features / topics that are intended from the state to be merged with
> master should end up in the main repository, however. More experimental and/or
> long term efforts (an example presented was the kconfig refactor leading up to
> 4.0
On Tuesday 15 February 2011, todd rme wrote:
> On Tue, Feb 15, 2011 at 11:19 AM, Sune Vuorela wrote:
> > On 2011-02-15, Parker Coates wrote:
> >> On Tue, Feb 15, 2011 at 03:45, Sune Vuorela wrote:
> >>> I have added prison (git clone kde:prison) to kdereview, targetting
> >>> kdesupport.
> >>
>
On Monday 14 February 2011 22:35:13 Stephen Kelly wrote:
> You might think in terms of how much a typical KDE application ends up
> using, but I'm thinking in terms of how much a typical Qt application ends
> up using. Gregory is not going to end up using KLocale KConfig KDateTime
> etc just becaus
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100578/#review1454
---
Ship it!
Looks good, nice cleanup and fix, thanks.
Long ago the
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100578/#review1453
---
Any comments? If there are no further objections, I'll commit th
32 matches
Mail list logo
