On Wednesday, 2011-05-18, Aurélien Gâteau wrote:
Git commit 388edfe3362c07c0d46b3990a325258684aaeb97 by Aurélien Gâteau.
Committed on 18/05/2011 at 22:27.
Pushed by gateau into branch 'master'.
Get rid of the deprecated KMessageWidget::MessageType enum values
I checked with lxr.kde.org
On Thu, May 19, 2011 at 2:01 AM, Kevin Krammer kevin.kram...@gmx.at wrote:
If you had to do that it is a source incompatible change.
Why do you need that?
Irrelevant. This API is new in master and the announcement for it's
modification was made long before. He simply gave it a grace period.
--
On Wednesday, May 18, 2011 22:08:00 Alexander Neundorf wrote:
From my side, I would strongly prefer to have one policy which is used at
least for all of KDE SC, (what was trunk/KDE/ before), if possible also for
kdesupport.
agreed. and in working on this:
On 19/05/2011 08:01, Kevin Krammer wrote:
On Wednesday, 2011-05-18, Aurélien Gâteau wrote:
Git commit 388edfe3362c07c0d46b3990a325258684aaeb97 by Aurélien Gâteau.
Committed on 18/05/2011 at 22:27.
Pushed by gateau into branch 'master'.
Get rid of the deprecated KMessageWidget::MessageType
On Thursday 19 May 2011 Aaron J. Seigo wrote:
http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Workf
low
Wow. This is a pretty complex workflow, and it's breaking with quite some
practices KDE used to use for a very long time. We have to make sure that we
don't leave
On Thursday 19 May 2011 May, Cornelius Schumacher wrote:
On Thursday 19 May 2011 Aaron J. Seigo wrote:
http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Workf
low
Wow. This is a pretty complex workflow, and it's breaking with quite some
practices KDE used to use
On Thursday, May 19, 2011 20:20:13 Ben Cooksley wrote:
I see quite a few problems with that workflow:
thanks for the input; i've added some of the core issues you raise to the
Requirements section of the wiki page. this will help us craft something
that fits the actual needs of us all.
On Thursday, May 19, 2011 10:05:27 Cornelius Schumacher wrote:
On Thursday 19 May 2011 Aaron J. Seigo wrote:
http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Wo
rkf low
Wow. This is a pretty complex workflow, and it's breaking with quite some
practices KDE used to use
Sebastian Trüg wrote:
Like I already said: patching rcgen seems like the best solution to me
and that is so trivial I can have finished it today.
The beta tagging is due to happen today. As far as I know this hasn't been
addressed. Was it more complex than expected or you just didn't have
On Thursday, 19 de May de 2011 11:44:59 Stephen Kelly wrote:
Ben Cooksley wrote:
Second you are heavily advocating rebasing. This shouldn't be done in
public repositories as it:
- Inflates the size of the repository.
I thought git gc which runs periodically would mean that the repo size
Ben Cooksley wrote:
Doesn't apply to KDE repositories, as performing a rebase involves a
force push, which initiates the damage prevention area of our hooks.
This triggers creation of a backup ref protecting the contents of
the old ref from being affected by a gc, and ensures they are always
On Fri, May 20, 2011 at 4:48 AM, Stephen Kelly steve...@gmail.com wrote:
Ben Cooksley wrote:
Doesn't apply to KDE repositories, as performing a rebase involves a
force push, which initiates the damage prevention area of our hooks.
This triggers creation of a backup ref protecting the contents
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101379/#review3411
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101338/#review3412
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101337/#review3413
---
This review has been submitted with commit
15 matches
Mail list logo
