Re: Merge or Cherry-Pick?
Em terça-feira, 1 de fevereiro de 2011, às 09:31:40, David Jarvie escreveu: On Mon, January 31, 2011 11:27 pm, Thiago Macieira wrote: On Monday, 31 de January de 2011 23:34:39 Arno Rehn wrote: I guess that won't quite work when there are commits specific to 4.6 in the 4.6 branch that shouldn't end up in master. And it clutters history with tons of merges. Then let's solve the problem by not having anything specific to 4.6. If it belongs in the stable release, it belongs in the next stable release too. That's not always true. Some changes *will* be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. That's not a problem or an excuse. Make the change in 4.6, merge to master, fix the conflicts and then push both branches. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Wed, Feb 02, 2011 at 01:21:44AM -0500, Dawit Alemayehu wrote: On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell johnf...@gmail.com wrote: But how would a similar work flow except there are multiple fixes Does that make sense? Yes. Great. IMHO that type of documentation is what is needed in techbase. in fact, that's exactly the type that does *not* belong there. there is enough generic git documentation out there, and bloating techbase by duplicating it all won't make it simpler to use. the right way is stating the desired goals, mentioning a few key phrases (interactive rebase in this case) and linking to some external source. and remember that following receipes does *not* work if you don't actually understand what you are doing - there may always be some circumstances that make it a receipe for disaster. and from experience i can tell that some people are astonishingly stubborn with ignoring signs of disaster ...
Review Request: Fix for bug 264444: ksplashx shows garbage when background image does not properly cover entire screen
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100520/ --- Review request for KDE Base Apps and KDE Runtime. Summary --- The base splashimage pixmap/qimage is never initialized, so if for some reason the splashscreen doesn't cover the entire screen, you get garbage. That reason can be a ksplashx theme that does not use multiple monitors on a multi-monitor system, or if it picks a background that is smaller than the current resolution (for example the Horos splash 1280x1024 version appears to be 1278x1024). This addresses bug 26. http://bugs.kde.org/show_bug.cgi?id=26 Diffs - ksplash/ksplashx/splash.cpp d6a992a Diff: http://git.reviewboard.kde.org/r/100520/diff Testing --- I tested this by both replacing the background that ksplashx was using with a smaller one, and on two multi-monitor systems (one of which uses a gentoo ksplash screen that only covered one of the monitors). The splash_image.fill( 0 ) can be changed to another color for debugging purposes, clearly showing the region of the monitor that is not covered by the splashscreen (and where before would be garbage from graphics memory). Thanks, Ivo
Re: Review Request: Enlarge image in folder preview when there's only one image
On Jan. 29, 2011, 10:27 a.m., Martin Engelmann wrote: If no one objects, I would like to commit this patch at the end of next week. It looks good to me. +1 - Jeffery --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6332/#review9752 --- On Jan. 15, 2011, 9:37 a.m., Martin Engelmann wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6332/ --- (Updated Jan. 15, 2011, 9:37 a.m.) Review request for kdelibs. Summary --- As stated in the bug report, the image on the folder preview should be enlarged if there is only one image. To achieve this there are two images created for the folder: img as before and oneTileImg. oneTileImg starts with the same image as img, but after the first thumbnail is generated oneTileImg won't be touched. The number of successfully created thumbnails is counted in validThumbnails. If only one thumbnail could be generated, oneTileImg is returned. The code between lines 566 and 589 in the original thumbnail.cpp was partly extracted into a new function called drawSubThumbnail. This is done to simplify the creation of the second preview. The extra effort to create the oneTileImg comparable to creating a fifth preview image for the folder. This addresses bug 240861. https://bugs.kde.org/show_bug.cgi?id=240861 Diffs - /trunk/KDE/kdebase/runtime/kioslave/thumbnail/thumbnail.h 1214477 /trunk/KDE/kdebase/runtime/kioslave/thumbnail/thumbnail.cpp 1214477 Diff: http://svn.reviewboard.kde.org/r/6332/diff Testing --- Tested using both Dolphin and Konqueror from trunk. The thumbnail generation was tested by moving images and files without thumbnail plug-in to a new folder. Then one file after another was deleted until only files without thumbnail plug-in were present. Also I opened randomly some folders with sub-folders containing large amounts of images (e.g. oxygen icon set with 550 action icons) to the performance. Screenshots --- Folder thumbnails for oxygen icon set in Konqueror http://svn.reviewboard.kde.org/r/6332/s/604/ Thanks, Martin
Re: Top 15 Mailinglists with messages in moderation
Hi, I've talked to current maintainer (Quentin Denis) about this. And this is his response: anything related to KMT can be removed, the code is now pure playground I dont need that mailing list. So I guess one can remove it. Cheers, Dinesh On Wed, Feb 2, 2011 at 4:37 AM, John Layt johnl...@googlemail.com wrote: On Tuesday 01 February 2011 13:45:27 George Goldberg wrote: 41 kdelibs-bugs This is a very useful list for bug triagers - I can volunteer to moderate it if no-one else is currently doing it. ditto, if more than 1 or 2 mods are needed. John.
Re: Merge or Cherry-Pick?
On Dienstag 01 Februar 2011, Thiago Macieira wrote: That's not always true. Some changes will be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. That's not a problem or an excuse. Make the change in 4.6, merge to master, fix the conflicts and then push both branches. if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. -- Wolfgang
Re: Merge or Cherry-Pick?
Quoting Oswald Buddenhagen o...@kde.org: and remember that following receipes does *not* work if you don't actually understand what you are doing - there may always be some circumstances that make it a receipe for disaster. and from experience i can tell that some people are astonishingly stubborn with ignoring signs of disaster ... A good tip if all went wrong is that git saves all the states for you. Just type: git reflog and you will see a log of every operation you did. If you messed up, try doing: git reset --hard SHA1 where SHA1 is the sha1 of the last successful operation you did. but just use reflog in emergencies and try to not make it an habit! Cheers, Artur ---
Re: Merge or Cherry-Pick?
On Wed, February 2, 2011 11:38 am, John Tapsell wrote: On 2 February 2011 07:27, Dawit A ada...@kde.org wrote: Ahh... I see. It is push everything upto that commit, not just push that commit. Ouch! That is almost as much a hassle as the convoluted method I am following now. Do not commit anything that is not ready to be pushed into my own local branch. Use git stash to save the uncommited changes before doing the pull --rebase and apply the stashed changes after doing the push... And then one day you do git checkout . by mistake and lose all your local uncommitted changes that you just spent a week working on .. I'd recommend maintaining a local 'master' branch which always mirrors the remote repository. Never do development in your local 'master' branch - always do your work in other local branches, and only merge/cherry-pick changes from them into the local 'master' once you are ready to push to the remote. That way, your local master always mirrors the remote, and you can choose exactly when and which commits to push. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. If the Commit Digest guys want some tags added to make their life easier, now would be the time to speak up. John. # ---[ You MUST wrap all lines at 72 characters ]--| # # ---[ Please see http://techbase.kde.org/Policies/Commit_Policy ]-| # # ===[ Subject ]===| # ---[ One line only, short meaningful description to show in logs ]---| # ===[ Details ]===| # ---[ You MUST leave one blank line after Subject line ]--| # ---[ Describe what has changed and explain why it has changed ]--| # ===[ Fields ]| # ---[ Uncomment and edit as applicable ]--| # ---[ Add Feature to release changelog ] # ---[ Optionally close a wish in bugs.kde.org as implemented ] #FEATURE: optional bug number # # ---[ Close a bug in bugs.kde.org as fixed, with optional version ] #BUG: bug number #FIXED-IN: release version # # ---[ Copy commit message to a bug in bugs.kde.org ] #CCBUG: bug number # # ---[ Copy commit message to an email address ] #CCMAIL: email # # ---[ Close a review in reviewboard.kde.org as submitted ] #REVIEW: review number # # ---[ Advise documentation team of user visible changes in the gui ] #GUI: # # =|
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 08:25, David Jarvie wrote: I'd recommend maintaining a local 'master' branch which always mirrors the remote repository. Never do development in your local 'master' branch - always do your work in other local branches, and only merge/cherry-pick changes from them into the local 'master' once you are ready to push to the remote. That way, your local master always mirrors the remote, and you can choose exactly when and which commits to push. Note to self: Always check that there are no new messages in the thread before pressing Send. Parker
Re: Merge or Cherry-Pick?
On Wednesday 02 February 2011 07:27:01 Dawit A wrote: Ahh... I see. It is push everything upto that commit, not just push that commit. Ouch! That is almost as much a hassle as the convoluted method I am following now. Do not commit anything that is not ready to be pushed into my own local branch. Use git stash to save the uncommited changes before doing the pull --rebase and apply the stashed changes after doing the push... Never have uncommitted changes, git is designed around frequent local commits as checkpoints in your development which you can later clean-up by collapsing them into fewer commits and re-writing the commit message just before pushing to the main repo. John.
Re: irc meeting for kdelibs git workflow
On Wed, Feb 2, 2011 at 08:45, John Layt wrote: On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. I like it. Good work. Parker
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 09:05, John Layt wrote: On Wednesday 02 February 2011 13:43:04 Parker Coates wrote: My preferred workflow is to put all local commits intended for master in a single, local, long-lived workmaster branch instead of putting them in master directly. Since the changes are local, you can just keep rebasing it onto master every time master is updated. Then if you want to push a single commit from the work branch: * pull master * you interactively rebase the workmaster branch onto master to put the desired commit first * merge the SHA you want to commit into master * push master I find that by keeping my commits out of master itself allows me to update without worries, to commit high priority fixes without messing up my local work, and to commit early and often locally while still having the option to clean things up later with some rebasing. Personally, I found this ability to keep my local commit queue out of the way was the biggest advantage of switching to Git. Parker Personally, I think you should NEVER have commits in master, you should only ever work in and push from branches, they're so cheap to do. That way your master is always a clean pure copy of the main repo to branch off. If I needed to extract a single commit out of a branch to push, rather than merging it to master I'd create a new branch from master and cherry-pick the commit to that, build and test it knowing it's clean, then push from there. Then pull master and rebase the original branch on master again. Hmm. You're probably right. The majority of my Git experience has been with git-svn where it's pretty much mandatory to commit via master. In a pure Git environment, I guess it should be possible to keep master 100% clean. Parker
Re: Merge or Cherry-Pick?
On 2 February 2011 14:23, Parker Coates parker.coa...@kdemail.net wrote: On Wed, Feb 2, 2011 at 09:05, John Layt wrote: On Wednesday 02 February 2011 13:43:04 Parker Coates wrote: My preferred workflow is to put all local commits intended for master in a single, local, long-lived workmaster branch instead of putting them in master directly. Since the changes are local, you can just keep rebasing it onto master every time master is updated. Then if you want to push a single commit from the work branch: * pull master * you interactively rebase the workmaster branch onto master to put the desired commit first * merge the SHA you want to commit into master * push master I find that by keeping my commits out of master itself allows me to update without worries, to commit high priority fixes without messing up my local work, and to commit early and often locally while still having the option to clean things up later with some rebasing. Personally, I found this ability to keep my local commit queue out of the way was the biggest advantage of switching to Git. Parker Personally, I think you should NEVER have commits in master, you should only ever work in and push from branches, they're so cheap to do. That way your master is always a clean pure copy of the main repo to branch off. If I needed to extract a single commit out of a branch to push, rather than merging it to master I'd create a new branch from master and cherry-pick the commit to that, build and test it knowing it's clean, then push from there. Then pull master and rebase the original branch on master again. Hmm. You're probably right. The majority of my Git experience has been with git-svn where it's pretty much mandatory to commit via master. In a pure Git environment, I guess it should be possible to keep master 100% clean. It seems that I go against the grain, and always develop in master. You already have origin/master as a pristine version of upstream master, and you don't have to worry about it getting out of sync. E.g: git log #find SHA1 of commit I want to push upstream git checkout origin/master #we are now on an unnamed branch git cherry-pick SHA # still on an 'unnamed branch' #compile, test, fix, etc. git push origin HEAD:master git checkout master git pull --rebase #rebase on top of remote, which now has our change John
Re: Merge or Cherry-Pick?
Em quarta-feira, 2 de fevereiro de 2011, às 11:46:20, Wolfgang Rohdewald escreveu: On Dienstag 01 Februar 2011, Thiago Macieira wrote: That's not always true. Some changes will be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. That's not a problem or an excuse. Make the change in 4.6, merge to master, fix the conflicts and then push both branches. if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. Laziness is not an argument -- it's just an excuse. If you find a bug that applies to 4.6, why will you not fix it there? In my experience, testing the *stable* releases is easier. Testing the development versions usually cause trouble because of unfinished features and untested new code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
Em quarta-feira, 2 de fevereiro de 2011, às 09:23:43, Parker Coates escreveu: Hmm. You're probably right. The majority of my Git experience has been with git-svn where it's pretty much mandatory to commit via master. In No, it isn't :-) You can commit from anywhere with git-svn. It chooses the SVN target based on the last SVN commit it finds in the history. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Review Request: New KIO::http_post and KIO::StoredHttpPost APIs that accept a QIODevice as input...
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100516/ --- Review request for kdelibs. Summary --- The attached patch is the first portion a set of patches to make uploading data through HTTP more efficient without affecting the existing implementation. Right now the amount of memory consumed when uploading large files through http or webdav is really not acceptable because only a QByteArray based API is available. That means if you want to upload a file of say 50 or 100 MB to a server, then you have to read the entire thing first before you can call KIO::http_post! This addresses bug 34578. http://bugs.kde.org/show_bug.cgi?id=34578 Diffs - kio/kio/jobclasses.h e9bd191 kio/kio/job_p.h daac895 kio/kio/job.cpp 7d4a849 kio/kio/job.h 632dfc8 Diff: http://git.reviewboard.kde.org/r/100516/diff Testing --- Used by changing kdewebkit to use the new API. Thanks, Dawit
Re: irc meeting for kdelibs git workflow
Zitat von John Layt johnl...@googlemail.com: On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. If the Commit Digest guys want some tags added to make their life easier, now would be the time to speak up. John. I like it but would propose: # ===[ Subject ]===| # ---[ One line only, short meaningful description to show in logs ]---| # ===[ Details ]===| # ---[ Blank line above intentional. Do not remove ]--| # ---[ Describe what has changed and explain why it has changed ]--| It think that is more robust . Mike This message was sent using IMP, the Internet Messaging Program.
Re: Initial support for kde_projects.xml in kdesrc-build
On Tuesday 01 February 2011, Michael Jansen wrote: If you find the place let me know. No ... only if i am unable to fix it myself :)) . Do you need that for running ? For building it's not necessary. Use CMAKE_PREFIX_PATH. I always thought that PATH controls which qt version is selected if you have more than one (First qmake found). It was that way some time ago. And QTDIR IS USED in FindQt4.cmake. I don't reevaluate my finding every day so perhaps something changed. Ok. So when an executable is searched, it is searched in a set of default directories (as e.g. /usr/bin/) and in PATH. So setting PATH so that it points to the qmake you want works. CMAKE_PREFIX_PATH is more generic (and didn't exist in cmake 2.4.something). So you can set this too to make cmake find the Qt you want (not pointing to QTDIR/bin, but just to QTDIR). QTDIR is a variable specific to FindQt4.cmake, so it works too. So all three work, the most generic/powerful one is CMAKE_PREFIX_PATH. Then the 100 points question is: If all of them point to a directory with a qt installed (three different versions). Which one wins? a) CMAKE_PREFIX_PATH b) PATH c) QTDIR I remember more than one newbie losing his grip over not beeing able to convince cmake to pickup the right one. Can you answer it without looking at the cmake file? I can't. CMAKE_PREFIX_PATH has more or less highest priority. Of course it can be ignore when using NO_DEFAULT_PATH. Alex
Re: Initial support for kde_projects.xml in kdesrc-build
On Wednesday 02 February 2011, Michael Pyne wrote: ... e.g. worrying about environment variables like PKG_CONFIG_PATH is no idle claim (kdesrc-build sets that as well), along with PATH in order to pick up the right Qt version. Please try to use only CMAKE_PREFIX_PATH instead of setting PATH. I recommend this to everybody. I'd also suggest not to set PKG_CONFIG_PATH, at least not to directories where KDE stuff is installed, this has to be found also without pkgconfig. Alex
Re: Merge or Cherry-Pick?
On Wednesday 02 February 2011, Oswald Buddenhagen wrote: On Wed, Feb 02, 2011 at 01:21:44AM -0500, Dawit Alemayehu wrote: On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell johnf...@gmail.com wrote: But how would a similar work flow except there are multiple fixes Does that make sense? Yes. Great. IMHO that type of documentation is what is needed in techbase. in fact, that's exactly the type that does *not* belong there. there is enough generic git documentation out there, and bloating techbase by duplicating it all won't make it simpler to use. the right way is stating the desired goals, mentioning a few key phrases (interactive rebase in this case) and linking to some external source. I very much disagree with this. We need the basic recipes there. With short statements I then start searching around in the web, find some blogs, some man pages, mess around, and in the end just take a local diff, get a fresh clone because everything is messed up, and apply the local diff in one step. At least that's the experience I had when trying to merge with conflicts and short remarks like do a interactive rebase or something like that, which lead me into an editor window which showed strange things where I didn't understand what I should do and when I did something things just got worse. Alex
Re: Merge or Cherry-Pick?
On Wednesday 02 February 2011, John Layt wrote: On Wednesday 02 February 2011 13:43:04 Parker Coates wrote: My preferred workflow is to put all local commits intended for master in a single, local, long-lived workmaster branch instead of putting them in master directly. Since the changes are local, you can just keep rebasing it onto master every time master is updated. Then if you want to push a single commit from the work branch: * pull master * you interactively rebase the workmaster branch onto master to put the desired commit first * merge the SHA you want to commit into master * push master I find that by keeping my commits out of master itself allows me to update without worries, to commit high priority fixes without messing up my local work, and to commit early and often locally while still having the option to clean things up later with some rebasing. Personally, I found this ability to keep my local commit queue out of the way was the biggest advantage of switching to Git. Parker Personally, I think you should NEVER have commits in master, you should only ever work in and push from branches, they're so cheap to do. That way your master is always a clean pure copy of the main repo to branch off. I don't really care how it will be, but I really think we should agree on one common recommended and documented workflow to use. Alex
Re: Merge or Cherry-Pick?
On Wednesday, 2 de February de 2011 18:28:38 Alexander Neundorf wrote: If you find a bug that applies to 4.6, why will you not fix it there? In my experience, testing the *stable* releases is easier. Testing the development versions usually cause trouble because of unfinished features and untested new code. The code may already differ. The developer may not have both branches installed in a recent and runnable state. Fair enough. Then fix only master. If you don't have the time or ability to test the stable release, do not apply commits there. If you can't test it, then you can't be sure to be doing worse. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011, Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. I don't see where this document describes the workflow to use with git. Alex
Re: Merge or Cherry-Pick?
Would someone be so kind to tell me how to undo accidentally pushed commits to trunk ? By accident I pushed the following commits to trunk when I only meant to push backported fixes in 4.6 branch: http://quickgit.kde.org/?p=kdelibs.gita=commith=e6f00fdd71328b26e57ef09e97e4aca569c4199c http://quickgit.kde.org/?p=kdelibs.gita=commith=65ac813c955c97798b53cd3f45854c40bdd2feaa http://quickgit.kde.org/?p=kdelibs.gita=commith=449d49908ce610d9af4e8e3da89466f168f66bc3
Re: irc meeting for kdelibs git workflow
On Tuesday 01 February 2011, Aaron J. Seigo wrote: hi everyone ... with git having finally arrived more-or-less, we find ourselves without a well defined work flow for kdelibs (and by extension other KDE repositories) i don't think we can or should hope and pray that our sysadmins will perform another magic trick and solve this for us, nor can we all just sit here looking at each other. so i'd like to suggest that we gather on irc in the near future and hammer this stuff out. weekends tend to be better for many it seems, so i've put up a doodle here: http://doodle.com/htgi56p8n2i7n3i8 where you can register your intention to attend and when you can. it covers this weekend and next. i can't attend this weekend, but that shouldn't stop others if this weekend is best for the majority. a draft agenda might look like: * 3rd party examples we can learn from: http://public.kitware.com/Wiki/Git/Workflow/Topic Short version of the cmake git workflow: * pull/update master * for any change, create a topic branch from master * work in the branch... * when done, merge the branch into next and push Once every week Brad and Dave from Kitware sit down and merge from next into master, to create a fresh master with the new stuff. I'm quite happy with that. I guess it doesn't work for KDE, or how could the merging from next into master be done ? Alex
Re: Merge or Cherry-Pick?
On Wednesday, February 2, 2011, Alexander Neundorf wrote: On Wednesday 02 February 2011, Oswald Buddenhagen wrote: in fact, that's exactly the type that does *not* belong there. there is enough generic git documentation out there, and bloating techbase by duplicating it all won't make it simpler to use. the right way is stating the desired goals, mentioning a few key phrases (interactive rebase in this case) and linking to some external source. I very much disagree with this. We need the basic recipes there. imho, you're both right :) simple recipes for the common tasks that are done in a KDE way will be of critical value; we can not expect everyone to learn on their own and then expect them to all be proficient or to do things consistently without some basic guidance. so yes, we're going to need to document a few basic things and that will probably involve some very simple illustrative examples. but we also can not get involved in writing a New and Improved Book On Git, either. we ought to rely on external sources for that, as Ossi points out. it's the difference between documenting the KDE best practices and teaching people how to use git, right? and it's one of the things that i found CMake's git documentation pages does very well. they don't make too much sense if you don't have a basic understanding of git, and you'll still run into all kinds of issues in practice that aren't covered on those pages, but they give you enough information to get pointed in the right direction and using the right kinds of commands for the different parts of their development workflow. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday, February 2, 2011, Alexander Neundorf wrote: * for any change, create a topic branch from master * work in the branch... in cmake development, how do developers find each other's branches to check on works-in-progress, collaborate, etc? are they pushed to a shared repository somewhere, documented somewhere where they are easily found, ...? I guess it doesn't work for KDE, or how could the merging from next into master be done ? i don't know about kdelibs, but i'm going to end up doing that for large parts of kde-workspace. (though i'm hoping/expecting for help from others so that it's not just bottlenecking on me alone. :) so maybe it's not without hope that we find a few people who play the role of merge master for kdelibs as well. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011, i...@michael-jansen.biz wrote: Zitat von John Layt johnl...@googlemail.com: On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. If the Commit Digest guys want some tags added to make their life easier, now would be the time to speak up. John. I like it but would propose: # ===[ Subject ]===| # ---[ One line only, short meaningful description to show in logs ]---| # ===[ Details ]===| # ---[ Blank line above intentional. Do not remove ]--| # ---[ Describe what has changed and explain why it has changed ]--| It think that is more robust . I like it as well. How can I make sure calligra hackers get to see this when they try to commit? -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: irc meeting for kdelibs git workflow
Quoting Boudewijn Rempt b...@valdyas.org: I like it as well. How can I make sure calligra hackers get to see this when they try to commit? Just create a text file named .commit-template in your repo's root folder with the template :) Cheers, Artur ---
Re: irc meeting for kdelibs git workflow
Quoting Boudewijn Rempt b...@valdyas.org: I like it as well. How can I make sure calligra hackers get to see this when they try to commit? Ah and add: [commit] template = .commit-template to your git config file (I forgot this in the other mail :) Cheers, Artur PS: thanks Alexis :P ---
Review Request: Consistent wording between edit email and edit IM dialogues
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100528/ --- Review request for KDEPIM-Libraries. Summary --- In the KAddressBook application, there is an inconsistency between the editing dialogues for the email addresses and IM contact addresses. In the dialogue for email the window title says ... Addresses and the set as standard button says Set Standard. In the corresponding dialogue for IM the title says ... Address (even though there can be more than one) and the same button says Set as Standard. This change makes the pluralisation of the window title, and the label of this button, consistent between these two dialogues. Diffs - akonadi/contact/editor/emaileditwidget.cpp a931ec1 akonadi/contact/editor/im/imeditordialog.cpp 3a2c83f Diff: http://git.reviewboard.kde.org/r/100528/diff Testing --- Built kdepimlibs and ran kaddressbook with these changes, verified the display. Thanks, Jonathan
Re: irc meeting for kdelibs git workflow
On Wednesday, February 2, 2011, Boudewijn Rempt wrote: In calligra, i was surprised to see people taking to branching like pigs to muck or fish to water. yeah, they are awesome :) We now have 37 feature branches, of which several have merged to master after review already. There's a simple naming pattern that's become sort of the calligra culture already -- subproject_topic_commit-name interesting; we're doing similar in kde-workspace: commit-name/topic; most of the time it's clear from the topic what the subproject is, so we haven't yet felt the need for subproject in there. but then again, we're only on our fourth feature branch :) what i'm finding nice with commit-name/topic is that i can track things easily by person of origin: KDE/4.6 is official while aseigo/activitiesrunner is something i'm working on. i can see how putting the subproject in front of that can add another nice layer of grouping as well. hm.. we might end up borrowing that strategy :) -- and it all works out very well. Master is is everyone pushing their branches to the main repository, or keeping them in separate cloned repositories? for kde-workspace we're seriously considering using a shared clone (not quite a team clone, more like a communally abused personal clone ;) so that the commit hooks don't get run on feature branches until they are ready for merging (which is particularly a nuisance with commits that have BUG: in the log message) but so that we can keep our development still in one easy to find place. that would make master in the clone our integration branch, and master in kde- workspace our shipping branch. i'm still working out the amount of merge work that will end up making for us, though ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: Merge or Cherry-Pick?
On Wednesday, February 2, 2011, Thiago Macieira wrote: I still think the current procedure is wrong. You're not testing the stable release, there's no guarantee that you're solving the problem at all, or worse, that you're not making it worse. and, imho, the stable branch is the more important thing to test: if it goes wrong in master due to a bad or unecessary merge from stable, you usually have months to notice and fix it. certain you or your teammates that also track master will notice it faster than if it sits in the stable branch where primary devel isn't happening anymore. with our monthly x.y.z releases, you have at most a few weeks with fewer people tracking the stable branch to catch a bad merge from master. so, again at least imho, the risk is higher when backporting compared to forward porting. and finally we have a tool that makes it reasonably painless to do it. :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday, February 2, 2011, Boudewijn Rempt wrote: On Wednesday 02 February 2011, Aaron J. Seigo wrote: -- and it all works out very well. Master is is everyone pushing their branches to the main repository, or keeping them in separate cloned repositories? Yes, to the main repository. No public clones. We might have to rething that when we have a few hundred branches -- on the other hand, branches can be deleted when done with, or we can add a datestamp or something like that. i've operated under the assumption that we'd delete branches every so often. maybe once a year as a (literal?) spring cleaning, every branch older than a certain age that's been merged .. which implies keeping track of those branches .. hm... for kde-workspace we're seriously considering using a shared clone (not quite a team clone, more like a communally abused personal clone ;) so that the commit hooks don't get run on feature branches until they are ready for merging (which is particularly a nuisance with commits that have BUG: in the log message) but so that we can keep our development still in one easy to find place. Hm... yes -- the BUG keywoard can be tricky. We haven't encountered it yet, with people being very good about using CCBUG in the branches, and BUG in the merge commit message. yes, that's another approach i suppose... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011, Aaron J. Seigo wrote: On Wednesday, February 2, 2011, Alexander Neundorf wrote: * for any change, create a topic branch from master * work in the branch... in cmake development, how do developers find each other's branches to check on works-in-progress, collaborate, etc? The group of cmake developers is small. It's about 4 people at Kitware, and then mostly me and two other guys outside of Kitware who commit C++ sources I think (but there are more module maintainers). What we do mostly does not overlap, so e.g. I don't feel the need to check what e.g. Eric is doing currently. The cmake git stage is basically for announcing please merge this next week into master. For other things using github or gitorious is recommended. ...and maybe gerrit in the future. Bigger things which need coordination are discussed on the mailing list first. Since last year doing a patch release every three months is planned, features are discussed at the beginning of the period (the last time with an actual phone conference). So, not sure there is in this regard much to learn for KDE. Alex
Re: Fwd: Top 15 Mailinglists with messages in moderation
On Tuesday 01 February 2011, Tom Albers wrote: 32 kde-usability I can have a look at those (and all upcoming messages). Regards, Ingo signature.asc Description: This is a digitally signed message part.
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: Merge or Cherry-Pick?
On Wednesday 02 February 2011 21:15:31 Aaron J. Seigo wrote: On Wednesday, February 2, 2011, Thiago Macieira wrote: I still think the current procedure is wrong. You're not testing the stable release, there's no guarantee that you're solving the problem at all, or worse, that you're not making it worse. and, imho, the stable branch is the more important thing to test: if it goes wrong in master due to a bad or unecessary merge from stable, you usually have months to notice and fix it. certain you or your teammates that also track master will notice it faster than if it sits in the stable branch where primary devel isn't happening anymore. with our monthly x.y.z releases, you have at most a few weeks with fewer people tracking the stable branch to catch a bad merge from master. so, again at least imho, the risk is higher when backporting compared to forward porting. and finally we have a tool that makes it reasonably painless to do it. :) I have two reasons to test in master: - I run master myself all the time. - If a fix really is dangerous I don't want it to appear in a bugfix release by accident. If nobody was running master who'd make sure its quality was even remotely decent? Somehow I don't buy that we should all be testing the latest stable branch while developing against master. Switching environments all the time is a major hassle and not as effective at finding and making people care about bugs in master.
Re: Merge or Cherry-Pick?
On Wed, Feb 2, 2011 at 1:03 PM, Dawit A ada...@kde.org wrote: Would someone be so kind to tell me how to undo accidentally pushed commits to trunk ? By accident I pushed the following commits to trunk when I only meant to push backported fixes in 4.6 branch: http://quickgit.kde.org/?p=kdelibs.gita=commith=e6f00fdd71328b26e57ef09e97e4aca569c4199c http://quickgit.kde.org/?p=kdelibs.gita=commith=65ac813c955c97798b53cd3f45854c40bdd2feaa http://quickgit.kde.org/?p=kdelibs.gita=commith=449d49908ce610d9af4e8e3da89466f168f66bc3 For those like me who made a mistake like this one there is an easy solution... Do git config --global push.default tracking and use the -t or --track option when creating your branches (branch or checkout -b). This way you can 'git push' (no arguments) in the current tracked branch without accidentally pushing your changes in other branches.
Re: Merge or Cherry-Pick?
Am 2/3/2011 6:10, schrieb Dawit A: What happens if I tested a bug fix and wanted it to push it upstream so that it can receive even wider testing, but it just so happens the time to tag the next bug fix release is right around the corner ? The original intent is to at least leave the bug fix in the trunk for several days to see if it causes any unforeseen regression. It is an impossible task for any developer, specially one working on the plumbing libraries, to test every possible combination or use case. If the push is done into a stable branch, then there is a real possibility that users are going to get exposed to unintended regressions. I'll assume you meant to say push is done into a stable branch *too early*... (otherwise, the last sentence in this paragraph is incompatible with the first part of the paragraph). You do it this way: 1. You fork off a topic branch from stable, and place your fix there. 2. Compile-test the fix. (Bonus points, if you can test the fix in action with the stable version.) 3. Merge that topic into master. Compile and test. 4. Publish the merge. Let it cook for a week in master. 5. Looks OK? Good. Merge the topic into the stable branch as well. (The stable branch might have progressed in the past week, hence, you don't necessarily fast-forward, but get a real merge.) 6. Merge stable into master and publish both. However, if you cannot test your fix with the stable version yourself, you should ask someone to do Step 5, additionally Step 5b test with stable version, and Step 6 for you. Hannes -- Atomic objects are neither active nor radioactive. -- Programming Languages -- C++, Final Committee Draft (Doc.N3092)
