--===============0425610961467383687== Content-Type: multipart/alternative; boundary=001a1147c9ae3fb9db0537aaacf7 --001a1147c9ae3fb9db0537aaacf7 Content-Type: text/plain; charset=UTF-8 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 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 --001a1147c9ae3fb9db0537aaacf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Btw, I think I can add two points abou= t merging the feature branches:

1) When the branch is consider= ed complete, publish a phabricator diff, generated with:

git d= iff master author/feature-branch

That will allow people commen= t on the changes it introduces and do a discussion in a single place.

2) When the review request is accepted, the branch should be *merge= d* into master, *not* squashed. Unless there is a really strong cause for s= quashing.=C2=A0 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.

<= div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 3:18 PM, Boudewijn Rempt = <boud@valdyas.org> wrote:

<= span class=3D"">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 rel= ease,
> once the big user crowds have done the real world mass testing? Delayi= ng those
> 6 weeks as well, until the next release, might be working against an i= dea of
> getting things out quickly to the users.
>
> Thus I propose to consider adding a small time-window after the big re= lease,
> say 1 week, at the end of which there would be a fix-up release (perha= ps 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 win= dow,
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 necessar= y 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

--001a1147c9ae3fb9db0537aaacf7-- --===============0425610961467383687== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KS3JpdGEgbWFp bGluZyBsaXN0CmtpbWFnZXNob3BAa2RlLm9yZwpodHRwczovL21haWwua2RlLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2tpbWFnZXNob3AK --===============0425610961467383687==--