<div dir="ltr"><div><div><div><div>Btw, I think I can add two points about merging the feature branches:<br><br></div>1) When the branch is considered complete, publish a phabricator diff, generated with:<br><br></div>git diff master author/feature-branch<br><br></div>That will allow people comment on the changes it introduces and do a discussion in a single place.<br><br></div>2) When the review request is accepted, the branch should be *merged* into master, *not* squashed. Unless there is a really strong cause for squashing.  Squashing the merges breaks the history of the project, so that one cannot use 'git blame' to find out why a specific line of code was introduced and, therefore, to maintain this code properly.<br><div><div><div><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 14, 2016 at 3:18 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 14 Jul 2016, Friedrich W. H. Kossebau wrote:<br>
<br>
> Sounds good to me as by-stander.<br>
><br>
> Just one thing I wonder: what about fix-up releases with little or big fixes<br>
> to new features or regressions, which are only uncovered after the release,<br>
> once the big user crowds have done the real world mass testing? Delaying those<br>
> 6 weeks as well, until the next release, might be working against an idea of<br>
> getting things out quickly to the users.<br>
><br>
> Thus I propose to consider adding a small time-window after the big release,<br>
> say 1 week, at the end of which there would be a fix-up release (perhaps only<br>
> if needed), and only then open the merge window.<br>
><br>
<br>
</span>If a fix is really, really, really urgent, we can do that, and do a 3.0.1.1, for<br>
instance. But if we'd want to have a week between release and merge window,<br>
then that would cut the stabilization/translation phase back to 3 weeks -- and<br>
we'd be doing something wrong if there would be a fix suddenly necessary after<br>
the four weeks of testing.<br>
<br>
After all, after the merge windows close, we'd make dev builds for all OS'es<br>
that people can test.<br>
<span class="im HOEnZb"><br>
--<br>
Boudewijn Rempt | <a href="http://www.krita.org" rel="noreferrer" target="_blank">http://www.krita.org</a>, <a href="http://www.valdyas.org" rel="noreferrer" target="_blank">http://www.valdyas.org</a><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Dmitry Kazakov</div>
</div>