Adopting the Linux/Firefox/Chrome release strategy

[Dmitry Kazakov]

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 at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>



-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20160715/53bc4c0b/attachment.html>