Sorry for the late reply, I somehow missed this message.
Jean-Marc Lasgouttes wrote: > Le 31/05/2016 à 22:26, Georg Baum a écrit : >> We need to decide: Either have a fixed schedule, and an unknown feature >> set of the next release, or a fixed feature set, and an unknown schedule. >> We do not have enough man power for defining both a fixed feature set and >> a fixed release schedule. > > I prefer the fixed schedule. We never know exactly when starting a > release cycle what features will happen or not. But we can enforce when > the release will happen. Makes sense. >> - Have a build server that does automatic builds on a regular basis for >> all three platforms (Linux, OS X, windows) and makes binary packages and >> build logs available. > > Do you have a particular service in mind? I agree that this would be > nifty. No, I have not yet searched, but I am convinced that it pays off to invest some time into that. If we had it for 2.2.0 it could have saved a lot of work and unneeded discussions. >> - (not related to automation) Disentangle unrelated stuff from the >> release. For example, the current way of updating the documentation is >> inefficient. In agile software development you write the documentation of >> a new feature almost at the same time as you implement the fetaure (this >> is one of the good aspects of agile software development). If we do that >> as well we can get rid of a noticeable delay at release time. > > The problem is that we are not very good at writing documentation and we > let Uwe do all this. If he had a small team of documenters to help, life > would be much easier. I am not sure whether we are not good at writing docs. We should simply try how far we get if we encourage everybody to document his new features. Georg
