On Monday, 31 de January de 2011 16:05:43 Aaron J. Seigo wrote:
> this was before i did any cherry-picks myself, but perhaps others had
> already beat me to it. in any case, is there a way to fix it so that the
> 4.6 branch would become mergeable with master, or do we now basically just
> have to w
On Monday, 31 de January de 2011 18:37:32 Dawit A wrote:
> On Mon, Jan 31, 2011 at 5:27 PM, Thiago Macieira wrote:
> > On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> >> Hi,
> >>
> >> something that hasn't been written down as far as I can see (if I
> >> overlooked it, please p
On Tuesday, 1 de February de 2011 01:23:01 Oswald Buddenhagen wrote:
> just face it, git's merging concept makes most sense for longer-lived
> feature branches, but not so much for bugfix branches. not even linux
> itself uses a forward-merge strategy for bugfix branches.
How does the kernel work
On Monday, January 31, 2011, Andreas Pakulat wrote:
> On 01.02.11 01:18:58, Pino Toscano wrote:
> > Alle martedì 1 febbraio 2011, Aaron J. Seigo ha scritto:
> > > > The concern that I have, on the other hand, is whether this can be
> > > > done in a source and binary compatible fashion. I just took
On Monday, January 31, 2011, Anders Lund wrote:
> Please do not make everything the desktop, as long as it is not keyboard
> accerssible! I avoid using plasma-notebook, since it is an interface for
> clickers.
please do not make knee-jerk reactions. please create informed opinions, ask
questions
On Mon, Jan 31, 2011 at 19:08, Michael Pyne wrote:
> On Monday, January 31, 2011 18:19:12 Albert Astals Cid wrote:
>> cons:
>> * There is black magic happening behind your back and once something
>> breaks you won't know how to fix things by yourself.
>
> For instance even after using kdesrc-build
On 01.02.11 01:18:58, Pino Toscano wrote:
> Alle martedì 1 febbraio 2011, Aaron J. Seigo ha scritto:
> > > The concern that I have, on the other hand, is whether this can be
> > > done in a source and binary compatible fashion. I just took a look
> > > at
> >
> > yes, it can. and i don't believe a
On 31.01.11 16:05:43, Aaron J. Seigo wrote:
> On Monday, January 31, 2011, Thiago Macieira wrote:
> > On Monday, 31 de January de 2011 14:44:38 Aaron J. Seigo wrote:
> > > On Monday, January 31, 2011, Andreas Pakulat wrote:
> > > > something that hasn't been written down as far as I can see (if I
>
On Tuesday 01 February 2011 01:13:16 Nuno Pinheiro wrote:
> A Segunda, 31 de Janeiro de 2011 23:58:54 Anders Lund você escreveu:
> > Please do not make everything the desktop, as long as it is not keyboard
> > accerssible! I avoid using plasma-notebook, since it is an interface for
> > clickers. Su
On Tue, Feb 01, 2011 at 12:29:12AM +0100, Thiago Macieira wrote:
> On Monday, 31 de January de 2011 23:50:49 Oswald Buddenhagen wrote:
> > On Mon, Jan 31, 2011 at 11:27:15PM +0100, Thiago Macieira wrote:
> > > Commit to 4.6, merge 4.6 into master.
> >
> > that's hard enough in qt, and there is tot
Alle martedì 1 febbraio 2011, Aaron J. Seigo ha scritto:
> > The concern that I have, on the other hand, is whether this can be
> > done in a source and binary compatible fashion. I just took a look
> > at
>
> yes, it can. and i don't believe anything in kdelibs itself uses it.
khtml does (but we
A Segunda, 31 de Janeiro de 2011 23:58:54 Anders Lund você escreveu:
> Please do not make everything the desktop, as long as it is not keyboard
> accerssible! I avoid using plasma-notebook, since it is an interface for
> clickers. Such interfaces may make sense for tablets and phones, NOT for
> any
On Monday, January 31, 2011 18:19:12 Albert Astals Cid wrote:
> cons:
> * There is black magic happening behind your back and once something
> breaks you won't know how to fix things by yourself.
Although it is definitely true that kdesrc-build hides what it's doing unless
you delve into either
On Monday, January 31, 2011, Michael Pyne wrote:
> On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote:
> > potential caveats are that it makes it harder to build certain KDE apps
> > because now you need not only kdelibs, but kate. this is already true for
> > things that require libs in kde
On Monday, January 31, 2011, Thiago Macieira wrote:
> On Monday, 31 de January de 2011 14:44:38 Aaron J. Seigo wrote:
> > On Monday, January 31, 2011, Andreas Pakulat wrote:
> > > something that hasn't been written down as far as I can see (if I
> > > overlooked it, please point me to it) is what t
On Monday, January 31, 2011, Albert Astals Cid wrote:
> * There is black magic happening behind your back and once something
> breaks you won't know how to fix things by yourself.
we can and should document how to do all the things "by hand" as well for such
situations.
but it would be nice if
On Monday, January 31, 2011 17:48:38 Aaron J. Seigo wrote:
> On Sunday, January 30, 2011, Michael Pyne wrote:
> > Like I said, "xml-support" branch on kdesrc-build git. If you want to
> > give
>
> _very_ cool. will the good news today never end? ;)
>
> serious question: once this is stabilized, c
Please do not make everything the desktop, as long as it is not keyboard
accerssible! I avoid using plasma-notebook, since it is an interface for
clickers. Such interfaces may make sense for tablets and phones, NOT for
anything with a keyboard!
--
tia,
Anders
On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote:
> potential caveats are that it makes it harder to build certain KDE apps
> because now you need not only kdelibs, but kate. this is already true for
> things that require libs in kde-support, kdepimlibs or kdegraphics, though.
This is mor
On Mon, Jan 31, 2011 at 5:27 PM, Thiago Macieira wrote:
> On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
>> Hi,
>>
>> something that hasn't been written down as far as I can see (if I
>> overlooked it, please point me to it) is what the policy on kdelibs is
>> to be now wrt. merg
On Monday, 31 de January de 2011 18:25:38 Parker Coates wrote:
> On Mon, Jan 31, 2011 at 17:36, Stefan Majewsky wrote:
> > On Mon, Jan 31, 2011 at 11:34 PM, Arno Rehn wrote:
> >> (Feature branches are a different thing).
> >
> > Am I right that these should be rebased instead of merged?
>
> It's
On Monday, 31 de January de 2011 14:44:38 Aaron J. Seigo wrote:
> On Monday, January 31, 2011, Andreas Pakulat wrote:
> > something that hasn't been written down as far as I can see (if I
> > overlooked it, please point me to it) is what the policy on kdelibs is
> > to be now wrt. merging vs. cherr
On Monday, 31 de January de 2011 23:50:49 Oswald Buddenhagen wrote:
> On Mon, Jan 31, 2011 at 11:27:15PM +0100, Thiago Macieira wrote:
> > On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> > > something that hasn't been written down as far as I can see (if I
> > > overlooked it, pl
On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote:
> I guess that won't quite work when there are commits specific to 4.6 in the
> 4.6 branch that shouldn't end up in master. And it clutters history with
> tons of merges.
Then let's solve the problem by not having anything specific to 4.6.
On Mon, Jan 31, 2011 at 17:36, Stefan Majewsky wrote:
> On Mon, Jan 31, 2011 at 11:34 PM, Arno Rehn wrote:
>>
>> (Feature branches are a different thing).
>
> Am I right that these should be rebased instead of merged?
It's my understanding that rebasing is only allowed for private, local
branches.
A Dilluns, 31 de gener de 2011, Aaron J. Seigo va escriure:
> On Sunday, January 30, 2011, Michael Pyne wrote:
> > Like I said, "xml-support" branch on kdesrc-build git. If you want to
> > give
>
> _very_ cool. will the good news today never end? ;)
>
> serious question: once this is stabilized,
On Mon, Jan 31, 2011 at 11:27:15PM +0100, Thiago Macieira wrote:
> On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> > something that hasn't been written down as far as I can see (if I
> > overlooked it, please point me to it) is what the policy on kdelibs is
> > to be now wrt. mer
On Sunday, January 30, 2011, Michael Pyne wrote:
> Like I said, "xml-support" branch on kdesrc-build git. If you want to give
_very_ cool. will the good news today never end? ;)
serious question: once this is stabilized, can we make this the default
recommended way of building KDE from git on te
On Monday, January 31, 2011, Andreas Pakulat wrote:
> something that hasn't been written down as far as I can see (if I
> overlooked it, please point me to it) is what the policy on kdelibs is
> to be now wrt. merging vs. cherry-picking of changes in branches and
> master?
what i've started doing
hi :)
since Ian already brought it up and suggested a separate thread for it, let me
do just that. we discussed this a bit on the release mailing list, but the
discussion really ought involve more people since it will impact us all.
the idea is this (and the Kate devs are just fine with it, btw
On Mon, Jan 31, 2011 at 11:34 PM, Arno Rehn wrote:
> (Feature branches are a different thing).
Am I right that these should be rebased instead of merged?
On Monday 31 January 2011 23:27:15 Thiago Macieira wrote:
> On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> > Hi,
> >
> > something that hasn't been written down as far as I can see (if I
> > overlooked it, please point me to it) is what the policy on kdelibs is
> > to be now wr
in case anyone wants to follow this topic, we're discussing it extensively on
plasma-de...@kde.org ... the ideas are taking shape and it's already moved on
from my first email. in fact, you can expect 4.7 to not look like at all what
i suggested in that email :)
we are also documenting (a proce
On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> Hi,
>
> something that hasn't been written down as far as I can see (if I
> overlooked it, please point me to it) is what the policy on kdelibs is
> to be now wrt. merging vs. cherry-picking of changes in branches and
> master?
Co
Hi,
something that hasn't been written down as far as I can see (if I
overlooked it, please point me to it) is what the policy on kdelibs is
to be now wrt. merging vs. cherry-picking of changes in branches and
master?
Andreas
--
You learn to write as if to someone else because NEXT YEAR YOU WIL
2011/1/17 Ingo Malchow :
> Dear beloved KDE developers and contributors,
>
> most of you probably remember the regular requests by Nightrose to
> think about projects that could need some more love from contributors.
>
> Well, now it MY time to make this call :)
> The list on https://promo.notes-de
Hi All,
An apology is in place. I blamed all you guys for cloning from the wrong server
in below mails, but in fact it looks like a problem on our side with the way we
updated the anongit mirrors. We have changed it now.
Old situation: anongit was pulling the changes every 5 minutes. which actu
On Monday 31 January 2011, Marco Martin wrote:
> On Monday 31 January 2011, Alex Fiestas wrote:
> > In KDE we're used to resize the windows to fulfill our personal
> > needs, and let the application save the "last used size". I guess
> > that is because of that feature that a lot of applications do
In KDE we're used to resize the windows to fulfill our personal needs,
and let the application save the "last used size". I guess that is
because of that feature that a lot of applications doesn't care about
the correct size.
A good experiment would be disable that feature in trunk (having a w
On Monday 31 January 2011 10.30.50 Ian Monroe wrote:
[...]
> *We need to have a unified branch naming scheme. Basically we need to
> come up with what we want the branches to be named, and then ask the
> sysadmin team to rename them for us.
>
> In use I think the 'KDE/' prefix is a bad idea, since
So thanks to everyone's patience with some of this issues this
weekend. I want to thank KO for their sponsorship and we all should
thank Nicolás Alvarez (PovAddict), as he is responsible for
significant size reductions in the repositories (probably about
~100mb/main repo on average).
Now that the
On Monday 31 January 2011, Alex Fiestas wrote:
> In KDE we're used to resize the windows to fulfill our personal needs,
> and let the application save the "last used size". I guess that is
> because of that feature that a lot of applications doesn't care about
> the correct size.
>
> A good experi
On Mon, Jan 31, 2011 at 10:10 AM, Nuno Pinheiro wrote:
> A Segunda, 31 de Janeiro de 2011 13:54:45 Marco Martin você escreveu:
>> On Monday 31 January 2011, Nuno Pinheiro wrote:
>> > A Segunda, 31 de Janeiro de 2011 13:00:50 Marco Martin você escreveu:
>> > > On Monday 31 January 2011, Nuno Pinhei
A Segunda, 31 de Janeiro de 2011 13:54:45 Marco Martin você escreveu:
> On Monday 31 January 2011, Nuno Pinheiro wrote:
> > A Segunda, 31 de Janeiro de 2011 13:00:50 Marco Martin você escreveu:
> > > On Monday 31 January 2011, Nuno Pinheiro wrote:
> > > > > my proposal is this:
> > > > >
> > > > >
On Monday 31 January 2011, Nuno Pinheiro wrote:
> > my proposal is this:
> >
> > * by default, Search and Launch on the desktop
>
> We talked about this in last tokamac remember?
> Imo a merge of krunner, activityes management, and the cashew and a few
> specific tryicons (just the hardware vital
A Segunda, 31 de Janeiro de 2011 01:22:41, você escreveu:
> hi...
>
> back when we started the path towards plasma i said that we needed to
> slowly evolve the desktop beyond the desktop folder with icons littered on
> the desktop.
>
> now we have activities, kick-ass containments like search and
Am 1/28/2011 17:42, schrieb Andreas Hartmetz:
> Semi-OT: What is the empty line good for?
> Sometimes I just continue writing if the start of a long first sentence turns
> out to be a good summary.
No, really, you should make the summary line short (max 75 characters or
so), and follow it by a bl
47 matches
Mail list logo
