[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Beta 2 tagging delay
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2011-09-29 2:19:32
Message-ID: CAAmsBfnn3UikyzRcCKv0OtfmHajkyEHYNMxxRbf+6i73JT+d2w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Sep 28, 2011 at 11:09 AM, Cyrille Berger Skott
<cberger@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@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.
[Attachment #5 (text/html)]
<div class="gmail_quote">On Wed, Sep 28, 2011 at 11:09 AM, Cyrille Berger Skott <span \
dir="ltr"><<a href="mailto:cberger@cberger.net">cberger@cberger.net</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im">On Wednesday 28 September 2011, \
Boudewijn Rempt wrote:<br> > On Wednesday 28 September 2011 Sep, Cyrille Berger \
Skott wrote:<br> > > Hi,<br>
> ><br>
> > I generally oppose the idea of delaying a beta for quality reason, \
there<br> > > is always an important bug that is going to be fixed the next day \
of the<br> > > tagging.<br>
><br>
> Of course. Let's make it more generic then: I propose that we will tag \
in<br> > future always on Monday, not Friday, because the weekend is when most<br>
> people have time to work on fixing things and preparing for tagging.<br>
</div>And that is exactly why we tag on Friday :) So that packagers have time to<br>
work on their packages during the week-end...<br>
<br>
And really, missing a beta is not a big deal, there is an other beta coming in<br>
three weeks. Unless you break your application... but that *should* *not*<br>
happen.<br>
<div class="im"><br>
> > On Tuesday 27 September 2011, Sven Langkamp wrote:<br>
> > > the recent merge of the strokes framework branch has introduce a \
number<br> > > > of problems in Krita.<br>
> ><br>
> > I guess by recent, you mean since the begining of the beta period ? In<br>
> > which case, can I ask why something that break krita to point of making<br>
> > it totally unusable was merged before the issues get solved ?<br>
><br>
> I made that decision. We needed the merge because other people were waiting<br>
> with their bugfixes for the merge to happen.<br>
</div>git checkout -b krita-fixyourbugshere<br>
sendmail <a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a> "For the \
time being use the 'krita-fixyourbugshere'<br> branch to collectively fix \
your bugs so that we don't break master too much"<br> <br>
And then you can merge all sort of things in "krita-fixyourbugshere", \
without<br> affecting master. Branches in git are *cheap*, for everyone. And if all \
the<br> krita devs are working on that branch, you should not get conflicts when<br>
merging back to master.<br>
<br>
If we really want to move to a more agressive release schedule (ie 3 or 4<br>
monthes), we need to make the best out of git features.<br></blockquote><div><br>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. <br> </div></div>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic