Re: KDE git workflow

2011-06-13 Thread Alexander Neundorf
On Monday 13 June 2011, John Layt wrote: > On Thursday 09 Jun 2011 17:56:54 John Layt wrote: > > On Thursday 09 Jun 2011 17:34:57 Cornelius Schumacher wrote: > > > Any takers for augmenting the examples with > > > step-by-step instructions from the real world? > > > > At Platform 11 I started a co

Re: KDE git workflow

2011-06-13 Thread John Layt
On Thursday 09 Jun 2011 17:56:54 John Layt wrote: > On Thursday 09 Jun 2011 17:34:57 Cornelius Schumacher wrote: > > Any takers for augmenting the examples with > > step-by-step instructions from the real world? > > At Platform 11 I started a couple of detailed step-by-steps for new Git > users wh

Re: KDE git workflow

2011-06-09 Thread Ben Cooksley
On Fri, Jun 10, 2011 at 9:32 AM, Cornelius Schumacher wrote: > 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 >> comm

Re: KDE git workflow

2011-06-09 Thread Aaron J. Seigo
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 integ

Re: KDE git workflow

2011-06-09 Thread Cornelius Schumacher
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

Re: KDE git workflow

2011-06-09 Thread John Layt
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 rea

Re: KDE git workflow

2011-06-09 Thread Cornelius Schumacher
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

Re: KDE git workflow

2011-06-09 Thread Cornelius Schumacher
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

Re: KDE git workflow

2011-06-09 Thread David Jarvie
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

Re: KDE git workflow

2011-06-09 Thread Cornelius Schumacher
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

Re: KDE git workflow

2011-06-09 Thread Torgny Nyblom
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 """ Loc

Re: KDE git workflow

2011-06-09 Thread Maksim Orlovich
> To make this happen we need to make these branches visible, communicate > what's > going on in them, and advertise them to other developers and adventurous > users. One project which does that successfully is the Kernel, so maybe we > could do it in a similar way. Will we have a single person re

Re: KDE git workflow

2011-06-09 Thread Cornelius Schumacher
On Thursday 09 June 2011 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. While they > are in integration branches, on

Re: KDE git workflow

2011-06-09 Thread David Jarvie
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 cor

KDE git workflow

2011-06-08 Thread Cornelius Schumacher
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 is