Re: 4.13.3 tarballs are available for packagers
On Monday 14 July 2014 21.01.41 Torgny Nyblom wrote: Sure. First thing tomorrow. baloo is now respun. commit 918ec9d265c315bed4313963c3be58fd748fe26a sha256: c7467bf518dc23e319b581dbc1dff84cd8d0b03516a1d25bde0aa0cd7bbad043 /Regards Torgny /Cheers Torgny div Original message /divdivFrom: Albert Astals Cid aa...@kde.org /divdivDate:2014/07/14 19:32 (GMT+01:00) /divdivTo: Vishesh Handa vha...@kde.org /divdivCc: kde-de...@kde.org,kde-packager kde-packa...@kde.org,KDE release coordination release-t...@kde.org,kdelibs kde-core-devel@kde.org,torgny nyblom nyb...@kde.org /divdivSubject: Re: 4.13.3 tarballs are available for packagers /divdiv /divEl Diumenge, 13 de juliol de 2014, a les 23:52:21, Vishesh Handa va escriure: On Sat, Jul 12, 2014 at 8:53 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 12 de juliol de 2014, a les 20:11:35, Vishesh Handa va escriure: On Sat, Jul 12, 2014 at 5:28 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 12 de juliol de 2014, a les 17:24:30, Albert Astals Cid va escriure: Note that baloo unit tests are not passing and if it's not fixed (+ package respun) before tuesday it won't be part of the release. I mean http://build.kde.org/view/KDE%20SC%20stable/job/baloo_stable/ is not green. I'm really not sure why the test is failing. It is passing perfectly on multiple machines that I've tried it out. It just seems to be jenkins. I'll try to figure it out, otherwise I'll disable the test. I specially wrote the test when I was fixing a bug for 4.13.3. Disabling the test doesn't really seem like a good idea. Can't you just add more debug to see what's wrong? Test fixed. It was a problem with the test, not with the code. Awesome, Torgny can you respin the baloo tarball? Cheers, Albert
Re: 4.13.3 tarballs are available for packagers
Sure. First thing tomorrow. /Cheers Torgny div Original message /divdivFrom: Albert Astals Cid aa...@kde.org /divdivDate:2014/07/14 19:32 (GMT+01:00) /divdivTo: Vishesh Handa vha...@kde.org /divdivCc: kde-de...@kde.org,kde-packager kde-packa...@kde.org,KDE release coordination release-t...@kde.org,kdelibs kde-core-devel@kde.org,torgny nyblom nyb...@kde.org /divdivSubject: Re: 4.13.3 tarballs are available for packagers /divdiv /divEl Diumenge, 13 de juliol de 2014, a les 23:52:21, Vishesh Handa va escriure: On Sat, Jul 12, 2014 at 8:53 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 12 de juliol de 2014, a les 20:11:35, Vishesh Handa va escriure: On Sat, Jul 12, 2014 at 5:28 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 12 de juliol de 2014, a les 17:24:30, Albert Astals Cid va escriure: Note that baloo unit tests are not passing and if it's not fixed (+ package respun) before tuesday it won't be part of the release. I mean http://build.kde.org/view/KDE%20SC%20stable/job/baloo_stable/ is not green. I'm really not sure why the test is failing. It is passing perfectly on multiple machines that I've tried it out. It just seems to be jenkins. I'll try to figure it out, otherwise I'll disable the test. I specially wrote the test when I was fixing a bug for 4.13.3. Disabling the test doesn't really seem like a good idea. Can't you just add more debug to see what's wrong? Test fixed. It was a problem with the test, not with the code. Awesome, Torgny can you respin the baloo tarball? Cheers, Albert
Re: Less time for KDE... :-)
On Saturday 23 November 2013 17.58.31 Alexander Neundorf wrote: Hi, for very happy personal reasons (since Tuesday, named David :-) ) I'll have significantly less time for KDE in the future. From one who know what it's like, your life will never be the same :) Congratulations!! /Torgny
Dependency to unreleased versions
Hi, What is the policy of depending on unreleased libraries? And is that written down somewhere? Reason I'm asking is this commit http://build.kde.org/view/FAILED/job/libkdcraw_master/83/changes#detail1 It introduces a dependency to libraw 0.16 witch is not released. /Regards Torgny
Re: Proposal for branching policy towards KF5
On Friday 26 July 2013 23.53.07 Michael Pyne wrote: On Fri, July 26, 2013 21:11:21 Torgny Nyblom wrote: On Thursday 25 July 2013 18.24.50 Michael Pyne wrote: The 'logical module groups' might play a role in the release process after a release is done, but shouldn't have any further role for tagging that I can see. i18n is covered above. Wouldn't this be nice to have as the source of branch info for the releases? One place to have this information instead of duplicate it for each tool/user? I think I see what you're talking about, but the release team essentially just make their own branch already, make their tags, that's it. Things are generally not tagged directly from master or any other development branch. Not quite :), when we make a release the tags are put on the release branch, i.e. KDE/4.10 for the last stable release. The release branch/tag is a thing of the past that was used in the SVN days. The only release team only thing is that we keep a list of modules/branches that we should tag modules from. Since this will be the same as the stable branch I see no reason why we should hide this information in the release tools repo. /Regards Torgny
Re: Proposal for branching policy towards KF5
On Thursday 25 July 2013 18.24.50 Michael Pyne wrote: On Thu, July 25, 2013 22:44:47 Albert Astals Cid wrote: El Dimecres, 24 de juliol de 2013, a les 23:05:55, Michael Pyne va escriure: On Fri, July 19, 2013 00:21:21 you wrote: After more live discussion with Sebas and Marco plus Aaron over a video chat, we came up with the following setup for the workspace repos (*) : - the development branch for their next feature release (based on Qt5/KF5) will be master. - *before* this happens, however, kdesrc-build / kde-build-metadata / projects.kde.org will need to be improved so that tools (kdesrc-build and possibly build.kde.org) can automatically select the latest Qt4-based branch (i.e. master everywhere and 4.11 for the workspace repos), on demand. This would also be the opportunity to implement latest *stable* branch which is 4.11 for most modules right now, but could be at some point 4.12 for most and 4.11 for workspace repos. Adding a similar generic selection for qt5/kf5, we would end up giving 3 options to people who compile from sources: stable, latest-qt4, or qt5/kf5- based. Back on topic, I have made an initial draft specification [1] for what this logical module group layer would look like. In addition, there is a sample JSON file in the kde-build-metadata git repository, called logical-module-structure that one can view to get a feel for the proposed syntax/semantics. snip A point of concern is that currently we already have a concept similar to this, for i18n. It's possible to specify in the projects.kde.org management interface a stable or trunk branch for translation purposes. I don't know the translation infrastructure well enough to see how this proposal would impact that feature; I assume we'd want to move scripty ( friends) over to using this at some point if we go through with it, but it's probably easy enough to keep both techniques on whatever release checklist we're using now. [I18N_HAT] I'd appreciate if you guys decide on something :D Not so long ago we had to write support for the projects.kde.org branches thing when we already had our nice set of scripts and now you say we'll have to build support for something different? It's good that we never removed our internal scripts and they are the authoritative source, that way removing the projects.kde.org support is trivial :D [/I18N_HAT] Well it would certainly be possible to *keep* support for whatever you're doing now with projects.kde.org, that isn't going away at this point. But since the concept is complementary, it would make sense to try to end up on one solution. At least this way it should be easier to fixup the branches for groups of modules at a time! ;) I'm not familiar with the i18n scripts at this point but I would volunteer to help with any needed porting. At this point I think this still needs a green light from the release team, though. They are now CC'ed for review. One clarification I should make is that I also received a recommendation to investigate migrating our current dependency data into this new JSON file if possible. You mean something like kde-build-metadata? Neither i18n nor releasing uses that file. Kind of (dependency data is one part of kde-build-metadata). It is true that neither requires dependency info. In the event, some prototyping of the result of making *all* of our deps go in the file is rather unsatisfactory so I'll be dropping that for now (the hard work is already done in case we decide to investigate later though). Basically from release I don't see how that affects us, we use the data from the release-tools module that is de-coupled from what you mention, no? dependency-data would not affect you at all. The 'logical module groups' might play a role in the release process after a release is done, but shouldn't have any further role for tagging that I can see. i18n is covered above. Wouldn't this be nice to have as the source of branch info for the releases? One place to have this information instead of duplicate it for each tool/user? /Regards Torgny Regards, - Michael Pyne
Re: Proposed adjustments to our release cycles
(Missed k-c-d) On Monday 18 June 2012 19.08.33 Albert Astals Cid wrote: El Dilluns, 18 de juny de 2012, a les 06:36:33, Martin Gräßlin va escriure: On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote: My concerns: * Need more people to do the tarball packaging/releasing (since if you propose to release that often you can't expect the same person to be doing packages almost weekly or byweekly given the release dates won't probably align) I would say we need proper Jenkins support for that. It must be as simple as clicking one button to have the tarball fall out of the CI system and already know whether it compiles or not. This is cool, i totally support that, just don't see it there, do we have any volunteer for the work? I'm working on it websites/build-kde-org development branch Here are the scripts that are supposed to be used for the new Jenkins install that is cooking. Together with either the traditional packaging scripts or the new that Allen has been working on the plan is to allow packaging to be done automatically and periodically. Ideally each package will then be the base of a build + test run. /Regards Torgny
Review Request: Add missing lib and include path
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103148/ --- Review request for kdelibs. Description --- Fixes build errors due to missing ref to kcoreaddons and a missing include path Diffs - kde3support/tests/CMakeLists.txt c015c6d kdecore/tests/CMakeLists.txt 2d94d6a kdeui/sonnet/tests/CMakeLists.txt 8a5c1f4 kdeui/tests/CMakeLists.txt d71faa1 kdeui/tests/kconfig_compiler/CMakeLists.txt 28e916f kio/tests/CMakeLists.txt 77552ed kioslave/http/kcookiejar/tests/CMakeLists.txt f436958 kioslave/http/tests/CMakeLists.txt 697f1d7 kjs/api/CMakeLists.txt ff1726d knewstuff/tests/CMakeLists.txt c3eb5e8 knotify/tests/CMakeLists.txt ce42557 kparts/tests/CMakeLists.txt d283970 kpty/tests/CMakeLists.txt d3eee12 kross/qts/CMakeLists.txt 640d027 kross/test/CMakeLists.txt b82c01b kunitconversion/tests/CMakeLists.txt 6938d3a nepomuk/test/CMakeLists.txt 177cfab tier1/libkarchive/autotests/CMakeLists.txt 679a3e0 tier2/sonnet/core/tests/CMakeLists.txt 208593a Diff: http://git.reviewboard.kde.org/r/103148/diff/diff Testing --- Builds ok Thanks, Torgny Nyblom
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Tuesday 11 October 2011 21.11.03 Martin Gräßlin wrote: On Tuesday 11 October 2011 20:12:39 Torgny Nyblom wrote: [...] But you also said that the screensaver without locking was going away in 4.9. This is what I'm against. As Thomas wrote you will always be able to run any animations you want. What will go away is the support for xscreensavers when the screen is locked. But we will make it possible to integrate QML based screensavers into the screen locker. Then all my objections are gone. Thanks for the clarification. /Regards Torgny
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Tuesday 11 October 2011 20.54.42 Thomas Lübking wrote: Am Tue, 11 Oct 2011 18:02:32 +0200 schrieb Torgny Nyblom nyb...@kde.org: Screensaver is bling only No, screensaver hacks are bling only, a screensaver is a software relic. (Semantics) The key aspect is when and why is there eye-candy. You can still run all scsreensavers to look at them, they're just ordinary single window applications. You can even run them fullscreen. No problem. BUT: running them automatically because you're away and the system is idle is simply not a justifiable (anymore), Why? I like this feature. and that was the concept of a screensaver which was just 10 years ago, but is no way today Agreed. - and on battery driven systems actually must be tagged stupid, sorry. But on non battery powered devices? /Regards Torgny
Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Tuesday 11 October 2011 15.55.15 you wrote: Am Tue, 11 Oct 2011 15:33:39 +0200 schrieb Torgny Nyblom nyb...@kde.org: Does this mean that I will be focred to use a screensaver with password unlock? If so why is that not a vaild usecase? It's what I use at home all the time. Why that? xdpms saves you power (and screen, if that would be any necessary) and neither the last generation of CRTs nor any consumer quality tft burns in - the only trouble makers would be plasma (sic! ;-) TVs which still suck so much power that you should really turn them off while they're not in use. Locking the screen is a valid requirement, but just rendering some fancy stuff (while you're not there anyway) is pointless energy (what today often means battery) wasting. By this argument the entire screensaver and all effects should go not just the lockless screensaver. In my oppinion the screensaver mode is a separate usecase then the locked screen one. Screensaver is bling only, where as the lock is for when you leave the computer in an untrusted environment and this should be active from when I leave, not after x min. /Regards Torgny
Re: Screensaver to be or not to be (was: Re: Security Audit Request for Screenlocker Branch)
On Tuesday 11 October 2011 19.52.36 Martin Gräßlin wrote: On Tuesday 11 October 2011 18:02:32 Torgny Nyblom wrote: On Tuesday 11 October 2011 15.55.15 you wrote: Am Tue, 11 Oct 2011 15:33:39 +0200 schrieb Torgny Nyblom nyb...@kde.org: Does this mean that I will be focred to use a screensaver with password unlock? If so why is that not a vaild usecase? It's what I use at home all the time. Why that? xdpms saves you power (and screen, if that would be any necessary) and neither the last generation of CRTs nor any consumer quality tft burns in - the only trouble makers would be plasma (sic! ;-) TVs which still suck so much power that you should really turn them off while they're not in use. Locking the screen is a valid requirement, but just rendering some fancy stuff (while you're not there anyway) is pointless energy (what today often means battery) wasting. By this argument the entire screensaver and all effects should go not just the lockless screensaver. Sorry, but effects are not about bling but about improving the user experience. Or do you consider present windows being bling? I consider most effects being bling yes, with that said I like it and appreciate it but still most effects add no real productive value. In my oppinion the screensaver mode is a separate usecase then the locked screen one. Screensaver is bling only, where as the lock is for when you leave the computer in an untrusted environment and this should be active from when I leave, not after x min. Yes screen saver/animation and screen locker are completely different things. That is exactly what this is about. I worked on a new screen locker which separates the animation and the locker. Therefore as I wrote having just an animation is a non-valid use case for the locker. But you also said that the screensaver without locking was going away in 4.9. This is what I'm against. I fully agree that the locker is and should be separated from the animation. /Regards Torgny
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 20.33.06 Andras Mantia wrote: On Saturday, October 01, 2011 16:27:48 Dario Freddi wrote: Hello all, and sorry for cross-posting. [...] I can't comment on activities, never used them, nor feel the need to use them. So this sounds more like the power management applet would force me to create and use activites. What I can say that I use the selection combo between the different power management schemes from time to time, as I can do the same thing (e.g developing so not anything like now I develop and then switch to mail reading/watching a movie), but depending on the battery status and the known time until I can recharge the battery, I can tweak the power management setting. There is no way any software could guess when will I be able to recharge my battery. +1 Please do not force me to use activites to set power management options. Also please do not remove the possibility to change how a certain state should look like. So far I've always changed the on battery profile. /Regards Torgny Nyblom signature.asc Description: This is a digitally signed message part.
Re: The future of Power Management - together with Activities
On Saturday 01 October 2011 21.02.19 Dario Freddi wrote: [...] Also please do not remove the possibility to change how a certain state should look like. So far I've always changed the on battery profile. I think there is a certain misunderstanding here. I have said the possibility of creating NEW profiles will be removed. Profile switching upon battery events will still be retained and will be looking exactly as it looks today. Ok, so the possibility of changing settings of the preset profiles will stay? -- /Regards Torgny Nyblom signature.asc Description: This is a digitally signed message part.
Re: Renaming X.Y branches to KDE/X.Y
On Thursday 08 September 2011 20.37.59 Jeremy Whiting wrote: Hello all, Sorry for the cross post, but this concerns many and I want to make sure everyone is aware. [...] Thus I propose we agree to use KDE/X.Y for official kde release branches going forward. In one week (Sep 15th) perform the required changes to existing repositories. 1 kdegraphics (mobipocket and okular) 2 kdeedu 3 kdeutils 4 kdepim Done 5 kdepim-runtime Done 6 kdeplasma-addons 7 kdepimlibs Done [...] In most cases, anyone with a clone without tracking branches will need to do this: git remote update git remote prune origin (or whatever they named the remote) /Regards Torgny signature.asc Description: This is a digitally signed message part.
Re: Renaming X.Y branches to KDE/X.Y
On Friday 16 September 2011 15.09.49 Albert Astals Cid wrote: [...] Please update the stable i18n branch settings in projects.kde.org Done, sorry for forgetting that. /Torgny signature.asc Description: This is a digitally signed message part.
Re: git workflow draft
On Tue, 23 Aug 2011 08:15:50 +0200, Aaron J. Seigo wrote: On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote: Was this decided upon at some point? I got conflicting stories fromsysadmin and other developers. Yesterday after migrating kdeaccessibilityto git I was asked by a sysadmin to rename the X.Y branches to KDE/X.Y Ithink personally, i prefer the KDE/X.Y style as well; and as we haven't had more accidently pushes of X.Y branches as people have become accustomed to the git tools more, the original reason for suggesting to move away from KDE/X.Y to just X.Y seems to have gone away? My vote goes for the X.Y scheme as the repo is already under the KDE namespace. This was also the original scheme used that then was (accidentally ?) not followed when more modules joined. /Regards Torgny
Re: Where is kmix hidden?
On Friday 19 August 2011 20.54.21 Harald Sitter wrote: On Fri, Aug 19, 2011 at 6:54 PM, Lukas Appelhans l.appelh...@gmx.de wrote: I guess there were no efforts yet from the kdemultimedia team to make the move. I did not realize we had to take care of the move seems a bit inconvenient. Who should do it then? All the modules that have moved has done it them self, some with hired help some without. If you need any assistance please drop by #kde-git or send a mail to kde-scm- interest. /Regards Torgny signature.asc Description: This is a digitally signed message part.
Re: Summary from Buildsystem BoF at Desktop Summit
On Monday 15 August 2011 23.31.26 Alexander Neundorf wrote: [...] - 8) Testing - We shortly discussed testing, continuous builds and nightly builds. I hope Volker (or somebody) can write a better summary. Volker has a prototype for easily running VM-based builds on Linux-machines, which contribute their results to a cdash dashboard. Marcus introduced us to cdash@home, which has a similar purpose, i.e. make it very easy for people to contribute their machine as a continuous-build host to a project. It seems there is growing interest in establishing structured testing for KDE, also highlighted by Till's talk The limits of portability. More details to come... Don't forget that there is a trial up and running on http://build.kde.org This is a Jenkins installation that is currently triggered by the commit hooks and do continious build + test of kdelibs (KDE/4.7), kde-runtime (master), kdepimlibs (master), kdepim (master) and kdepim-runtime (master). The plan is to expand this to all (former) modules and atleast the stable and master branches. Any feedback regarding this site would be appreciated. /Regards Torgny signature.asc Description: This is a digitally signed message part.
Re: Summary from Buildsystem BoF at Desktop Summit
On Tuesday 16 August 2011 19.48.39 Alexander Neundorf wrote: [...] There are currently several parties interested in running builds/test. There is you working on Jenkins, Volker is working on setting up virtual machines so users can do builds in a seti@home style, and Marcus is trying to see how cdash@home could fit for KDE. It would be good to coordinate the plans of the different people in some way. Should we do this on kde-buildsystem or somewhere else ? Anywhere is fine with me, but as we already have started (sort of) in kde- buildsystem lets stay there. (My view on the below might be biased as I'm pushing for the CI solution) Do we want to set up machines which build everythings regularly ? I don't realy see the point of this if (almost) every commit is built. Then those machines would only build stuff that is already built elsewhere. It is essentially a continious setup with a big polling window. Or do we want to find users interested in specific applications or libs setting up builds just for this one part ? The issue with this as I see it would be to ensure that they all use a valid environment. How do we want to deal with covering different build options ? Idealy every combination should be checked, but in reality I don't know. It will be quite hard to descide what combinations to try as the number of possibilities are almost endless. And how about the different operating systems we support ? Best case scenario would be a farm of machines (VMs?) that are triggered by a commit and build on every supported platform. Sort of parallell CI. Do we care more about fast turn around times for continuous builds and targeted email notifications (so I get an email really fast if I broke something), or are we more interested in getting complete builds done from time to time ? What is preventing both of these? A continious build machine will do a the equivivalent of a full build just that it does it in chunks. As for turnarond times, that depends on the participating HW and setups. There is some work to go as the state of our (at least the modules I've tried) unit tests are poor. /Regards Torgny signature.asc Description: This is a digitally signed message part.
Re: Review Request: New Date/Time Widgets in kdelibs/kdeui
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101575/#review5719 --- Any progress? - Torgny On June 10, 2011, 9:18 p.m., John Layt wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101575/ --- (Updated June 10, 2011, 9:18 p.m.) Review request for kdelibs, KDEPIM, KPhotoAlbum, Skrooge, Zanshin, Kevin Ottens, and David Jarvie. Summary --- [Sorry this is a post-commit review and took so long to remember to post. Bad coder, no cookie for you!] This review is for some new replacement widgets for the popular KDEPIM KDateEdit and KTimeEdit widgets which were copied into a number of other projects. These new widgets are clean rewrites (the original widgets have history back to KDE2 days) with slightly changed api but otherwise should replicate the same functionality with a couple of new features. They will be available for use by any apps using kdelibs 4.7. The 3 new widgets are: KDateComboBox: A date entry widget derived from KComboBox, the drop-down menu can display a date picker and list of fancy dates to choose from. The list of dates can be configured. KTimeComboBox: A time entry widget derived from KComboBox, the drop-down menu can display a list of times to choose from. The list of times can be configured. KDateTimeEdit: A KDateTime entry widget combining KDateComboBox and KTimeComboBox with optional combo's to select the calendar system and time spec as well. This widget should only be used if you want time spec aware data entry. All widgets can accept a null or invalid input, it is up to the coder to check for validity of input using isValid() if required. All feature options of the widgets can be configured. All widgets can optionally display a warning box on focus out if the entry is invalid. All widgets can be used in Qt Designer. I'm particularly looking for input on the api, and what QWidget event virtual methods I should be reimplementing to make the classes BIC future-proof. Diffs - kdeui/CMakeLists.txt 1e8b259 includes/KDateComboBox PRE-CREATION includes/KDateTimeEdit PRE-CREATION includes/KTimeComboBox PRE-CREATION includes/CMakeLists.txt 7a8bc5c kdeui/tests/CMakeLists.txt c7b8026 kdeui/tests/kdatecomboboxtest.h PRE-CREATION kdeui/tests/kdatecomboboxtest.cpp PRE-CREATION kdeui/tests/kdatetimeedittest.h PRE-CREATION kdeui/tests/kdatetimeedittest.cpp PRE-CREATION kdeui/tests/ktimecomboboxtest.h PRE-CREATION kdeui/tests/ktimecomboboxtest.cpp PRE-CREATION kdeui/widgets/kdatecombobox.h PRE-CREATION kdeui/widgets/kdatecombobox.cpp PRE-CREATION kdeui/widgets/kdatetimeedit.h PRE-CREATION kdeui/widgets/kdatetimeedit.cpp PRE-CREATION kdeui/widgets/kdatetimeedit.ui PRE-CREATION kdeui/widgets/ktimecombobox.h PRE-CREATION kdeui/widgets/ktimecombobox.cpp PRE-CREATION kdewidgets/kde.widgets 9040538 Diff: http://git.reviewboard.kde.org/r/101575/diff Testing --- Unit tests written for non-gui functionality. Gui functionality tested in Qt Designer. KDateTimeEdit still has a couple of minor bugs, but I didn't want to hold the review up any longer. Screenshots --- Qt Designer Preview http://git.reviewboard.kde.org/r/101575/s/180/ KDateComboBox http://git.reviewboard.kde.org/r/101575/s/181/ KTimeComboBox http://git.reviewboard.kde.org/r/101575/s/182/ Thanks, John
Re: KDE git workflow
On Wednesday 08 June 2011 19.03.01 Cornelius Schumacher wrote: As you already know, we have discussed the git workflow for KDE at the Platform 11 sprint, and have come up with a recommendation. Please find the full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow Local branches are always rebased, remote branches never When developing in a local branch, changes should always be rebased before pushing them to the remote origin. This keeps a simple linear history. Rebasing can be thought of as applying changes as patches to the latest version of the code. In case of conflicts they need to be adapted. So developers always patch against the latest version of the code. Remote branches are shared by multiple people. Rebasing them causes different people to have different versions of history, which causes conflicts, inconsistent and hard to understand states. So remote branches should never be rebased. Merging them properly also reflects that development actually happened in a side line. This part I fully agree with, however later in the example section it seems like rebasing should be done prior to review. Is the examples correct? /Regards Torgny
iceScrum (was Re: Qt5 - KDE5?)
On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote: we have already been putting together plans, including documenting them feature by feature in iceScrum For those of us who this is the first time we hear about icsscrum where is it, who can use it and for what? /Regards Torgny
Re: iceScrum (was Re: Qt5 - KDE5?)
On Thursday, May 12, 2011 14:38:57 Torgny Nyblom wrote: On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote: [...] Shaun gave the location; it's still experimental for us, though. We're using it for the next three months of plasma development, with a focus on Plasma Active issues, as a trial. If this works out well, we will find a more permanent home somewhere under the KDE infrastructure umbrella and open the invitation to use it to more people. If there is interest sooner, then perhaps someone can look into speeding up that timeline. Thanks (Aaron and Shaun) for that, I think that it look interesting and am looking forward to hear what your impressions are after this first sprint. If you think that it is good I would love to have an official KDE version running for us all to use. /Regards Torgny
Re: Git Feature Branch Naming Policy
On Tuesday 26 April 2011 15.52.18 John Layt wrote: Hi, Did anything come out from discussions on feature branch naming in git? With GSoC starting soon we'll be getting a lot of new feature branches and it would be nice if they were consistantly named to make them easy to find and manage. See http://community.kde.org/20110213_GitWorkflowAgenda#How_To_Handle_Topic_Bran ches for the original meeting notes. I'd prefer to see the gsoc branches under a common prefix in the main project repo rather than as personal branches or repos: origin/gsoc2011/subproject/branchname Why this long name with multiple namespaces, the branches should be deleted once merged so we won't have a collection of old soc branches around for long? /Regards Torgny
Re: [Kde-scm-interest] Re: libtagaro - kdereview [- kdegames]
On Thursday 21 April 2011 21.25.13 Ian Monroe wrote: On Thu, Apr 21, 2011 at 06:56, Stefan Majewsky stefan.majew...@googlemail.com wrote: Hi, what is the technical procedure for moving libtagaro.git to kdereview? I think sysadmins need be informed, and hope that those are reading here. Assuming that this goes well: I hereby propose to move libtagaro to the kdegames module after the usual review period. For the time being, because kdegames has not yet moved from SVN, this would create a module that is split between SVN and Git, but a similar situation exists with kdegraphics, so I hope this is not a problem. In any event, scm-interest is CCd if anyone wants to discuss this. This doesn't make sense to me. If you want to be part of kdegames, you should join it where it is. If I were you I would just hold off. It's way too confusing to split modules between VCS systems and I don't think it should be allowed (*cough* kdegraphics *cough*). +1 a module is a unit and should be treated as such even if the different apps are in different gits. /Regards Torgny
Re: [Kde-scm-interest] next steps with Git migration
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 people are tempted to call their local branch simply '4.6' and then they end up creating remote branches called '4.6' and its all rather confusing. And kdepim* never had this prefix. So it would make sense to simply drop it 'KDE/'. +1 from me /Regards Torgny
Re: kdelibs, kdebase moving to Git this Saturday
On Sunday 30 January 2011 14.38.17 Tom Albers wrote: - Original Message - On 1/30/2011 1:17 PM, Marco Martin wrote: in the runtime repository, the pics directory doesn't seem available, but the main CMakelist.txt still looks for it. kde-runtime is currently set read-only for that and other reasons, the conversion seems to be flawed. Unfortunately the guys writing the conversion script are in bed or afk right now. Additionally we've made kde-workspace read-only too, as #kwin found a missing file, which means we have a problem there too. I'ld like to ask everyone to check the repo's NOW, so the conversion people can have a full list of problems and we don't have to repush 3 times this week, but only once. enterprise branches missing from kdelibs /Regards Torgny
Re: kdelibs, kdebase moving to Git this Saturday
On Friday 28 January 2011 00.06.21 Nicolas Alvarez wrote: John Tapsell wrote: 2011/1/27 Nicolás Alvarez nicolas.alva...@gmail.com: 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: Sho_ IMHO the objective is to import the SVN history faithfully and accurately While I agree with Eike here, I think that in this case we can make an exception, however I do not like the idea of git-filter-branch. How about we simply rewrite the message in svn2git? /Regards Torgny
Re: kdelibs, kdebase moving to Git this Saturday
On Friday 28 January 2011 11.05.43 Johannes Sixt wrote: Am 1/28/2011 10:31, schrieb Torgny Nyblom: On Friday 28 January 2011 00.06.21 Nicolas Alvarez wrote: John Tapsell wrote: 2011/1/27 Nicolás Alvarez nicolas.alva...@gmail.com: 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 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: Sho_ IMHO the objective is to import the SVN history faithfully and accurately While I agree with Eike here, I think that in this case we can make an exception, however I do not like the idea of git-filter-branch. How about we simply rewrite the message in svn2git? Doesn't it operate with a git-fast-import stream? Wouldn't it just mean to flip a LF to a SP here and there? You wouldn't even have to change the byte-length of the commit messages. Well yes, but that would potentionaly give us messages like SVN_SILENT CCBUG: 123456 BUG: 123455 Fix foo bar. Wouldn't it be better to move these messages to the end of the message if there is a valid line to show. /Regards Torgny
Re: kdelibs, kdebase moving to Git this Saturday
On Friday 28 January 2011 16.13.31 Nicolas Alvarez wrote: 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. Is that with all wallpapers removed or only those in trunk? 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. From trunk - do what ever you like (my vote would be on git, but not neccecarily the same repo, to keep things together) From the hole repo - No way, not unless you also skip all branches and tags. /Regars Torgny
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
On Friday 21 January 2011 22.44.49 Ben Cooksley wrote: On Fri, Jan 21, 2011 at 11:17 AM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, January 20, 2011, Ben Cooksley wrote: Correct, it is Gerrit which is a more git based alternative to Reviewboard. http://code.google.com/p/gerrit/ does it have benefits over reviewboard? having just toyed with a bit after lunch today, it seems like it's useful to drive the entire integration workflow and not just smaller or one-off patches? if that's true, would gerrit be a workable replacement for reviewboard once everything is moved over to git? would it be integratable with identify.kde.org? Whilst Gerrit can integrate with KDE Identity (identity.kde.org) it has some pretty severe technical issues. Implementation wise, it runs it's own sshd implementation (written in Java) on a non standard port. It uses this to allow you to to publish review requests by pushing to it using a Git client. However, it implements the git protocol itself as well, and uses it to lie about the push being accepted by git, storing the changes in it's own database. In terms of accessing the sshd implementation it provides, it implements storage of SSH keys in it's own way as well, which means information has to be duplicated. In addition, when trying to test it myself, it's installation procedure failed using MySQL, I was only able to test it using it's integrated H2 database. This is completely unpalatable in terms of security and technical on KDE servers in my opinion as a sysadmin. Not sure what the others think of it however. We use it at work and my (somewhat clowdy after 6 months of paternety leave) memory of it was that it was quite unintuiative to work with and hard to understand what you were supposed to do when doing anything else then the normal pull/push thing. /Regards Torgny
Re: Suspending mailinglists due to lack of moderators.
On Sat, 1 Jan 2011 21:25:23 + (UTC) Tom Albers t...@kde.org wrote: [...] 40 kdelibs-bugs 28 plasma-bugs If no one who actually use these lists step up I can try and take them. /Torgny
