On Thursday, September 29, 2011 04:19:32 Sven Langkamp wrote:
> On Wed, Sep 28, 2011 at 11:09 AM, Cyrille Berger Skott
>
> <cber...@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 kimages...@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.
While you are right in principle, I don't think we should work with merge
windows before our first release. We're currently in fix-as-much-of-the-UI-
as-possible-before-the-release mode, and of course also fixing other bugs.
Things will be different after the release of 2.4 is done.
-Inge
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
