Re: Update needed to binary compatibility guide for Windows?
On Sun, Apr 13, 2014 at 6:36 PM, Michael Pyne wrote: > If it's true, do we want > to adopt a constraint on our handling of virtual functions in leaf classes > based on this? IMO we shouldn't worry about ABI on Windows. And not because "meh Windows", but since Microsoft breaks C++ ABI with every compiler release, which is quite frequently these days. In general C++ ABI stability just isn't a thing on Windows. And we are both the upstream and the downstream for the releases anyways. To that latter point, I guess really it matters what the KDE Windows team thinks. Ian
Re: Review Request 110529: more error handling in KIdleTime
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110529/ --- (Updated May 20, 2013, 3:25 a.m.) Review request for KDE Frameworks and kdelibs. Description --- more error handling in KIdleTime Segfaults could result in some rare circumstances Diffs - tier1/kidletime/src/xsyncbasedpoller.cpp e5f5328ae66d44e9224582ad759207bc42333d80 tier1/kidletime/src/kidletime.cpp fe18ee5d5c4525086a56d99e76e8ea0a4a92ce08 Diff: http://git.reviewboard.kde.org/r/110529/diff/ Testing --- Thanks, Ian Monroe
Re: Review Request 110042: Find Qt5 version of DBusMenuQt
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110042/#review32794 --- Ship it! Ship It! - Ian Monroe On April 16, 2013, 1:26 p.m., Frederik Gladhorn wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110042/ > --- > > (Updated April 16, 2013, 1:26 p.m.) > > > Review request for kdelibs. > > > Description > --- > > Build fix for dbusmenu qt5 changes. > This appends the 5 to include path and lib dir in the find module. > Also rename the whole thing to not conflict with the Qt 4 version. > > > Diffs > - > > CMakeLists.txt 00402d4 > cmake/modules/FindDBusMenuQt.cmake 5af70ef > cmake/modules/FindDBusMenuQt5.cmake PRE-CREATION > > Diff: http://git.reviewboard.kde.org/r/110042/diff/ > > > Testing > --- > > > Thanks, > > Frederik Gladhorn > >
Review Request 110529: more error handling in KIdleTime
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110529/ --- Review request for kdelibs. Description --- more error handling in KIdleTime Segfaults could result in some rare circumstances Diffs - tier1/kidletime/src/xsyncbasedpoller.cpp e5f5328ae66d44e9224582ad759207bc42333d80 tier1/kidletime/src/kidletime.cpp fe18ee5d5c4525086a56d99e76e8ea0a4a92ce08 Diff: http://git.reviewboard.kde.org/r/110529/diff/ Testing --- Thanks, Ian Monroe
Re: libtagaro -> kdereview [-> kdegames]
On Thu, Apr 21, 2011 at 06:56, Stefan Majewsky 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*). Ian
Re: 4.6 branches created in git again
On Mon, Mar 21, 2011 at 18:13, Alex Merry wrote: > On 21/03/11 20:17, Alexander Neundorf wrote: >> >> On Monday 21 March 2011, Ian Monroe wrote: >>> >>> Ben did add this block to his hook. Hooray. :) >>> >>> I'm thinking I should just go ahead and rename KDE/4.6 to 4.6 etc. >> >> Wasn't the conclusion more like going with the longer name, i.e. KDE/4.6 ? > > That's what I understood from the earlier discussion... I get why people like the prefix in theory, since I mean that's why I left it there. It looks nice. But in practice its obviously just been confusing. Even now that creating 4.6 is blocked, that just means its blocked and we won't notice when people struggle. Ian
Re: 4.6 branches created in git again
On Mon, Mar 21, 2011 at 15:17, Oswald Buddenhagen wrote: > On Mon, Mar 21, 2011 at 02:09:23PM -0500, Ian Monroe wrote: >> (making sure local branches track the correct remote branches, >> > nothing to be done here. really? you can't change what happens when you type 'git push' ? > only caveat: if people actually pushed different things to the branches, > we already have internal 4.6 forks. means you have to git merge the > dying branch before you dispose of it with the forced push. well yes, I've been doing this routinely since the git transition. Thats what this whole thread is about. Albert and others have noticed them quick enough that the forks have all been trivial. Ian
Re: 4.6 branches created in git again
On Mon, Mar 21, 2011 at 13:41, Oswald Buddenhagen wrote: > On Mon, Mar 21, 2011 at 05:57:03PM +, Tom Albers wrote: >> Though if it needs a reclone for everyone we need to pick a date and >> *communicate* it. Let's say this weekend? >> > reclone? hello? > git fetch > git checkout 4.6 Yea, ossi is correct even if snarky. :) Its not a big deal, but the rename will be a bit confusing for people. I'm going to play around with a test repo to figure out what commands will make it pain-free (making sure local branches track the correct remote branches, clean out deleted remote branches etc). And then email kcd+plasma+co and we can plan on making the switch this weekend. Ian
Re: 4.6 branches created in git again
On Sun, Mar 20, 2011 at 09:17, Ian Monroe wrote: > On Sun, Mar 20, 2011 at 09:09, Andreas Hartmetz wrote: >> On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: >>> Can you please be careful and do not create incorrectly 4.6 branches in >>> places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) >>> >>> Ian can you kill them? >>> >>> Albert >> >> Maybe we can go through with renaming the branches to n.m (without KDE/) >> prefix? >> Some repositories have the prefix, some don't, I think it doesn't make sense >> to >> have the prefix, and it was decided (by tossing a coin...) that the prefix >> should be removed. > > This would just cause more chaos until we block the creation of > whatever the non-favored naming scheme is. Ben did add this block to his hook. Hooray. :) I'm thinking I should just go ahead and rename KDE/4.6 to 4.6 etc. Ian
Re: 4.6 branches created in git again
On Sun, Mar 20, 2011 at 09:45, John Tapsell wrote: > Why do we let people create branches on the main git server anyway? > Well for feature branches its fine and kind of the point of git. There's no reason to let non-admins create version branches though. Ian
Re: 4.6 branches created in git again
On Sun, Mar 20, 2011 at 09:09, Andreas Hartmetz wrote: > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote: >> Can you please be careful and do not create incorrectly 4.6 branches in >> places where the branch is called KDE/4.6 (e.g kdelibs and kde-runtime) >> >> Ian can you kill them? >> >> Albert > > Maybe we can go through with renaming the branches to n.m (without KDE/) > prefix? > Some repositories have the prefix, some don't, I think it doesn't make sense > to > have the prefix, and it was decided (by tossing a coin...) that the prefix > should be removed. This would just cause more chaos until we block the creation of whatever the non-favored naming scheme is. Ian
Re: Review of the branch plasma/declarative in kdelibs
On Wed, Feb 23, 2011 at 05:54, Artur de Souza wrote: > Quoting Ian Monroe : >> >> I understand the need to provide to the QML developer stuff like i18n >> and a way to look up the location of icons, but I'm less sure having >> an actual QIcon/KIcon object. We're going to want to make use of Qt >> Components right? So until thats sorted out and we're able to >> "sub-class" (re-implement? javascript is weird) the Qt Components to >> add features like naming icons by name, wouldn't it make sense to just >> provide a method to query for resources like icons? And then let the >> QML developer use whatever the standard method is for displaying that >> icon. > > Just as a side note: Qt Components right now is just a specification of a > common API for widgets so there is nothing that we provide that could be > "subclassed" for example :) > > http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200 > > Qt Components will also not provide something like "naming icons by name". > In order to have this, KDE will need to provide a "image provider" that > would be able to return QPixmaps when one asks for an icon by the name. Yes ^^ that would make sense. > My tip would be: don't expect much coming from the project itself besides > the API that should be followed by developers implementing their platform's > widgets (this API can be extended though). So should there be a Qt.components.plasma? Its not really clear to me how Qt.components.meego would be inappropriate for Plasma though. Ian
Re: Review of the branch plasma/declarative in kdelibs
On Tue, Feb 22, 2011 at 14:41, Marco Martin wrote: > Hi all, > in kdelibs there is since some time a branch called plasma/declarative that > contains a new little library, that depends at the moment on kdecore and kdeui > (probably is possible to make it depend only from kdecore) that is meant to be > used in QML applications. > see http://mail.kde.org/pipermail/kde-mobile/2011-January/000301.html > there is still quite a bit of work to be done on it (mostly integrating a bit > of similar work that has been previously done in kdepim) and i plan to look > into it shortly. > > The target is to have it in experimental/ in kdelibs for 4.7, so I want to ask > for a review period for a subsequent merge I understand the need to provide to the QML developer stuff like i18n and a way to look up the location of icons, but I'm less sure having an actual QIcon/KIcon object. We're going to want to make use of Qt Components right? So until thats sorted out and we're able to "sub-class" (re-implement? javascript is weird) the Qt Components to add features like naming icons by name, wouldn't it make sense to just provide a method to query for resources like icons? And then let the QML developer use whatever the standard method is for displaying that icon. Thanks, Ian
Re: splitting up kdebase in git
2011/2/11 Ingo Klöcker : > On Friday 11 February 2011, Ian Monroe wrote: >> On Fri, Feb 11, 2011 at 14:06, Davide Bettio wrote: >> > Hi, >> > >> > Our default wallpapers used to be part of kdebase/workspace, but >> > during the git migration they've been removed from workspace due >> > the size of that directory. >> > Wallpapers can't be kept in a git repository because every time a >> > git repository is cloned all the history (including old >> > wallpapers) is cloned. So actually wallpapers are nowhere, should >> > we move wallpapers back to trunk/KDE/kdebase/workspace? >> >> Since that location in SVN is now a bit obscure, perhaps we should >> create a new SVN module called trunk/KDE/kdebase-wallpapers. > > kde-wallpapers? Because ... > > >> The context here is that: SVN is just better then Git at storing >> stuff like wallpapers, so I think we should consider it as the best >> longterm solution for big binary blobs. But wallpapers are required >> by kdebase-workspace. > > ... because kdebase/workspace became kde-workspace in Git. Well, so maybe kde-basewallpapers or kde-workspace-wallpapers then. Eg, PAINT IT GREEN!! :D Ian
Re: splitting up kdebase in git
On Fri, Feb 11, 2011 at 14:06, Davide Bettio wrote: > Hi, > > Our default wallpapers used to be part of kdebase/workspace, but during > the git migration they've been removed from workspace due the size of > that directory. > Wallpapers can't be kept in a git repository because every time a git > repository is cloned all the history (including old wallpapers) is > cloned. So actually wallpapers are nowhere, should we move wallpapers > back to trunk/KDE/kdebase/workspace? Since that location in SVN is now a bit obscure, perhaps we should create a new SVN module called trunk/KDE/kdebase-wallpapers. The context here is that: SVN is just better then Git at storing stuff like wallpapers, so I think we should consider it as the best longterm solution for big binary blobs. But wallpapers are required by kdebase-workspace. Ian
Re: A Qt replacement for KGlobal::ref and deref
On Thu, Feb 10, 2011 at 08:43, Thiago Macieira wrote: > Em quinta-feira, 10 de fevereiro de 2011, às 10:49:08, Stefan Majewsky > escreveu: >> On Thu, Feb 10, 2011 at 9:14 AM, Thiago Macieira wrote: >> > The correct way to solve this problem is to show another window >> > indicating that it is doing something and tell me what. We solve both >> > problems at once: there is a window open, so it's not yet a quit from >> > QCoreApplication's sense, and the user gets feedback. >> >> This assumption breaks in KDE because the progress is displayed by the >> kuiserver. > > But we're no longer talking about a KDE application. This is a Qt application, > with no access to kuiserver. But surely such functionality isn't unique to KDE? Having operations not associated with a QWidget that need to finish before an application closes seems pretty normal. David summed it up: "Instead of just counting open windows, you also count other things which ask to be counted - systray icon and jobs." Ian
Re: Merge or Cherry-Pick?
On Thu, Feb 10, 2011 at 04:31, Johannes Sixt wrote: > Am 2/10/2011 10:40, schrieb Ben Cooksley: >> On Thu, Feb 10, 2011 at 9:35 PM, Johannes Sixt wrote: >>> git push origin KDE/4.6 >> >> This is wrong, as it would try to push the content of HEAD (the merge >> of origin/KDE/4.6 into a checkout of origin/master) into KDE/4.6. > > Now you made me think about it. But, no, it is correct: > > git push remote branch > > is always a shorthand for > > git push remote branch:branch > > regardless of the push.default configuration setting. Therefore, the > command I gave pushes the local KDE/4.6 branch to the remote KDE/4.6 > branch, regardless what you have checked out. Which is why I think these shorthands are just really confusing and urge folks to just be explicit in everything. Certainly it isn't obvious that git push remote branch doesn't does the same thing regardless of what branch you have checked out. But if you did git push origin KDE/4.6:KDE/4.6 you know exactly what you are doing. But shorthand commands like `git pull --rebase` remain popular, and everyone confused. Ian
Re: git clone kde:kde-workspace hangs
On Mon, Feb 7, 2011 at 16:29, Martin Koller wrote: > On Sunday, 6. February 2011 23:54:07 Thiago Macieira wrote: >> On Sunday, 6 de February de 2011 16:48:21 Shaun Reich wrote: >> > On Sun, Feb 6, 2011 at 4:30 PM, Martin Koller wrote: >> > > Hi, >> > > >> > > I've tried already several times today to get a clone of kde-workspace >> > > and it always gets stuck at about 10-15% >> > > >> > > What can I do ? >> > >> > You can try using the tarball form on project.kde.org, for now (no idea why >> > it hangs up). at least then you can resume it. >> >> Note that the git clone/fetch/push percentage is by number of objects, not >> size. I have tried cloning kde-workspace now and it worked fine, but I did >> notice a slowdown around 14-15%. My guess is that there are some big objects >> being transferred. > > Thanks for the hint, but in my case my internet connection did not transfer > anything > during this hang (no LED activity on my router) even for 10 minutes or so ... > Nevertheless, I've downloaded the tarball for now. Its not a "tarball for now". It should have a script that changes it into a complete clone. It's certainly the best way to download new repos if your Internet connection is at all dubious. Ian
Re: Merge or Cherry-Pick?
2011/2/8 Nicolás Alvarez : > On 03/02/2011, Johannes Sixt wrote: >> Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa: >> 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. >> >>> Or should I give up and cherry-pick ? (I'd really like not to). >> >> My recommendation: Keep the fix in 4.6 only for the moment. Just wait >> until the initial merge has happened - and lets hope (HOPE BIG TIME) that >> the person doing that merge knows what s/he is doing! > > I have now merged 4.6 into master in kde-workspace. Great Nicolás. This will be much easier with the 4.7 branch! Ian
Re: Merge or Cherry-Pick?
> On Wednesday 19 January 2011, Ian Monroe wrote: >> > Can somebody please add a simple step-by-step howto, what I have to do >> > with identity.kde.org, projects.kde.org and git.kde.org, how the git >> > push/merge/branching policy is for KDE, etc. If there are existing blog >> > articles about this, please add links to them in a good visible place. >> >> There is no push/merge/branching policy for KDE. Different projects >> will likely do their own thing. For the time being its just the >> SVN-style development translated to Git. > > This looks to me like "do what you want, there is no policy". FWIW I thought the question was regarding branch policies (eg the release schedule with code freezes), not the technicalities of how to do merges between branches. I suppose the answer would be the same, but I was confused why you thought the release schedule system needed to be shaken up post-haste. :) Ian
Re: proposal: remove KTextEditor interface from kdelibs repository
On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo wrote: >[snip] > oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of "sideways" dependency wouldn't exist. Actually splitting up repos is the easy and less interesting part overall. Ian
next steps with Git migration
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 major issues will be addressed shortly (kde-runtime, kdelibs enterprise branches), there are some issues that we need to handle still. *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/'. *Bero (of Ark Linux) pointed out to me that Konsole is in the 4.6 branch of kde-baseapps, and that the Konsole repo has its own 4.6 branch. This might just be a case where things need to be removed from places where it doesn't belong or it should be communicated. *Kate & Git. Precisely where it lives and where packagers should build from needs to be clearly communicated (removing it from repos where its not developed is a great way to communicate this!). This should probably be its own thread though. :) Ian
Re: kdelibs, kdebase moving to Git this Saturday
On Sun, Jan 30, 2011 at 08:58, Torgny Nyblom wrote: > 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 Sorry about this & thanks for pointing it out. We have done an identical conversion + branches and this should be available tonight or tomorrow morning. I'll push it into my scratch space, and let you push the branches it into kdelibs under whatever naming scheme you want. :) Ian
Re: kdelibs, kdebase moving to Git this Saturday
On Fri, Jan 28, 2011 at 05:27, Johannes Sixt wrote: > Am 1/28/2011 12:19, schrieb Torgny Nyblom: >> On Friday 28 January 2011 11.05.43 Johannes Sixt wrote: >>> 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. > > That would be much better, of course. I just tried to help find a > low-hanging-fruit solution. Well it was always too late for any solution, conversion is tomorrow. Ian
kdelibs, kdebase moving to Git this Saturday
The basic schedule will be that sometime on Saturday the repos listed in the subject will be made read-only, we'll make the conversion and upload them to git.kde.org. The subversion directories will be emptied and replaced with a README. *Both* the 4.6 and trunk branches are moving. 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 Thanks, Ian Monroe
Re: [PATCH] Re: KDE 4.6.0: go or no go?
On Thu, Jan 20, 2011 at 08:18, Sebastian Trüg wrote: > This patch does in no way solve the issue. I'm not sure what the release team is supposed to do with this statement. What do you think of 246678 and the 4.6.0 release? Ian
Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
2011/1/19 Alexander Neundorf : > Hi, > > now that it's getting serious, can somebody who is working on the git > migration, *please* take care and write proper documentation on > techbase.kde.org for git dummies ? > > http://techbase.kde.org/Development/Tutorials/Git , which is the first google > result, and looks like a gateway page, has a "Getting started" section, the > only link there which looks not outdated is the one to the git.kde.org > manual. > > http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for somebody > who knows how to use git for KDE, but not for me. Maybe try this out first, it looks straightforward and the topic list is comprehensive: http://gitimmersion.com > Can somebody please add a simple step-by-step howto, what I have to do with > identity.kde.org, projects.kde.org and git.kde.org, how the git > push/merge/branching policy is for KDE, etc. If there are existing blog > articles about this, please add links to them in a good visible place. There is no push/merge/branching policy for KDE. Different projects will likely do their own thing. For the time being its just the SVN-style development translated to Git. > Sorry if such documentation already exists and I just didn't find it. > > For CMake, which moved to git last spring, such a wiki page exists: > http://www.cmake.org/Wiki/CMake/Git , which was mostly good enough for git > dummies as me. I'd really like if somebody would write something similar for > KDE. I don't want to discourage anyone finishing the KDE-spin of the "intro to git" documentation, but there are tons of generic git docs out there and so far we don't have much KDE-specific advice to give. Like most of the cmake docs are actually about their workflow, not really git. Everyone should really pay attention to this though: http://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes Will save you a lot of time. :) Ian
kdebindings 4.7 was modularized and has now moved to Git
KDE Bindings 4.7 has moved to Git. Hooray! You can browse through the projects at: https://projects.kde.org/projects/kde/kdebindings 4.6 will continue to be developed in SVN. We still need to update some docs on Techbase and such. Thanks, Ian
Re: kdebase-workspace and kdebase-runtime git repos to validate
On Mon, Dec 13, 2010 at 18:22, Ian Monroe wrote: > So kdelibs and kdebase are switching to Git, probably not Dec 20/21 as > was previously thought, but at the release of 4.6.0. > > Whether its next week or next month though, its pretty soon. :) > > I have three work-in-progress repos, the first two I created last night: > http://gitweb.kde.org/scratch/ianmonroe/kdebase-workspace.git > http://gitweb.kde.org/scratch/ianmonroe/kdebase-runtime.git [snip] > kdelibs is the same one I emailed kcd a while ago: > http://gitweb.kde.org/scratch/ianmonroe/kdelibs-test.git [snip] Well gitweb is down at the moment, due to a possible security issue. To clone the above repos directly do: git clone git://anongit.kde.org/scratch/ianmonroe/kdebase-workspace git clone git://anongit.kde.org/scratch/ianmonroe/kdebase-runtime git clone git://anongit.kde.org/scratch/ianmonroe/kdelibs-test Thanks, Ian
kdebase-workspace and kdebase-runtime git repos to validate
So kdelibs and kdebase are switching to Git, probably not Dec 20/21 as was previously thought, but at the release of 4.6.0. Whether its next week or next month though, its pretty soon. :) I have three work-in-progress repos, the first two I created last night: http://gitweb.kde.org/scratch/ianmonroe/kdebase-workspace.git http://gitweb.kde.org/scratch/ianmonroe/kdebase-runtime.git I've checked all the subdirectories and they appear to have a decent history. One exception is some of the Solid modules which seemed to have an early identity crisis. :) Check it out and let me know if this is a concern and with help of people who know its history we could fix it up. kdelibs is the same one I emailed kcd a while ago: http://gitweb.kde.org/scratch/ianmonroe/kdelibs-test.git For 'master' the history is appears fairly complete, some directories go back in time further then SVN log did even. The branches (especially the early CVS ones) are a bit confused, this is a work-in-progress. cvs2svn has some known issues I think, but we'll do our best. The only repo I have left to start is kdebase-apps. Thanks for any feedback you have, Ian Monroe
Trial run of the kdelibs git
I've done a trial run of a kdelibs git conversion and published it here: http://gitweb.kde.org/scratch/ianmonroe/kdelibs-test.git It should have a fairly comprehensive history thanks to Torgny Nyblom trackModule.pl script. Feedback appreciated. The plan is do the git conversion at the same time kdepim does, on Dec 20th. One question is whether we want to have a separate 'history' repo, like what Amarok has. It is used to store inactive branches. The size savings for the main repo probably isn't much, but it does clean up the 'git branch -a' list. Another issue is what the Kate folks are planning, though I don't believe it should affect the git conversion. Thanks, Ian Monroe
Re: Move kruler to git
2010/11/1 Mathias Soeken : > Hello, > > I would like to move kruler to git, but I need some help how to proceed. > Should the kdegraphics project move all at once, or will there be a Graphics > module in projects.kde.org which will hold all the sub-projects? > > Are there some online resources how to proceed in this case. For now I only > saw kdesupport and extragear projects moving to projects.kde.org. Since kruler > is rather small, it should not be as complicated as with other projects. > > Best regards, > Mathias Main modules aren't scheduled to start switching until Nov 17th: http://community.kde.org/Sysadmin/GitInfrastructureLaunch But you could start writing the ruleset for kdegraphics now to make that a reality quicker. Ian
