[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Adopting the Linux/Firefox/Chrome release strategy
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2016-07-15 11:10:56
Message-ID: CAEkBSfU4TgN2PvmHzM1ejdMWZ8khiy1yprz7j_UL+COqRhK4xA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Btw, I think I can add two points about merging the feature branches:
1) When the branch is considered complete, publish a phabricator diff,
generated with:
git diff master author/feature-branch
That will allow people comment on the changes it introduces and do a
discussion in a single place.
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.
On Thu, Jul 14, 2016 at 3:18 PM, Boudewijn Rempt <boud@valdyas.org> wrote:
> On Thu, 14 Jul 2016, Friedrich W. H. Kossebau wrote:
>
> > Sounds good to me as by-stander.
> >
> > Just one thing I wonder: what about fix-up releases with little or big
> fixes
> > to new features or regressions, which are only uncovered after the
> release,
> > once the big user crowds have done the real world mass testing? Delaying
> those
> > 6 weeks as well, until the next release, might be working against an
> idea of
> > getting things out quickly to the users.
> >
> > Thus I propose to consider adding a small time-window after the big
> release,
> > say 1 week, at the end of which there would be a fix-up release (perhaps
> only
> > if needed), and only then open the merge window.
> >
>
> If a fix is really, really, really urgent, we can do that, and do a
> 3.0.1.1, for
> instance. But if we'd want to have a week between release and merge window,
> then that would cut the stabilization/translation phase back to 3 weeks --
> and
> we'd be doing something wrong if there would be a fix suddenly necessary
> after
> the four weeks of testing.
>
> After all, after the merge windows close, we'd make dev builds for all
> OS'es
> that people can test.
>
> --
> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
> _______________________________________________
> Krita mailing list
> kimageshop@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
Krita 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