Hi Apollon, first, thank you for your feedback.
On Thu, Oct 02, 2014 at 09:21:58PM +0300, Apollon Oikonomopoulos wrote: > Hi Willy, > > On 19:18 Thu 02 Oct , Willy Tarreau wrote: > > So my question is : what do you think about the current maintenance > > release frequency ? Do you think we should release more often, which > > also means that some people might upgrade for no good reason, or get > > used to miss versions ? Do you think that instead we should simply > > consider that when someone asks for a release here on the list, it's > > likely the good time for it ? > > As you stated, currently there are two distinct release modes, driven by > different needs: > > - Security vulnerabilities/major bugs - the event-driven release mode: > I think everyone will agree that in these cases a release should be > as immediate as possible. Sure. > - Medium/minor bugs - the "never-important-enough-to-warrant-a-release" That's probably the best way to describe it, indeed! > mode: These tend to pile up in a long queue of commits and wait until > either someone asks for a release, or something bad happens. > However, even if these fixes are really not that serious, they do fix > existing problems. Furthermore, usually someone has complained about > these problems and possibly more people have experienced them but not > bothered to report them and most of those affected would like to see > them fixed in a reasonable amount of time without cherry-picking > commits from git themselves. Yes, good point. > Note that the combination of a long number of unreleased minor fixes > with a forced release due to a major bug has higher chances of exposing > users to undetected regressions since the last release, precisely at the > moment you want all people to upgrade urgently. That's an interesting aspect I had not added to the mix, but you're right and as we've seen with 1.5-dev, releases always come by two : the first one with the new features, and the second one one week later to fix the ugly regressions that remained undetected for 6 months. So indeed, making it easier for users to upgrade more often can bring some benefits. > IMHO, with the 1.5 series being maintenance-only (i.e. no new features) > I think we can apply a time-based rule specifying an upper limit, > something like "release on the 15th of every month" (or the 1st Monday), > as long as there is something to release of course. Yes, that could be something like this. I just don't want the date to become too strict because flexibility is convenient for everyone. I was also thinking about scripting something to indicate the cost of not releasing a set of fixes. In short, a minor bug counts as 1, a medium bug counts as 3, a major bug counts as 10, and a critical one as 30. We sum everything seen since last release and get a score. If the total exceeds 20, a release is needed. Otherwise just check the date since last release. > It's probably > tempting to consider schedules like "release before the oldest > unreleased git commit is 1 month old", Interesting view, more accurate than considering the last release indeed. > but I think it's essential to > stick to a schedule easy to remember (by adding a periodic reminder) and > difficult to prolong e.g. by waiting for 2 weeks without bugs. Unless commit hooks tell me "Hey, now's time to release" :-) > By the way, we are approaching the Debian freeze, due on Nov 5, which > means that I would be really happy to see a release by Oct 15. That > said, I was about to put on the "that guy who asks for a release" hat > :-). *This* is a very good reason. I have something to check with Emeric and depending whether we can address it quickly or not, I'll plan a release soon then. And you, the distro maintainers, should not be shy about this. I'm serious. We (haptech) try to push a release before our own major releases of ALOHA for the very same reason. We all know how annoying it is to have the first version of a package in a new release starting with a ton of patches, while we feel "clean" when all patches are added only after the release. So do not hesitate to harrass me if you don't see 1.5.5 in a few days. Thanks for your insights, Willy
