Re: Review Request: Speed limit in ftp kio slave

[Nicolas Alvarez]

> On Aug. 10, 2011, 1:07 p.m., David Faure wrote:
> > kioslave/ftp/speedController.h, line 24
> > 
> >
> > kde_file.h isn't used in this header -> move the #include to the .cpp 
> > file.
> 
> Tushar Mehta wrote:
> I have used it for usleep. If I am not including it then it give me this:
> "error: ‘usleep’ was not declared in this scope"

usleep is in . Include that instead.


- Nicolas


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102267/#review5593
---


On Aug. 9, 2011, 7:16 p.m., Tushar Mehta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102267/
> ---
> 
> (Updated Aug. 9, 2011, 7:16 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> ---
> 
> - This patch contains the basic code which will put the limit on download 
> speed of the ftp data transfer.
> - It is looking for "speed-limit" meta-data for deciding how much speed 
> control is required.
> - If this meta-data is not found, code will work as it was before and no 
> speed control related code will come into picture.
> - This patch is the most basic one which I have testing on my system and to 
> the extent it is controlling the speed.
> - Lets say if speed limit is 30 KBps then mostly will get the avg speed 
> around 30 to 35 KBps.
> - I am using QTime for measuring time elapsed between two socket read call 
> and its precision is in millisecond. Looping is taking place in microsecond 
> and thats why I am getting almost all the time 0 as time elapsed in between 
> two calls.
> - To solve the above problem usleep is introduced to make it sync with the 
> timer.
> 
> 
> Diffs
> -
> 
>   kioslave/ftp/CMakeLists.txt e080b02 
>   kioslave/ftp/ftp.h 0bd375b 
>   kioslave/ftp/ftp.cpp 655524a 
>   kioslave/ftp/speedController.h PRE-CREATION 
>   kioslave/ftp/speedController.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/102267/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Tushar
> 
>

Re: kdeutils has migrated to git

[Nicolas Alvarez]

Aaron J. Seigo wrote:
> On Saturday, August 20, 2011 16:48:09 Raphael Kubo da Costa wrote:
>> For now, I have created a scratch git repository with the files which
>> used to be in the top-level kdeutils directory in SVN, so you can just
>> use the CMakeLists.txt there to build everything (there are no
>> inter-repository dependencies, that is, thereis no libkdeutils).
> 
> imho better would be to use:
> 
> https://projects.kde.org/projects/kde/superbuild/repository
> 
> it has a kdeutils section already even ... still needs some improvements
> as it uses anongit.kde.org instead of (at least optionally) the kde:
> prefix, but this is a good step in the right direction.

As I said in another thread: Superbuild is unrelated and orthogonal to the 
ability of the kdeutils buildsystem to allow building both as standalone 
apps and as a single module.

-- 
Nicolas

Re: How to see the resolution of merge of KDE/4.7 into KF5

[Nicolas Alvarez]

Stephen Kelly wrote:
> I couldn't make git show me the conflicts. I tried git show, which
> surprises me as it shows a 3 way diff of a single file which was
> apparently not in conflict (full output at
> http://steveire.com/mergecommit). I also tried several variations of git
> diff frameworks^...origin/KDE/4.7.
> 
> How can I see the conflicts resolved in a merge? Do I just see no conlicts
> because I chose the frameworks branch in every hunk (which actually I
> don't think I did)?

The 3-way diff doesn't show conflicted files. It shows files that, in the 
merge commit, aren't identical to the version in either merge parent, which 
means the file was modified in both branches being merged.

If you chose always the same branch (whether frameworks or 4.7) for all 
hunks within a file, that file is identical to the one in that branch, so it 
won't appear in 'git show'. On the other hand, if a file was changed in both 
branches but git could merge it automatically without a conflict, it *will* 
appear in 'git show'.

There is nothing in git that "remembers" whether you got a conflict or not 
(ie. whether git's merging algorithms failed to do the merge automatically 
and asked you to resolve it by hand).

-- 
Nicolas

Re: My Plans, Your Plans: Berlin Desktop Summit

[Nicolas Alvarez]

Alex Fiestas wrote:
> · Draft a plan for colord integration (next thing after krandr is fixed)

That better be optional at runtime :) There aren't that many people who
care about color profiles (but we really need the functionality for those 
who do).

> · Draft a plan for systemd kde-workspace integration (there are a couple
> of things we can do I think)

Yes, please! :)

-- 
Nicolas

Re: My Plans, Your Plans: Berlin Desktop Summit

[Nicolas Alvarez]

Sebastian Kügler wrote:
> One of my goals is to take steps to make the release team more scalable,
> and reduce its bus numbers.

Surely you mean increase :) A bus number of 1 means the team has a single 
point of failure.

-- 
Nicolas

Re: Review Request: Fix logic with clear-button animation in klineedit (notably at first try) and address bug 268898.

[Nicolas Alvarez]

> On July 26, 2011, 10:46 p.m., Aleix Pol Gonzalez wrote:
> > kdeui/widgets/klineedit.cpp, line 358
> > 
> >
> > Wouldn't it be better to put it this way? Just saying...
> > 
> > d->clearButton->animateVisible(d->wideEnoughForClear && text.length() > 
> > 0);

I think the original is clearer, to be honest.


- Nicolas


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102095/#review5129
---


On July 26, 2011, 9:54 p.m., Hugo Pereira Da Costa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102095/
> ---
> 
> (Updated July 26, 2011, 9:54 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> ---
> 
> Details:
> - fixes the somewhat incorrect logic in KLineEditButton::animateVisible
> - simplifies KLineEdit::updateClearButtonIcon consequently.
> 
> 
> This addresses bug 268898.
> http://bugs.kde.org/show_bug.cgi?id=268898
> 
> 
> Diffs
> -
> 
>   kdeui/widgets/klineedit.cpp 8f1c8a4 
>   kdeui/widgets/klineedit_p.h 95016bd 
> 
> Diff: http://git.reviewboard.kde.org/r/102095/diff
> 
> 
> Testing
> ---
> 
> tested with klineedittest found in kdelibs/kdeui/tests, this with and without 
> the patch attached to comment #1 of bug 268898, used to actually trigger the 
> mentionned bug. Also tested with other klineEdit implementation such as 
> Dolphin's location bar.
> 
> 
> Thanks,
> 
> Hugo
> 
>

Re: Formal complaint concerning the use of the name "System Settings" by GNOME

[Nicolas Alvarez]

David Jarvie wrote:
> On Mon, July 25, 2011 12:50 pm, Ambroz Bizjak wrote:
>> Hi Mark,
>> have you seen my proposed improvement on your suggestion?
>>
>> http://lists.kde.org/?l=kde-core-devel&m=131149560119520&w=2
>>
>> I suggest that you consider it, because it would avoid having to
>> update the Freedesktop specification and any DE that doesn't name its
>> programs differently in other DEs (e.g. Xfce).
> 
> This proposal has the same drawbacks as Mark's - it is aimed at
> knowledgeable users, not the ordinary user who may not be aware of which
> desktop a particular application is from. See
> http://lists.kde.org/?l=kde-core-devel&m=131159889604990&w=2.

So what is *your* proposed solution?

As you say, the long term solution is to have setting interoperability. The 
key words there are "long term". We can't do that *now*, before the new KDE 
release and before the new GNOME release. We need a solution *now* to avoid 
having two entries with the exact same name in the application list.

Mark and Ambroz's solutions have the advantage of not requiring months of 
collaboration and programming, which would be needed for setting 
interoperability.

-- 
Nicolas

Re: Fixes in Git (first in stable, then merge to master)

[Nicolas Alvarez]

Nicolas Alvarez wrote:
> - Figure out how to solve the scripty problem. scripty does its own
> conflicting commits to .desktop files in both branches, and that won't
> change[1]. We probably need a custom merge tool for .desktop-like files
> that ignores translations.

I *think* I managed to write such a merge tool. I still need more testing 
and fixing. For example, if there is an actual file conflict, I'm handling 
it pretty badly right now (no conflict markers or anything).

Also, when merging 4.7 into master, it seems that if a .desktop file was 
only modified in 4.7, git will do the merge automatically, bringing those 
4.7 changes into master, without running the custom merge tool. Those 
changes would be undone again next time scripty runs.

But this seems promising anyway. Stay tuned :)

-- 
Nicolas

Re: Fixes in Git (first in stable, then merge to master)

[Nicolas Alvarez]

David Jarvie wrote:
> On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote:
> During the stable branch freeze before a minor version release (such as
> currently before the 4.7 release), it isn't possible to commit bug fixes
> to stable first and then merge to master. Only master can be committed to,
> so presumably we'll have to continue to commit to master and cherry-pick
> later once the freeze ends. Either that or change the policy on freezes.

You could branch 4.7 into (say) 4.7-fixes to do bugfixes during the freeze, 
and merge it back into 4.7 when the freeze ends.

-- 
Nicolas

Re: Fixes in Git (first in stable, then merge to master)

[Nicolas Alvarez]

Alex Fiestas wrote:
> Last few days I have been patching some pieces of our workspace here and
> there, the first set of patches I did them directly into master which if
> I remember correctly was against the policy.
> So, the second round of fixes I tried to do it the right way, which is:
> 1-Create the patch while using 4.7 (optional I guess)
> 2-Test the patch in 4.7
> 3-Commit the patch in 4.7
> 4-Checkout master branch
> 5-Merge 4.7 into master
> 
> [...]
> 
> So, at this point I'm wondering if the policy is bad or (and this option
> is the more plausible) I don't know how to use the tool.
> 
> Cheers and sorry for the cherry-pick's I've done so far.

There is no active policy saying you're supposed to merge. Almost everybody 
in KDE is still doing cherry-picks. KDevelop is the only KDE project I know 
that consistently uses forward-merges from the stable branch to master.

---

It *would* be good to switch to the new workflow of doing changes in the 
lowest supported branch and up-merging, but it's not that easy. We need to:

- Figure out how to solve the scripty problem. scripty does its own 
conflicting commits to .desktop files in both branches, and that won't 
change[1]. We probably need a custom merge tool for .desktop-like files that 
ignores translations.

- Check if there is any change in 4.7 that isn't in master, and if so, see 
if that's intentional (4.7-specific hack, or the version bumps) or an 
oversight (never cherry-picked into master).

- Do the initial merge from 4.7 to master, solving the conflicts. The more 
they have diverged, the harder this is.

- Get *everyone* to start with the new workflow for that particular 
repository (see below). Else, if some people keep cherry-picking while 
others expect merging, the next one to try merging may get conflicts about 
all the cherry-picks people did since the last merge, and a merge will make 
commits appear duplicated in the log (as ossi pointed out to me).

Off to read about custom git merge drivers...

-- 
Nicolas

Re: Review Request: Locale-independent parsing of floats in trader queries

[Nicolas Alvarez]

> On July 10, 2011, 11:27 p.m., Nicolas Alvarez wrote:
> >

okay... reviewboard ate my message. Trying again:

Note that flex (.l) files are used to generate C/C++ source code, but that's 
*not* being done at build time. You'll have to manually update lex.c when 
committing this change.

(I tried fixing this and making all flex/bison get generated at compile time, 
but I ran into some CMake compatibility problems, so I think it'll have to wait 
for the next source-compat break...)


- Nicolas


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101610/#review4582
---


On July 10, 2011, 7:39 a.m., Chusslove Illich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101610/
> ---
> 
> (Updated July 10, 2011, 7:39 a.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> ---
> 
> Usage of atof() to parse floats in trader language was locale-dependent:
> if locale specified something other than dot as decimal separator,
> parsing floats (which are always dot-separated in queries) failed.
> Replaced atof() with simple sufficient custom parser.
> 
> Added a unit test.
> 
> 
> This addresses bug 275548.
> http://bugs.kde.org/show_bug.cgi?id=275548
> 
> 
> Diffs
> -
> 
>   kdecore/services/lex.l b00013b 
>   kdecore/tests/kservicetest.h 189bbd4 
>   kdecore/tests/kservicetest.cpp 8d14213 
> 
> Diff: http://git.reviewboard.kde.org/r/101610/diff
> 
> 
> Testing
> ---
> 
> Unit test.
> 
> In bug #275548 a plugin could not be loaded in some locales because,
> as it turned out, it failed version check due to misparsed floats
> in a trader query. This fix makes it load properly.
> 
> 
> Thanks,
> 
> Chusslove
> 
>

Re: Review Request: Locale-independent parsing of floats in trader queries

[Nicolas Alvarez]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101610/#review4582
---


- Nicolas


On July 10, 2011, 7:39 a.m., Chusslove Illich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101610/
> ---
> 
> (Updated July 10, 2011, 7:39 a.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> ---
> 
> Usage of atof() to parse floats in trader language was locale-dependent:
> if locale specified something other than dot as decimal separator,
> parsing floats (which are always dot-separated in queries) failed.
> Replaced atof() with simple sufficient custom parser.
> 
> Added a unit test.
> 
> 
> This addresses bug 275548.
> http://bugs.kde.org/show_bug.cgi?id=275548
> 
> 
> Diffs
> -
> 
>   kdecore/services/lex.l b00013b 
>   kdecore/tests/kservicetest.h 189bbd4 
>   kdecore/tests/kservicetest.cpp 8d14213 
> 
> Diff: http://git.reviewboard.kde.org/r/101610/diff
> 
> 
> Testing
> ---
> 
> Unit test.
> 
> In bug #275548 a plugin could not be loaded in some locales because,
> as it turned out, it failed version check due to misparsed floats
> in a trader query. This fix makes it load properly.
> 
> 
> Thanks,
> 
> Chusslove
> 
>

KConfigIniBackend::isWritable bug

[Nicolas Alvarez]

Hi,

I'm trying to get kdelibs unit tests to run in a clean and headless 
environment (for automated testing). I'm starting an X server, dbus, and 
kdeinit by hand.

Currently kded (started by kdeinit) is failing to start up if I'm running it 
for the first time and there is currently no ~/.kde directory.
Specifically, it's showing a kdialog popup with 'Configuration file 
"/var/lib/buildbot/.kde/share/config/kdedrc" not writable.'. (I don't even 
see the popup because it's on the invisible Xvfb server).

After some code-reading and debugging, I found the cause. kded checks if 
~/.kde/share/config/kdedrc is writable via KConfigIniBackend::isWritable(). 
This function first checks if the file itself is writable using access() 
(well, KStandardDirs::checkAccess). Then there is this code:

// The check might have failed because any of the containing dirs
// did not exist. If the file does not exist, check if the deepest
// existing dir is writable.
if (!QFileInfo(filePath()).exists()) {
QDir dir = QFileInfo(filePath()).absolutePath();
while (!dir.exists()) {
if (!dir.cdUp()) {
return false;
}
}
return QFileInfo(dir.absolutePath()).isWritable();
}

This code will never succeed for more than one level of directories: 
QDir::cdUp() requires an existing and readable parent directory! So it would 
only work in this case if ~/.kde/share already exists.

What's the cleanest way to rewrite it? dir=dir.filePath("..")?

-- 
Nicolas

Re: Releases of the thing that was KDE

[Nicolas Alvarez]

Scott Kitterman wrote:
> New thread as requested.
> 
> I've been told on IRC that we will still have an integrated release of
> what used to be KDE (I've no clue what to call it now since I think I read
> KDE SC was deprecated).
> 
> All I see in the messaging from the platform sprint seems to be about
> further deconstruction and decentralization.
> 
> The KDE 4.7 beta 1 tarballs are an inconsistent mess that clearly weren't
> coherently thought out (don't get me started about modules thinking it'd
> be a
> great idea to split tarballs in 4.6.3).  [to be clear, I'm not against
> splitting, I'd just like it to be planned out and done consistently, once
> so we don't have to redo packaging multiple times].

What module split tarballs in 4.6.3? I thought tarball layout remained fixed 
throughout 4.6.

-- 
Nicolas

(I read mailing lists through Gmane. Please don't Cc me on replies; it makes 
me get one message on my newsreader and another on email.)

Re: Objections to stop creating nightly tarballs from svn?

[Nicolas Alvarez]

Michael Pyne wrote:
> Perhaps this is ironic, but kdesrc-build does *not* at this point support
> snapshots for git modules (even hosted on git.kde.org) because I assume
> (and this is just my assumption) that the cost of generating the snapshot
> would be a net loss for the git.kde.org server.

The snapshots will keep being generated whether kdesrc-build uses them or 
not, so you won't be causing any more server load.

The main advantage of using the snapshots for the initial clone is that you 
can resume aborted downloads via the usual HTTP mechanisms, which is not 
possible via git://.

-- 
Nicolas

Re: Review Request: Deprecate KLineEdit::clickMessage

[Nicolas Alvarez]

> On May 14, 2011, 4:01 a.m., Shaun Reich wrote:
> > Are you sure the behaviour for the Qt method 100% equivalent to the 
> > current? I ask this because now that the deprecated method forwards to it, 
> > naturally it's quite important to make sure nothing gets fscked up.

Someone in #kde-devel tried it a little ago. Apparently one of them renders the 
placeholder text in italics and the other doesn't (don't remember which).

(Also, using *both* causes both to draw, one unreadably over the other)


- Nicolas


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101360/#review3308
---


On May 14, 2011, 12:59 a.m., Davide Bettio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101360/
> ---
> 
> (Updated May 14, 2011, 12:59 a.m.)
> 
> 
> Review request for kdelibs and Plasma.
> 
> 
> Summary
> ---
> 
> Since Qt 4.7 QLineEdit::setPlaceholderText is available so 
> KLineEdit::clickMessage should be deprecated.
> I kept clickMessage as not deprecated in plasma/widgets/lineedit but now is 
> using placeholderText.
> 
> 
> Diffs
> -
> 
>   kdeui/widgets/klineedit.h 909d1f7 
>   kdeui/widgets/klineedit.cpp 0dd3690 
>   plasma/widgets/lineedit.cpp 09c0c66 
> 
> Diff: http://git.reviewboard.kde.org/r/101360/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Davide
> 
>

Re: Review Request: Fix compile of KIO with KDE_ENABLE_FINAL enabled.

[Nicolas Alvarez]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101277/
---

(Updated May 2, 2011, 9:34 p.m.)


Review request for kdelibs.


Changes
---

Rewrite according to Dawit's suggestion.


Summary (updated)
---

kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. The first 
problem is in kio, where there's two file-static functions with the same name 
(isLocalRequest) and slightly different code.

Fixed by renaming one of the functions.


Diffs (updated)
-

  kio/kio/accessmanagerreply_p.cpp ccc7474799734b91112d70dc81945b8fe9b9f96c 

Diff: http://git.reviewboard.kde.org/r/101277/diff


Testing
---

Compilation of kdelibs/kio with and without final. Didn't try installing or 
running.
Other parts of kdelibs still don't work with final.


Thanks,

Nicolas

Re: Review Request: Fix compile of KIO with KDE_ENABLE_FINAL enabled.

[Nicolas Alvarez]

> On May 2, 2011, 8:26 p.m., Dawit Alemayehu wrote:
> > Instead of doing all that, please rename the local static function in 
> > accessmanagerreply_p.cpp to "isLocalResource(...)" and be done with it.

So the one checking for scheme=="data" should remain isLocalRequest, and the 
one not checking for "data" should be isLocalResource?

I don't really understand those names; maybe the functions need doxygen even if 
they're static :)


- Nicolas


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101277/#review3076
-----------


On May 2, 2011, 7:26 p.m., Nicolas Alvarez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101277/
> ---
> 
> (Updated May 2, 2011, 7:26 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> ---
> 
> kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. The first 
> problem is in kio, where there's two file-static functions with the same name 
> (isLocalRequest) and slightly different code.
> 
> This patch fixes kio compilation by moving the two isLocalRequest functions 
> into the corresponding private classes.
> 
> 
> Diffs
> -
> 
>   kio/kio/accessmanager.cpp 03b75898b0fcc6b47518fde8a8b3afc23a1a677f 
>   kio/kio/accessmanagerreply_p.h 408b5331c999633f4f5d603a70cb419678249a7e 
>   kio/kio/accessmanagerreply_p.cpp ccc7474799734b91112d70dc81945b8fe9b9f96c 
> 
> Diff: http://git.reviewboard.kde.org/r/101277/diff
> 
> 
> Testing
> ---
> 
> Compilation of kdelibs/kio with and without final. Didn't try installing or 
> running.
> Other parts of kdelibs still don't work with final.
> 
> 
> Thanks,
> 
> Nicolas
> 
>

Review Request: Fix compile of KIO with KDE_ENABLE_FINAL enabled.

[Nicolas Alvarez]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101277/
---

Review request for kdelibs.


Summary
---

kdelibs compilation is broken with KDE4_ENABLE_FINAL turned ON. The first 
problem is in kio, where there's two file-static functions with the same name 
(isLocalRequest) and slightly different code.

This patch fixes kio compilation by moving the two isLocalRequest functions 
into the corresponding private classes.


Diffs
-

  kio/kio/accessmanager.cpp 03b75898b0fcc6b47518fde8a8b3afc23a1a677f 
  kio/kio/accessmanagerreply_p.h 408b5331c999633f4f5d603a70cb419678249a7e 
  kio/kio/accessmanagerreply_p.cpp ccc7474799734b91112d70dc81945b8fe9b9f96c 

Diff: http://git.reviewboard.kde.org/r/101277/diff


Testing
---

Compilation of kdelibs/kio with and without final. Didn't try installing or 
running.
Other parts of kdelibs still don't work with final.


Thanks,

Nicolas

Re: Initial merge (was: Re: Merge or Cherry-Pick?)

[Nicolas Alvarez]

Thiago Macieira wrote:
> On Friday, 4 de February de 2011 15:18:58 Nicolas Alvarez wrote:
>> Johannes Sixt wrote:
>> > (1) All back- and forward-porting was complete when SVN went
>> > read-only.
>> 
>> IMHO this is not a safe assumption. As I said before, I found a missing
>> forward-port in kdeplasma-addons, which is a 'small' repository. I see a
>> higher chance of a missing forward port among the 200+ 4.6 revisions in
>> kdelibs.
> 
> Those missing forward-ports need to be forward-ported anyway. The merging
> doesn't change that.
> 
> Whoever forgot to do forward-ports should be doing it *yesterday*.

I know forward-ports should be done anyway and asap. But until they aren't 
done, we can't do the 4.6 merge.

-- 
Nicolas

Re: Initial merge (was: Re: Merge or Cherry-Pick?)

[Nicolas Alvarez]

Johannes Sixt wrote:
> Am 2/3/2011 13:04, schrieb Johannes Sixt:
>> Before anybody begins to work in this way, someone with sufficient
>> knowlege must introduce the first real merge of the 4.6 branch into the
>> master branch. The conflicts must be resolved; or it is possible to punt
>> by using -s ours.
>> 
>> As long as this merge did not happen, anyone who wants to use the merge
>> workflow is at a loss, unfortunately.
> 
> I tried to do the initial merges in kdelibs, kde-runtime, kde-baseapps,
> and kde-workspace yesterday, and they turned out to be rather simple with
> a surprisingly trivial result. Fast-forward to 5. below if you want to
> know what it is.
> 
> The simplicity results from two assumptions:
> 
> (1) All back- and forward-porting was complete when SVN went
> read-only.

IMHO this is not a safe assumption. As I said before, I found a missing 
forward-port in kdeplasma-addons, which is a 'small' repository. I see a 
higher chance of a missing forward port among the 200+ 4.6 revisions in 
kdelibs.

-- 
Nicolas

Re: Merge or Cherry-Pick?

[Nicolas Alvarez]

Johannes Sixt wrote:
> Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa:
>> So I git cloned KDE/4.6 into some local branch (git checkout KDE/4.6; git
>> checkout -b toolbuttons), then fix, then test.
>> 
>> Now I want to merge to the KDE/4.6 branch; thats easy.
>> 
>> Then I want to merge to master (or to some local branch cloned from
>> master and then from there to master). As already announced in this
>> thread, this results in tons of conflicts (notably many .desktop files).
> 
> Before anybody begins to work in this way, someone with sufficient
> knowlege must introduce the first real merge of the 4.6 branch into the
> master branch. The conflicts must be resolved; or it is possible to punt
> by using -s ours.

I did this in kdeplasma-addons yesterday. I actually found a bug fix in 4.6 
that hadn't been merged into master, and a merge -s ours would have lost it; 
so I had to cherry-pick that one first.

To do it in the other repos, we would have to carefully check if there is 
any commit missing forward-port; and that's very time-consuming since 
there's lots of 4.6 changes in eg. kdelibs.

-- 
Nicolas

Re: kdelibs, kdebase moving to Git this Saturday

[Nicolas Alvarez]

Torgny Nyblom wrote:
> On Friday 28 January 2011 16.13.31 Nicolas Alvarez wrote:
>> The kdebase-runtime repository is currently 260MB, and kdebase-workspace
>> is 300MB. Apparently it's because of wallpapers and icons, either in the
>> current revision or in the past.
>> 
>> Removing wallpapers from kdebase-workspace would bring it down to 190MB
>> (100MB less). I haven't yet tested kdebase-runtime.
> 
> Is that with all wallpapers removed or only those in trunk?

It's with wallpapers completely removed from the repository (trunk, 
branches, tags, etc; there are no wallpaper blob objects).

I don't think we'd get any significant savings if wallpapers stay in 
branches...

-- 
Nicolas

Re: kdelibs, kdebase moving to Git this Saturday

[Nicolas Alvarez]

Nicolás Alvarez wrote:
> Ian Monroe wrote:
>> git://anongit.kde.org/scratch/nalvarez/kdelibs-convtest
>> git://anongit.kde.org/scratch/ianmonroe/kdebase-apps
>> git://anongit.kde.org/scratch/ianmonroe/kdebase-runtime
>> git://anongit.kde.org/scratch/ianmonroe/kdebase-workspace
>> git://anongit.kde.org/scratch/ianmonroe/konsole
> 
> Some problems were found in the kdelibs repository, mostly in old tags.
> r411963 is particularly good at messing up conversions...
> 
> The new repository (shall we call it RC2?) is in:
> 
> git://anongit.kde.org/scratch/ianmonroe/kdelibs-trial
> 
> kdebase repos seem to have similar problems; new git repos will be up
> once the rules are fixed.
> 
> Please, help review the repositories before migration! Unlike KDE
> software, here we won't have point releases to fix bugs later :)

The kdebase repositories have been re-pushed with tags and branches fixed. 
Same URLs as before.

-- 
Nicolas

Re: kdelibs, kdebase moving to Git this Saturday

[Nicolas Alvarez]

Ian Monroe wrote:
> For up to one week if someone finds a major problem in the history a
> re-push will be considered. After that we'll just live with it.
> 
> ...but far better would be for any problem to be found now. Please
> note that the repo names are not the final ones (they will be konsole,
> kde-baseapps, kde-workspace, kde-runtime, kdelibs).
> 
> git://anongit.kde.org/scratch/nalvarez/kdelibs-convtest
> git://anongit.kde.org/scratch/ianmonroe/kdebase-apps
> git://anongit.kde.org/scratch/ianmonroe/kdebase-runtime
> git://anongit.kde.org/scratch/ianmonroe/kdebase-workspace
> git://anongit.kde.org/scratch/ianmonroe/konsole

The kdebase-runtime repository is currently 260MB, and kdebase-workspace
is 300MB. Apparently it's because of wallpapers and icons, either in the 
current revision or in the past.

Removing wallpapers from kdebase-workspace would bring it down to 190MB 
(100MB less). I haven't yet tested kdebase-runtime.

What do you all think of removing wallpapers from these git repositories?
We could put them in a separate git repository, or even keep them in SVN.

-- 
Nicolas

Re: kdelibs, kdebase moving to Git this Saturday

[Nicolas Alvarez]

John Tapsell wrote:
> 2011/1/27 Nicolás Alvarez :
>> Please, help review the repositories before migration! Unlike KDE
>> software, here we won't have point releases to fix bugs later :)
> 
> I have quite a few commits in kdebase-workspace with the commit message:
> 
> SVN_SILENT:
> Do blahblah
> 
> and
> 
> GUI:
> do blah blah
> 
> 
> Since git places a high important on the very first line, could we
> mangle these into  "SVN_SILENT: Do blahblah"  and "GUI: do blah blah"
>  ?
> 
> So check if the first line contains only a keyword, and if so combine
> with next line?

It's technically possible, but it may involve a lot of manual work.

And many people (not including me) disagree with this kind of history edits; 
for example: " IMHO the objective is to import the SVN history 
faithfully and accurately"

-- 
Nicolas