Beta 2 tagging delay

[Sven Langkamp]

On Wed, Sep 28, 2011 at 11:09 AM, Cyrille Berger Skott
<cberger at cberger.net>wrote:

> On Wednesday 28 September 2011, Boudewijn Rempt wrote:
> > On Wednesday 28 September 2011 Sep, Cyrille Berger Skott wrote:
> > > Hi,
> > >
> > > I generally oppose the idea of delaying a beta for quality reason,
> there
> > > is always an important bug that is going to be fixed the next day of
> the
> > > tagging.
> >
> > Of course. Let's make it more generic then: I propose that we will tag in
> > future always on Monday, not Friday, because the weekend is when most
> > people have time to work on fixing things and preparing for tagging.
> And that is exactly why we tag on Friday :) So that packagers have time to
> work on their packages during the week-end...
>
> And really, missing a beta is not a big deal, there is an other beta coming
> in
> three weeks. Unless you break your application... but that *should* *not*
> happen.
>
> > > On Tuesday 27 September 2011, Sven Langkamp wrote:
> > > > the recent merge of the strokes framework branch has introduce a
> number
> > > > of problems in Krita.
> > >
> > > I guess by recent, you mean since the begining of the beta period ? In
> > > which case, can I ask why something that break krita to point of making
> > > it totally unusable was merged before the issues get solved ?
> >
> > I made that decision. We needed the merge because other people were
> waiting
> > with their bugfixes for the merge to happen.
> git checkout -b krita-fixyourbugshere
> sendmail kimageshop at kde.org "For the time being use the
> 'krita-fixyourbugshere'
> branch to collectively fix your bugs so that we don't break master too
> much"
>
> And then you can merge all sort of things in "krita-fixyourbugshere",
> without
> affecting master. Branches in git are *cheap*, for everyone. And if all the
> krita devs are working on that branch, you should not get conflicts when
> merging back to master.
>
> If we really want to move to a more agressive release schedule (ie 3 or 4
> monthes), we need to make the best out of git features.
>

For faster releases you need something like the merge windows for the
kernel. The problem is that when merge happen to close the beta release, we
get lots of bug reports that are not needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20110929/eafd42e1/attachment.html>