On Wednesday, August 31, 2011 01:00:56 PM Sebastian Kügler wrote:
On Friday, August 26, 2011 12:06:26 Stephen Kelly wrote:
Was this decided upon at some point? I got conflicting stories from
sysadmin and other developers. Yesterday after migrating
kdeaccessibility to git I was asked by
On 13 September 2011 00:03, Alexander Neundorf neund...@kde.org wrote:
Including the 5 ?
http://vizzzion.org/blog/2011/06/there-is-no-kde5/ ;-)
Alex
I think that 5 has to stick around.When we go to KDE 6 how we will name it
if there isn't going to be any 5?
And moreover there will be a lot
On Friday, August 26, 2011 12:06:26 Stephen Kelly wrote:
Was this decided upon at some point? I got conflicting stories from
sysadmin and other developers. Yesterday after migrating
kdeaccessibility to git I was asked by a sysadmin to rename the X.Y
branches to KDE/X.Y I think concensus
Ok it seems most people with a preference prefer KDE/X.Y over X.Y and for
valid reasons
1) Other non-kde blessed branches can have obvious names.
2) Kdelibs, base, etc. are already KDE/X.Y
3) More modules are already KDE/X.Y than X.Y so less to fix when enforcing
consistency. (after looking at
I forgot to mention some details about my proposal. See below.
On Wed, Aug 31, 2011 at 9:07 AM, Jeremy Whiting jpwhit...@kde.org wrote:
Ok it seems most people with a preference prefer KDE/X.Y over X.Y and for
valid reasons
1) Other non-kde blessed branches can have obvious names.
2)
On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote:
Was this decided upon at some point? I got conflicting stories from
sysadmin and other developers. Yesterday after migrating kdeaccessibility
to git I was asked by a sysadmin to rename the X.Y branches to KDE/X.Y I
think concensus
On Saturday, August 27, 2011 21:27:06 Michael Pyne wrote:
On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote:
Was this decided upon at some point? I got conflicting stories from
sysadmin and other developers. Yesterday after migrating kdeaccessibility
to git I was asked by a
Alexander Neundorf wrote:
No branches should be prefixed with KDE; we consider that a reserved
name.
Nor topic should branches be numeric in nature (such as a version
number) as
those are reserved for actual release branches. (Sys admin at the
meeting indicated that it is likely
On Wednesday 24 August 2011 06.20.06 Torgny Nyblom wrote:
My vote goes for the X.Y scheme as the repo is already under the
KDE namespace.
That information is lost as soon as the repository is cloned, though.
As disc and bandwidth gets cheaper we'll probably see more mirror sites do
full
On Wed, Aug 24, 2011 at 5:29 AM, Thomas Zander zan...@kde.org wrote:
On Wednesday 24 August 2011 06.20.06 Torgny Nyblom wrote:
My vote goes for the X.Y scheme as the repo is already under the
KDE namespace.
That information is lost as soon as the repository is cloned, though.
As disc and
On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote:
Was this decided upon at some point? I got conflicting stories fromsysadmin
and other developers. Yesterday after migrating kdeaccessibilityto git I
was asked by a sysadmin to rename the X.Y branches to KDE/X.Y Ithink
personally, i
On Tue, Aug 23, 2011 at 6:15 PM, Aaron J. Seigo ase...@kde.org wrote:
On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote:
Was this decided upon at some point? I got conflicting stories fromsysadmin
and other developers. Yesterday after migrating kdeaccessibilityto git I
was asked by a
On Tue, Aug 23, 2011 at 12:38 AM, Ben Cooksley bcooks...@kde.org wrote:
On Tue, Aug 23, 2011 at 6:15 PM, Aaron J. Seigo ase...@kde.org wrote:
On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote:
Was this decided upon at some point? I got conflicting stories
fromsysadmin
and other
On Tue, 23 Aug 2011 08:15:50 +0200, Aaron J. Seigo wrote:
On Monday, August 22, 2011 11:33:49 Jeremy Whiting wrote:
Was this decided upon at some point? I got conflicting stories
fromsysadmin
and other developers. Yesterday after migrating kdeaccessibilityto
git I
was asked by a sysadmin to
On Tue, Feb 15, 2011 at 10:51 AM, Aaron J. Seigo ase...@kde.org wrote:
hi all
so after the meeting on Sunday, here is where we are in terms of a draft
workflow. more complete meeting minutes can be seen here:
http://titanpad.com/SnJwFW2iXL
the goal of the meeting was to come up
On Monday 22 August 2011, Jeremy Whiting wrote:
On Tue, Feb 15, 2011 at 10:51 AM, Aaron J. Seigo ase...@kde.org wrote:
hi all
so after the meeting on Sunday, here is where we are in terms of a draft
workflow. more complete meeting minutes can be seen here:
Am Donnerstag 17 Februar 2011, 13:46:04 schrieb Johannes Sixt:
Am 2/17/2011 12:10, schrieb Andreas Hartmetz:
On Thursday 17 February 2011 09:01:05 Johannes Sixt wrote:
When you develop a new feature, it is a very important choice on which
version of the software you base it on. I am
I'm tired aguing, so I'll leave it at that. Just one point (because I
don't want to be called silly):
Am 2/17/2011 21:56, schrieb Stephen Kelly:
Choose a starting point
that is convenient; but DO NOT CHANGE IT once you have done serious
development, because a change (aka rebase) basically
On Freitag 18 Februar 2011, Parker Coates wrote:
This is off topic, but is there a git tool to run a particular
command (for example, cmake make ./test) for every
commit in a range? Something like git-bisect without the
bisecting.
for commit in `git log 64d2c1e...ba634b6
Am 2/18/2011 11:37, schrieb Parker Coates:
This is off topic, but is there a git tool to run a particular command
(for example, cmake make ./test) for every commit in a range?
Something like git-bisect without the bisecting.
More than once, I've rebased a local topic branch and been
Johannes Sixt wrote:
I'm tired aguing, so I'll leave it at that. Just one point (because I
don't want to be called silly):
Just for clarity I wasn't calling you silly :).
I think we're just victims of low-bandwidth communication.
All the best,
Steve.
On 18/02/2011, Wolfgang Rohdewald wolfg...@rohdewald.de wrote:
On Freitag 18 Februar 2011, Parker Coates wrote:
This is off topic, but is there a git tool to run a particular
command (for example, cmake make ./test) for every
commit in a range? Something like git-bisect without the
On Thursday 17 February 2011 09:01:05 Johannes Sixt wrote:
Am 2/16/2011 22:10, schrieb Stephen Kelly:
As one of the people asked to describe my idea of the workflow (which
should focus on rebasing, not merging) I put write up here:
Am 2/17/2011 12:10, schrieb Andreas Hartmetz:
On Thursday 17 February 2011 09:01:05 Johannes Sixt wrote:
When you develop a new feature, it is a very important choice on which
version of the software you base it on. I am advocating to base a feature
on a well-known, stable state. If you choose
On Wed, Feb 16, 2011 at 10:31 PM, Stephen Kelly steve...@gmail.com wrote:
If someone writes 100 commits and pushes them without review then that's a
social problem.
I was referring to the case when a feature branch gets moved between
repositories (e.g. a personal clone and the master repo).
On Wednesday 16 February 2011 12:58:48 John Layt wrote:
I want to make a start on some of the Git recipe and reference
documentation as things occur to me, and was thinking a central
http://techbase.kde.org/Development/Git hub page leading off to the various
tutorial, policy, recipe, sysadmin,
Johannes Sixt wrote:
Am 2/16/2011 22:10, schrieb Stephen Kelly:
As one of the people asked to describe my idea of the workflow (which
should
focus on rebasing, not merging) I put write up here:
http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea
On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo ase...@kde.org wrote:
Only features / topics that are intended from the state to be merged with
master should end up in the main repository, however. More experimental and/or
long term efforts (an example presented was the kconfig refactor leading
On Tuesday 15 February 2011 18:32:29 John Layt wrote:
Actually, even more complete minutes, outstanding issues and action points
can be found at http://community.kde.org/20110213_GitWorkflowAgenda
Following up on my action points for the commit template and config settings.
I've attached a
On Wednesday 16 February 2011 10:58:48 John Layt wrote:
# ===[ Subject ]===|
# ---[ One line only, short meaningful description to show in logs ]---|
Personally, I find that starting this short description with the module,
library or whatever
On Wednesday, February 16, 2011 13:45:46 Stefan Majewsky wrote:
On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo ase...@kde.org wrote:
Only features / topics that are intended from the state to be merged
with
master should end up in the main repository, however. More experimental
and/or
Michael Pyne wrote:
People who are interested in ksslsocket will see the commits.
You're thinking of CommitFilter. I'm thinking of the kde-commits mailing
list (i.e. people who didn't *know* they were interested in ksslsocket
until they saw a strange commit).
I wasn't really. It's just as
Sorry, knode fails me again. Some keyboard shortcut must be too close to
ctrl+v for me...
Stephen Kelly wrote:
Either way is an assumption, but only one of these assumptions involves
deliberately discarding data. ;)
If noise is data, you would have a good point.
What specifically do you
mjansen might just have been following a 'never rebase public branches'
philosphy, but that really doesn't work for me. It was a complicated feature
requiring lots of refactoring.
Hehe ... as the one doing the code i would say it was more like
mjansen stumbled through unchartered
Michael Jansen wrote:
mjansen might just have been following a 'never rebase public branches'
philosphy, but that really doesn't work for me. It was a complicated
feature requiring lots of refactoring.
Hehe ... as the one doing the code i would say it was more like
mjansen
hi all
so after the meeting on Sunday, here is where we are in terms of a draft
workflow. more complete meeting minutes can be seen here:
http://titanpad.com/SnJwFW2iXL
the goal of the meeting was to come up with a draft of a mutually agreeable
git workflow for kdelibs and
On Tuesday 15 February 2011 17:51:35 Aaron J. Seigo wrote:
hi all
so after the meeting on Sunday, here is where we are in terms of a draft
workflow. more complete meeting minutes can be seen here:
http://titanpad.com/SnJwFW2iXL
Actually, even more complete minutes, outstanding
37 matches
Mail list logo
