Aaron J. Seigo | 1 Feb 01:01 2011
Picon

Re: Initial support for kde_projects.xml in kdesrc-build

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 the default recommendation was something that a new 
contributor could use to get a full KDE build going with just a few minutes 
effort on their part.

--

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
Aaron J. Seigo | 1 Feb 01:05 2011
Picon

Re: Merge or Cherry-Pick?

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 the policy on kdelibs is
> > > to be now wrt. merging vs. cherry-picking of changes in branches and
> > > master?
> > 
> > what i've started doing for bugfixes is to apply the fix to the stable
> > branch (e.g. 4.6) and then cherry-pick that into master. when i tried to
> > merge the 4.6 branch into master, i just got a ton of conflicts, so i
> > stopped trying that :)
> 
> Because of the cherry-picks.

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 wait 
for a 4.7 branch?

--

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
Aaron J. Seigo | 1 Feb 01:07 2011
Picon

Re: proposal: remove KTextEditor interface from kdelibs repository

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-support, kdepimlibs or kdegraphics,
> > though.
> 
> This is more a package management concern, and while I do want to avoid

indeed; i'm hoping one or more of the packagers will chime in at some point.

> 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.

> should be fine. It would be interesting to see if the various mobile
> development groups have already done something like this in fact.

they tend to strip out lots of things like this, yes. they also tend to do 
things that aren't BC in other libraries in kdelibs to get their size down 
further.

--

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
(Continue reading)

Michael Pyne | 1 Feb 01:08 2011
X-Face
Picon

Re: Initial support for kde_projects.xml in kdesrc-build

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 the --pretend output or the log files (where the command 
run is displayed at the top of every log file), this is also a pro:

pros:
* There is black magic happening behind your back so that users who are 
unwilling/unable to navigate gcc/make/cmake can still build and test bleeding-
edge versions of KDE despite their lack of CLI mastery.

Anytime you add a layer to a working system there is usually a pro of "this 
makes me do less work" and a con of "now I forgot how it works" (e.g. moc, 
high level programming languages in general, etc.)

I certainly don't disagree with the con you mentioned, but I do think that the 
benefit in increased testing coverage outweighs the concern with "black 
magic", especially since I take great pains (and have for years) to have 
kdesrc-build operate as much like you or I would do the build as possible.

For instance even after using kdesrc-build on my source tree for years I can 
go to svn or git modules and run the standard update command (even git pull) 
and everything just works. I can go to the build directory and run make or 
cmake-gui and things just work. When I'm worried about what kdesrc-build is 
about to do, I can pass the --pretend flag and it shows the command line for 
about 95% of the commands it would run. In short it is (my idea of) a bum-
standard build system, or as close as I can get it in an automated script.
(Continue reading)

Nuno Pinheiro | 1 Feb 01:13 2011

Re: the next step on the desktop

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
> anything with a keyboard!

contrary to what some beleve the mouse does some jobs better than the keyboard 
:), plus major major plus the things a mouse does are very very difrent from 
what a touch based interface does... 
-- 
Nuno Pinheiro | nuno.pinheiro <at> kdab.com | UI Designer 
Klarälvdalens Datakonsult AB, a KDAB Group company
KDAB - Qt Experts - Platform-independent software solutions

--

-- 
oxygen guy, "I make the pretty pictures"

Pino Toscano | 1 Feb 01:18 2011
X-Face
Picon

Re: proposal: remove KTextEditor interface from kdelibs repository

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 know very few people care about it).

Apart from that, this move is a bit of "suprise" for whoever compiles 
kdelibs from sources, and gets no KTextEditor by default anymore (after 
years and years). The same goes for the katepart, which means you now 
have to install something additional, instead of relying on what kdelibs 
provided for years? Looks like a bit of source compatibility breaking, 
at least IMHO.

> * it would be an interesting and useful experiment with modularization
> of kdelibs 

I don't think taking out random pieces of kdelibs piece-by-piece is 
something useful to do over time: either you split the whole at once, or 
you don't.

--

-- 
Pino Toscano
Oswald Buddenhagen | 1 Feb 01:23 2011
Picon

Re: Merge or Cherry-Pick?

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 totally no way that kde's
> > discipline would be sufficient to make forward-merging feasible (as in
> > "actually helpful and producing an even remotely readable history").
> 
> Only because in Qt we do it in batches, so we get lots of changes. And
> the Qt repository is way bigger than anything KDE has.
> 
that's part of the problem, but not what i aimed at. people are just too
short-minded and often too lazy (and sometimes don't have the disk space
or cpu/time) to do things in the proper branch to start with. the result
is a lot of cherry-picks even when using forward merging, which makes
for a rather terrible history and a somewhat limited benefit. just look
at qt's history - kde's will be three times worse.

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.

Christoph Feck | 1 Feb 01:28 2011
Picon

Re: the next step on the desktop

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. Such interfaces may make sense for tablets and phones, NOT for
> > anything with a keyboard!
> 
> contrary to what some beleve the mouse does some jobs better than the
> keyboard
> 
> :), plus major major plus the things a mouse does are very very difrent
> :from what a touch based interface does...

People who have both hands on the keyboard are annoyed by anything that 
requires the mouse. Of course, an artist sees it just the other way around ;)

Christoph Feck (pepo)

Andreas Pakulat | 1 Feb 01:43 2011
Picon
Picon

Re: Merge or Cherry-Pick?

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
> > > > 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 for bugfixes is to apply the fix to the stable
> > > branch (e.g. 4.6) and then cherry-pick that into master. when i tried to
> > > merge the 4.6 branch into master, i just got a ton of conflicts, so i
> > > stopped trying that :)
> > 
> > Because of the cherry-picks.
> 
> 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 wait 
> for a 4.7 branch?

One could do a git merge --ours KDE/4.6 if its certain that all changes
from 4.6 have been cherry-picked into master. That'll do the merge, but
ignore any changes in 4.6 and simply always use the master version of
all files. 

Having had a quick look at the result of a normal git merge KDE/4.6 into
master, however I think that this is not desirable. Even some .desktop
files seem to need manual merging (or at least another scripty run, I
can see fr-translations in 4.6 that are not in master). Other things may
(Continue reading)

Andreas Pakulat | 1 Feb 01:57 2011
Picon
Picon

Re: proposal: remove KTextEditor interface from kdelibs repository

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 anything in kdelibs itself uses it.
> 
> khtml does (but we know very few people care about it).

Indeed the debugger does use it, that is a problem as it creates a
hen-egg-problem.

> Apart from that, this move is a bit of "suprise" for whoever compiles 
> kdelibs from sources, and gets no KTextEditor by default anymore (after 
> years and years). The same goes for the katepart, which means you now 
> have to install something additional, instead of relying on what kdelibs 
> provided for years? Looks like a bit of source compatibility breaking, 
> at least IMHO.

Thats nothing really new in KDE land, our SC constantly gets new
dependencies that one needs to fetch and build. With all the movements
to git various repositories already split themselves up (polkit, phonon)
and so far people seem to have been able to adjust to that. No idea
wether the 'promo' around such changes was the cause for that or wether
only packagers were affected as most people get the packages from their
distro, but I haven't seen huge fallout so far because of such changes.

> > * it would be an interesting and useful experiment with modularization
> > of kdelibs 
(Continue reading)


Gmane