On Tuesday 29 April 2014 15:18:55 Mark Gaiser wrote: > On Tue, Apr 29, 2014 at 3:09 PM, Kevin Ottens <er...@kde.org> wrote: > > Hello, > > > > On Tuesday 29 April 2014 14:33:12 Harald Sitter wrote: > >> On Sun, Apr 27, 2014 at 3:15 PM, David Faure <fa...@kde.org> wrote: > >> > * Everything is developed in master, so each release will contain a > >> > few > >> > new features and bugfixes; > >> > > >> > Of course, going with this type of cycle comes with some price of its own: > >> > * Features in released modules can only be introduced in a very fine > >> > grained way so as to not jeopardize the stability; > >> > >> I suspect that's bad wording, but those two things sound contradicting to > >> me. > > > > IMO, it makes more sense if you reintroduce some of the context: > >> > * CI should be always green, breakages should be treated as stop the > >> > line > >> > events (all commits following a breakage should only be to try to get > >> > things back to normal); > >> > * There should be a strong focus on automated tests and peer review: > >> > all > >> > modified code should come with corresponding tests; if you got a > >> > framework > >> > which is low on test coverage because of its architecture it's likely > >> > time > >> > to focus on the tooling and test harnessing. > >> > >> If everything is developed in master (i.e. features are not developed > >> in a feature branch and then merged into master) but features mustn't > >> affect the stability, how do you ensure latter if someone develops a > >> feature locally (alas, no feature branch on git.kde.org) and then > >> pushes at any day (since there is no feature freeze)? > > > > Because of the above: thin slices, all peer reviewed, all with automated > > tests (slightly oversimplifying since we can't have 100% coverage, but > > that's what we're aiming). > > > > In more words, having those constraints push people toward not making > > large > > feature branches be it online (git.kde.org) or locally. Or if they do so > > nonetheless, each of the commits will have to be reviewed separately > > anyway > > and will have to be small (baby steps) and with automated tests. > > > > That means features will enter gradually and not in a big bang fashion as > > we usually do (via large commits or merge commits). What we're after by > > doing that, is earlier exposure and testing by the other developers, > > discussion generated in turn, and each step destabilization risk should > > be lower. > > > > That's basically more discipline required. > > > > Hope that clarifies. > > > > Regards. > > -- > > Kévin Ottens, http://ervin.ipsquad.net > > > > KDAB - proud supporter of KDE, http://www.kdab.com > > > > > > _______________________________________________ > > release-team mailing list > > release-team@kde.org > > https://mail.kde.org/mailman/listinfo/release-team > > I asked a few folks the same question, but i might as well ask it on the > list. Why don't we simply introduce a "merge window" like the kernel.
Because our community structure has nothing to do with the kernel. A good way to see that is that we struggle to get any of our feature branches tested by lack of contributors. Unlike ours, kernel feature branches get a lot of testing prior to merges. We just happen to be way smaller in head count while having a similar amount of code in the whole community. > How i see it is as follows: > > 1. The first week (first 7 days) of each month is the merge window. > 2. Features that are merged should already be heavily tested before it > makes it's way in. We've been constantly failing that for years now. > 3. The rest of the month is stabilizing. And that too we've been failing at, developers keep playing in their development branches instead of stabilizing. > 4. followed by a release at the end of the month. > > Just wondering... since the kernel approach seems like a really good > one for short release cycles. But we're not the kernel, so we're going for something different. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team