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.
In addition I would suggest the following: (Officially) allow new
features that do not require a file format change into minor releases.
The main reason is again that this allows testing more regularly. For
instance, in my case, I can use a development version in my work, but
only if the file format is the same.
Unfortunately it also means we force all users to test these new features.
Yes, I think that having nightlies would be more efficient than that.
- Automate windows installer generation. This would probably mean to switch
to mingw, since we can do both a mingw build and run nsis from a linux
machine.
Yes.
- 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.
- Run tests automatically, using the binaries from the build server, make
test results available.
Sure. Not difficult once we have the nightlies.
- (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.
- (not related to automation) Set bug targets more realistically. This
avoids massive retargeting (with related discussions), and gives a better
picture what needs to be done for the release.
We are not good at bug targets, except when the patch is almost done. I
am not sure that we can improve much on that. We cannot force people to
work on a bug, unfortunately.
JMarc
