On Fri, May 20, 2011 at 4:48 AM, Stephen Kelly 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 of
>> th
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 al
On Thursday, 19 de May de 2011 22:30:35 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 af
On Thu, May 19, 2011 at 10:22 PM, Thiago Macieira wrote:
> 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.
>>
>
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 re
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 is
not inflated?
> - Requires some Git magic to recover if the
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
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.
> Pl
On Thursday, 19 de May de 2011 20:20:13 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.
> - Requires some Git magic to recover if the branch you are currently
> using gets force pushed.
On Thursday, 19 de May de 2011 10:11:04 Boudewijn Rempt wrote:
> In Calligra, we sort of discussed that we might call the staging branch
> where everyone can commit "master", and that we'll try to get an automated
> system to copy commits that didn't break unittests to the release branch,
> which o
2011/5/19 Aaron J. Seigo :
> 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 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
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 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:
http://techbase.kde.org/Development
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
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 atten
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 Tue, May 17, 2011 at 1:16 PM, Fredrik Höglund 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
On 05/17/2011 05:52 PM, 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.
The best wa
> 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
o
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
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
Testing.
If everyone is working on branches on cool new stuff, the release will be crap.
On 5/17/11, Alexis Ménard 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 like
> "Fre
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 g
24 matches
Mail list logo
