On Sunday, July 14, 2013 15:23:46 David Faure wrote: > On Friday 12 July 2013 17:07:13 Aaron J. Seigo wrote: > > we ought to think of ways to make master more stable. > > Exactly. And porting master to qt5/frameworks definitely doesn't make it > more stable, so let's not do that. > > (Yes, I'm mixing both topics, because I see contradictory arguments from the > same person in both threads ;)
Context is important. When developing the 4.x series, we have something that would benefit from broader testing and usage and which can quite realistically be developed in such a manner. So a “keep master stable at all times” strategy makes every bit of sense. During the Qt5/Frameworks 5 port of kde-workspace, that branch will not be called ‘master’, but KDE/4.11. The rest is semantics: the KDE/4.11 branch becomes the “master” branch for 4.x for kde-workspace from that point forward. During the Frameworks 5 port, the stability goal for master will initially be for the developers doing that work (or who would like to), and then later for early adopter testers and then eventually widespread use. During each of those phases, we will strive to keep master stable for the audience it is addressing. Using master for porting to Frameworks 5 allows us to minimize later work by clearly defining which branches can drift from that development in which ways. We will strive tot keep that master branch as usable as possible during that porting, however; e.g. the use of topic branches for the porting tasks will help us keep master in a sane state during that process. When looking at the needs and requirements of * a stable release series * a major porting effort / devel cycle things do not work identically. Trying to compare statements made in those two contexts will lead one to find that some statements can not be applied with equal accuracy to both contexts. It’s like being surprised that there are differences in the safety precautions taken when driving a car or flying an airplane, despite both being ways of getting from point A to point B. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.