On 6 October 2015 at 12:22, Gordon Sim <[email protected]> wrote: > On 10/06/2015 11:39 AM, Robbie Gemmell wrote: >> >> I'm all for ensuring we do more releases which this would do, so that >> would be good. I'll admit I'm not a huge fan of the time-based cadance >> on its own though, perhaps the ideal for me would be a similar maximum >> bounding time on more features-based releases, plus point releases >> with fixes as appropriate. >> >> To quote myself from a semi related thread some months ago: >> >> "I think we tend to be guilty of putting everything in together, >> resulting in a big release that can then drag on a bit, making it more >> difficult to respond quickly if the need arises, which in turn makes >> us want to complete the cycle by including yet more stuff into the >> release just to avoid it having to wait around for a while until the >> following release happens." > > > Proton has not had a time-based cadence to-date, yet the situation you > describe has very much been a feature of that component, so I don't think it > is the cadence that is the issue there. >
No it hasnt, its has generally drifted until some point a release actually happened (for whatever reason). That can be fine if it is frequent enough, much less so if it isnt (which it often hasn't been). The time based release should clearly help avoid the 'not frequent enough' case, however I think the same issues I have in mind generally apply with the defined time schedule too, only with reduced impact since the kick off points should be better known in advance. We have missed many of our other timed-based release dates to some degree for largely the same reasons. A general cadence is always there, so it does still have the effect of prompting periodic releases, which is obviously very good, but I still find most of those releases frustrating too. > The most important criteria is that the release plan is clear and open to > anyone interested. > > Personally, I think a time-based approach is a very good and simple way of > achieving that. The alternative is much more open communication around the > work targeted for each release, estimates of the time needed and frequent > updates on status. > > That can certainly be true. While none of that would really be a bad thing, I'm not suggesting that we would attempt to manage things that closely, because I don't honestly think it would actually happen if we did. Really all I'm thinking of is being a bit more adaptive. If after say 2 months of an expected 3 month time box there was a whole load of finished work on master, and someone was about to begin ripping things apart to make 'unrelated major change X', I'd rather we just consider shipping master then, as theres a whole load of finished work only likely to be held up by stuff coming later. If someone were to recognise such a state, perhaps that did the finished work or is about to start the new major work, they might send an email saying 'hey folks, would it make sense to release this existing stuff sooner on its own, then perhaps another release a couple months later with this new stuff', then we could at least have a discussion about doing it. Otherwise, what has tended to happen is that the work goes in, possibly isnt quite happen ready when the time is up, and the release process then drags on as this becomes clearer and things get addressed. Doing more point releases would help too in some regards, less penalty to users waiting for the next release to get fixes to things that werent quite 100% due to hitting a date they probably shouldnt have. If releases are frequent enough or flexible enough that missing them doesnt impose massive penalty, such as neeeding to wait 3 months for the next one, there is much less reason for folks to be concerned about what release their bits actualy go into. The main issue might then be if certain changes need to go in the same release, e.g considering a 'fix/break these things together' grouping, which in the earlier scenario might mean we still decided not to release the earlier stuff yet. Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
