On Wednesday, May 18, 2011 22:08:00 Alexander Neundorf wrote:
From my side, I would strongly prefer to have one policy which is used at
least for all of KDE SC, (what was trunk/KDE/ before), if possible also for
kdesupport.
agreed. and in working on this:
On Thursday 19 May 2011 Aaron J. Seigo wrote:
http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Workf
low
Wow. This is a pretty complex workflow, and it's breaking with quite some
practices KDE used to use for a very long time. We have to make sure that we
don't leave
On Thursday 19 May 2011 May, Cornelius Schumacher wrote:
On Thursday 19 May 2011 Aaron J. Seigo wrote:
http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Workf
low
Wow. This is a pretty complex workflow, and it's breaking with quite some
practices KDE used to use
On Thursday, May 19, 2011 20:20:13 Ben Cooksley wrote:
I see quite a few problems with that workflow:
thanks for the input; i've added some of the core issues you raise to the
Requirements section of the wiki page. this will help us craft something
that fits the actual needs of us all.
On Thursday, May 19, 2011 10:05:27 Cornelius Schumacher wrote:
On Thursday 19 May 2011 Aaron J. Seigo wrote:
http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Wo
rkf low
Wow. This is a pretty complex workflow, and it's breaking with quite some
practices KDE used to use
On Thursday, 19 de May de 2011 11:44:59 Stephen Kelly wrote:
Ben Cooksley wrote:
Second you are heavily advocating rebasing. This shouldn't be done in
public repositories as it:
- Inflates the size of the repository.
I thought git gc which runs periodically would mean that the repo size
Ben Cooksley wrote:
Doesn't apply to KDE repositories, as performing a rebase involves a
force push, which initiates the damage prevention area of our hooks.
This triggers creation of a backup ref protecting the contents of
the old ref from being affected by a gc, and ensures they are always
On Fri, May 20, 2011 at 4:48 AM, Stephen Kelly steve...@gmail.com wrote:
Ben Cooksley wrote:
Doesn't apply to KDE repositories, as performing a rebase involves a
force push, which initiates the damage prevention area of our hooks.
This triggers creation of a backup ref protecting the contents
On Tuesday, May 17, 2011 11:40:30 Alexis Ménard wrote:
fact that you couldn't hack features in the official trunk, people had
to use personal svn branches and now teams like plasma think about
setup integration repos. That sounds weird, you usually use these
personally, i don't care whether
On Wednesday 18 May 2011 12:06:18 Aaron J. Seigo wrote:
i don't want to start this discussion here on this mailing list as i doubt
it will result in anything useful, given the constraints on bandwidth and
opportunity to easily diverge into a thousand sub-topics. let's ensure
this gets
On Wednesday 18 May 2011, Aaron J. Seigo wrote:
...
i don't want to start this discussion here on this mailing list as i doubt
it will result in anything useful, given the constraints on bandwidth and
opportunity to easily diverge into a thousand sub-topics. let's ensure
this gets attention at
Hello,
Not sure this was discussed before but I'd like to bring the topic for
discussion.
Now that KDE moved to git it seems we still have old habits like
Freezing period on trunk (or should I say master branches of each
git repos). That sounds like weird to me when one of the main feature
of
Testing.
If everyone is working on branches on cool new stuff, the release will be crap.
On 5/17/11, Alexis Ménard men...@kde.org wrote:
Hello,
Not sure this was discussed before but I'd like to bring the topic for
discussion.
Now that KDE moved to git it seems we still have old habits
On Tuesday, 17. May 2011. 11.42.41 Maksim Orlovich wrote:
Testing.
If everyone is working on branches on cool new stuff, the release will
be crap.
I don't agree. Freezes just stop the development - it doesn't improve the
bugfixing as much.
The best way (IMO) would be to have all done in
On Tuesday 17 May 2011, Ivan Cukic wrote:
On Tuesday, 17. May 2011. 11.42.41 Maksim Orlovich wrote:
Testing.
If everyone is working on branches on cool new stuff, the release will
be crap.
I don't agree. Freezes just stop the development - it doesn't improve the
bugfixing as much.
It's not just about keeping people focused on fixing bugs, it's about
developers actually running and testing the branch that we're about
to release.
With that I agree. The idea in plasma-world was to keep an always
releasable branch. That is, things get in from the development branches
On Tue, May 17, 2011 at 1:16 PM, Fredrik Höglund fred...@kde.org wrote:
On Tuesday 17 May 2011, Ivan Cukic wrote:
On Tuesday, 17. May 2011. 11.42.41 Maksim Orlovich wrote:
Testing.
If everyone is working on branches on cool new stuff, the release will
be crap.
I don't agree. Freezes
17 matches
Mail list logo
