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 fi
On Wed, Feb 2, 2011 at 1:03 PM, Dawit A 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.git&a=com
On Wed, Feb 2, 2011 at 6:13 PM, Andreas Hartmetz wrote:
> 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
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 n
> 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 th
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 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 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
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 importa
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
w
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 simpl
---
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 02 February 2011, Artur de Souza wrote:
> Quoting Boudewijn Rempt :
> > 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
Quoting Boudewijn Rempt :
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
Quoting Boudewijn Rempt :
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
---
On Wednesday, 2 de February de 2011 20:35:19 Andreas Hartmetz wrote:
> On Monday 31 January 2011 23:27:15 Thiago Macieira wrote:
> > On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> > > Hi,
> > >
> > > something that hasn't been written down as far as I can see (if I
> > > overlo
On Monday 31 January 2011 23:27:15 Thiago Macieira wrote:
> On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> > Hi,
> >
> > something that hasn't been written down as far as I can see (if I
> > overlooked it, please point me to it) is what the policy on kdelibs is
> > to be now wr
Am Mittwoch, 2. Februar 2011, 11:46:20 schrieb Wolfgang Rohdewald:
> 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 wo
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-pro
On Wednesday 02 February 2011, i...@michael-jansen.biz wrote:
> Zitat von John Layt :
>
> > 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
> >
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
som
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
On Wed, Feb 2, 2011 at 1:49 PM, Pino Toscano wrote:
> Alle mercoledì 2 febbraio 2011, Dawit A ha scritto:
>> Would someone be so kind to tell me how to undo accidentally pushed
>> commits to trunk ?
>
> $ git revert SHA
>
>> http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=449d49908ce610d9af
>> 4
Alle mercoledì 2 febbraio 2011, Dawit A ha scritto:
> Would someone be so kind to tell me how to undo accidentally pushed
> commits to trunk ?
$ git revert SHA
> http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=449d49908ce610d9af
> 4e8e3da89466f168f66bc3
This commit, which is your "fix" for the
On 02.02.11 13:03:03, Dawit A 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:
You can't. Whats pushed cannot be taken back, you can put
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 wil
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.git&a=commit&h=e6f00fdd71328b26e57ef09e97e4aca569c4199c
http://qui
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.
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
> > f
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 ch
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 wrote:
> > >> But how would a similar work flow except there are multiple fixes
> > >
> > > Does that make sense?
> >
> > Ye
On Wednesday 02 February 2011, Thiago Macieira wrote:
> 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 co
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.
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 wh
Zitat von John Layt :
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
particu
---
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 fir
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 th
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, s
On 2 February 2011 14:23, Parker Coates 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
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 change
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 ma
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 si
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: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 int
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 t
On Wed, Feb 2, 2011 at 00:35, Dawit A wrote:
> I learned this the hard way, but it is even more problematic, at least
> for me, when you attempt to learn how to adapt or re-learn how to do a
> particular workflow with git. For example, let us take one of the
> things Alexander mentioned in his emai
On Wed, February 2, 2011 11:38 am, John Tapsell wrote:
> On 2 February 2011 07:27, 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
On Tuesday 01 February 2011, Anders Lund wrote:
> A stray thought on making plasma-netbook easier to use: have a shortcut to
> the search field, and put it in the text, so it reads "F2 to search"
> instead of "Search" (given F2 is the shortcut). That way it will be
> visible to the user what to do.
On 2 February 2011 07:27, 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 g
Quoting Oswald Buddenhagen :
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 ignor
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.
>
> M
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 wrote
> 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, vi
---
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 bas
On Wed, Feb 02, 2011 at 01:21:44AM -0500, Dawit Alemayehu wrote:
> On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell 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.
>
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 ha
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
57 matches
Mail list logo
