On Fredag den 20. maj 2011, Commit Hook wrote:
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101379/#review3411
> ---
>
>
> This
---
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
e2d70d6c478c1f82f065
---
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
65aabc8c6df6d25fc35d
---
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
dffd5950b35ead8c14c5
On Fri, May 20, 2011 at 4:48 AM, Stephen Kelly 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 of
>> th
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 al
On Thursday, 19 de May de 2011 22:30:35 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 af
On Thu, May 19, 2011 at 10:22 PM, Thiago Macieira wrote:
> 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.
>>
>
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 re
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
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 is
not inflated?
> - Requires some Git magic to recover if the
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
Currently in Ubuntu Natty 11.04, Dbus in compiz does not work perfectly.
might be better in Ubuntu Classic.
2011/5/17 Matthias Clasen :
> On Mon, May 16, 2011 at 5:29 PM, Frederik Gladhorn wrote:
>> Hi,
>> sorry for cross-posting. I would just like to have this looked at by everyone
>> so we can
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.
> Pl
On Thursday, 19 de May de 2011 20:20:13 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.
> - Requires some Git magic to recover if the branch you are currently
> using gets force pushed.
On Thursday, 19 de May de 2011 10:11:04 Boudewijn Rempt wrote:
> In Calligra, we sort of discussed that we might call the staging branch
> where everyone can commit "master", and that we'll try to get an automated
> system to copy commits that didn't break unittests to the release branch,
> which o
2011/5/19 Aaron J. Seigo :
> 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 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
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 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::Mess
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:
http://techbase.kde.org/Development
21 matches
Mail list logo
