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
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
---
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
---
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
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
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
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
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,
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.
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
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
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:
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
41 matches
Mail list logo
