On Wed, June 8, 2011 6:03 pm, Cornelius Schumacher wrote:
As you already know, we have discussed the git workflow for KDE at the
Platform 11 sprint, and have come up with a recommendation. Please find
the
full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow
The core
On Wednesday 08 June 2011 19.03.01 Cornelius Schumacher wrote:
As you already know, we have discussed the git workflow for KDE at the
Platform 11 sprint, and have come up with a recommendation. Please find the
full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow
Local
On Thursday 09 June 2011 Maksim Orlovich wrote:
Will we have a single person review every single commit to master, too?
We don't have formal rules about who reviews commits. That will be done by the
developers and maintainers who care, just like it is done now.
We might have a Aaron's
On Thu, June 9, 2011 5:22 pm, Cornelius Schumacher wrote:
On Thursday 09 June 2011 Maksim Orlovich wrote:
And what if there are multiple branches on the same module at the same
time? Which one of these branches, or master (or release?) is going to
get testing coverage?
The idea is that, if
On Thursday 09 June 2011 Torgny Nyblom wrote:
This part I fully agree with, however later in the example section it seems
like rebasing should be done prior to review. Is the examples correct?
The examples need some reality check, ideally with detailed actual git
commands. In general it's a
On Thursday 09 June 2011 David Jarvie wrote:
In order to get good testing coverage, there should normally only be one
integration branch per git module. Otherwise, testing coverage will be
split between the competing integration branches.
Right.
--
Cornelius Schumacher schumac...@kde.org
On Thursday 09 Jun 2011 17:34:57 Cornelius Schumacher wrote:
On Thursday 09 June 2011 Torgny Nyblom wrote:
This part I fully agree with, however later in the example section it
seems like rebasing should be done prior to review. Is the examples
correct?
The examples need some reality
On Thursday 09 June 2011 John Layt wrote:
Besides the inconsistency that
Torgey also found, the one part of the command flow I'm wondering about is
whether for the simple workflow we tell them to push or merge their
commits into master?
If it's a local branch, rebase the branch, merge it to
On Thursday, June 9, 2011 13:50:59 David Jarvie wrote:
One side effect of using integration branches in what used to be
kdelibs/kdepimlibs/kdebase is that new features aren't likely to be widely
tested until later in the development cycle than previously.
features should not remain in
As you already know, we have discussed the git workflow for KDE at the
Platform 11 sprint, and have come up with a recommendation. Please find the
full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow
The core ideas are that:
* master is always kept in a stable state that
10 matches
Mail list logo
