On Monday 08 July 2013 16:26:00 laurent Montel wrote: > Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : > > Hi, > > > > 2013/7/8 Àlex Fiestas: > > > Now that kde-workspace and kdelibs are going to be frozen (which in > > > theory > > > means less work for everybody) I'd like to propose a new release > > > schedule > > > to be applied starting with 4.12. > > > > > > Basically the idea is to cut testing time and compensate it by keeping > > > master always in a "releaseable" state, now that two major components > > > are > > > frozen it looks like it is a good time to get used to it. > > > > > > You can read all the proposal in: > > > http://community.kde.org/KDE_Core/ReleasesProposal > > > > > > Before sending this email I have checked with distro people, i18n > > > people, > > > other developers and almost all of them seemed to either like or be > > > neutral > > > about it (only one exception :p) so I hope that the proposal is not a > > > complete disaster. > > > > > > As its name indicates, it is a proposal, so please be constructive in > > > the > > > feedback, we can change as many things as we need. > > > > I like the idea (from the Dolphin development point of view). Most of > > the changes that went into master during the past months had already > > been tested rather well before they were merged, and the remaining > > regressions were found rather quickly by people who use the master > > branch a lot. Therefore, it would have been nice if some of the > > improvements could have been shipped to users sooner - quite a few > > bugs that had been fixed in master (with patches that were IMHO too > > intrusive for the 4.10 branch) months ago were reported again and > > again. > > > > @Laurent:you say that you have "a lot of features to implement", and > > that this would not be possible with a shorter release schedule. But > > wouldn't it be possible to implement some of the features for the next > > version and the rest for the one after that? > > > > If you think that you > > need more time to stabilize a feature in the master branch, then maybe > > developing the feature in a separate branch and merge it once it's > > finished might be a good idea? > > No it’s not a good idea because nobody tests branch you can see pb that we > had when we merge akonadi branch (last big changes).
It is true that we have a problem with getting people to test branches. But this problem is independant from the release schedule: I believe developing in branches is a good way to work, no matter if releases are created every 3 or 6 months. Having said so, I think Akonadi is a bad example because: - It was a huge change, quite the equivalent of a rewrite - It was affecting personal data When we develop a new feature and want to get more testing, we need to get people to know about it so that they are interested in testing it. If I create a feature but nobody knows about it, it won't get much testing, whether it is in master or on a topic branch. If the feature is developed in master, I have to be careful not to introduce any regression in the existing code before I push any commit, I cannot rely on my group of interested people to spot it because they can't test my work before it reaches master. At feature-freeze time, if my feature is not ready, it is often impossible to revert because the history is mangled with the rest of the work done in master. Furthermore I don't want to revert because it would make me wait for 6 months! If the feature is developed in a topic branch, I should still be careful not to introduce regressions, but I have an extra safety net before it reaches master and can affect people who are not involved in testing my feature. Having it in a branch also gives me a way out: if it turns out the feature is not ready in time for release N, it is possible for me to revert the "integration commit" (because it has been merged in with "--no-ff" [1]) and post-pone the feature for the next release. I am still frustrated, but it's not so bad with this new schedule because release N+1 is only 3 months away. I like this new schedule because it should reduce the more-or-less subconscious behavior of "let's commit this in master before feature-freeze, it's half broken but I need to commit it now otherwise Albert^Wthe release team is going to (rightfully) yell at me! it's no problem I have more than enough time to fix it before release" (famous last words...) Aurélien [1] http://nvie.com/posts/a-successful-git-branching-model/ , section "Incorporating a finished feature on develop"