On 13 September 2011 00:03, Alexander Neundorf 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 of con
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
I forgot to mention some details about my proposal. See below.
On Wed, Aug 31, 2011 at 9:07 AM, Jeremy Whiting 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) Kdelibs, base, etc. a
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 whic
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 thin
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 s
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 concensu
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
On Wed, Aug 24, 2011 at 5:29 AM, Thomas Zander 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 bandw
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 mirr
Am Dienstag, 23. August 2011, 08:15:50 schrieb Aaron J. Seigo:
> 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
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 r
On Tue, Aug 23, 2011 at 12:38 AM, Ben Cooksley wrote:
> On Tue, Aug 23, 2011 at 6:15 PM, 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 a
On Tue, Aug 23, 2011 at 6:15 PM, 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
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 Monday 22 August 2011, Jeremy Whiting wrote:
> On Tue, Feb 15, 2011 at 10:51 AM, 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.c
On Tue, Feb 15, 2011 at 10:51 AM, 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
>
> the goal of the meeting was to come up with a
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
On 18/02/2011, Wolfgang Rohdewald 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
>> bisecting.
>
> fo
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.
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 bee
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 --pretty='fo
On Fri, Feb 18, 2011 at 03:21, 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):
>
> 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 se
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
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
>>
>> http://thread.g
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, sysadm
On Wed, Feb 16, 2011 at 10:31 PM, Stephen Kelly 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). Review can
only happ
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
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:
> >
> > http://community.kde.org/20110213_GitWorkflowAg
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
>
> http://thread.gmane.org/gmane.comp.kde.scm-inte
> The complicated nature of the feature is the reason for it, but the point I
> was trying to make was that each of the noisy aspects should be discouraged
> by discouraging merging and encuraging rebasing instead in the documented
> workflows.
A point where i btw. disagree. But i am not willing
On Thursday, February 17, 2011 00:19:56 Stephen Kelly wrote:
> >> What specifically do you mean by "creating useful history" though?
> >> i.e.
> >> what should be done additionally in a rebase workflow to get the
> >> useful
> >> history you refer to?
> >
> > Do this:
> cd /tmp
> git clone git://g
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
>
> mjans
> 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 terr
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 d
On 16/02/2011, Stephen Kelly wrote:
> Michael Pyne wrote:
>> Either way is an assumption, but only one of these assumptions involves
>> deliberately discarding data. ;)
>>
>> What specifically do you mean by "creating useful history" though? i.e.
>> what should be done additionally in a rebase wor
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
Ben Cooksley wrote:
>
> Ah, you clearly have no understanding of the damage a "flood" or
> "email bomb" causes.
Correct :)
> Prior to git.kde.org being made available for mainstream use, in the
> 1st generation of hooks, a flood occurred.
>
> This flood completely filled ktown's email queue, pr
On Wednesday, February 16, 2011 22:31:31 Stephen Kelly wrote:
> > An easy way to solve duplicates is to disable sending commit mails for
> > branches other than master, but I personally dislike that solution as
> > it
> > would result in mailing lists like #kde-commits not receiving any
> > emails
On Thu, Feb 17, 2011 at 10:31 AM, Stephen Kelly wrote:
> Michael Pyne wrote:
>
>> An easy way to solve duplicates is to disable sending commit mails for
>> branches other than master, but I personally dislike that solution as it
>> would result in mailing lists like #kde-commits not receiving any
Michael Pyne wrote:
> An easy way to solve duplicates is to disable sending commit mails for
> branches other than master, but I personally dislike that solution as it
> would result in mailing lists like #kde-commits not receiving any emails
> until the branch is fully landed on master. (I hate t
Aaron J. Seigo wrote:
> Open questions / topics for further discovery:
>
> * documenting best practices for keeping a topic branch in sync with
> master, keeping in mind that later a merge from the topic branch to master
> needs to be done and the git history sould be kept as clean as possible
A
On Wednesday, February 16, 2011 13:45:46 Stefan Majewsky wrote:
> On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo 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 ter
On Wednesday, February 16, 2011 12:05:51 Raphael Kubo da Costa wrote:
> On Wednesday 16 February 2011 10:58:48 John Layt wrote:
> > # ===[ Subject ]===|
> > # ---[ One line only, short meaningful description to show in logs ]---|
>
> Personally,
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 wha
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 re
On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo 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 up to
> 4.0
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, outstand
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 kde-runt
49 matches
Mail list logo
