> > but by committing to reserving trunk for stabilizing changes until the > beta, we focus our effort on polishing and delivering the release.
No, committing to testing, bug fixing, and validating focuses our effort on polishing and delivering the release. Committing to reserving trunk for stabilising changes doesn't actually do anything. We could reserve trunk and no one could ever commit a single patch to it, or we could reserve trunk and everyone continues working on features. Whatever we do to trunk doesn't have any impact on how our attention is directed. Granted, you could argue that there is some great beneficial psychological aspect and having no feature branch will make everyone suddenly start working on bug fixes, but to people this actually affects (committers), it's not going to mean much to them. They are either already going to be motivated and tasked with getting 4.0 out the door, or they are going to do their own thing. I'm fairly positive that better communication around the release, and progress towards the release would be a better motivator. And it would go further to getting new contributors (who definitely don't care about the branches) involved, because anyone on the ML could see progress getting made and be a part of any call to arms. But at the end of the day, bikeshedding about this is not important. This is one of those issues which someone should just stand up and say "We're doing it this way because I said so", because either way, it really doesn't matter and the impact is going to be minimal, so we may as well get on with our lives. On 4 July 2018 at 04:06, Scott Andreas <sc...@paradoxica.net> wrote: > Here’s why I really like this proposal: > > – It focuses our thought and effort on what it’ll take for each of us to > become confident in running Apache Cassandra 4.0 for our most critical > applications *prior* to cutting the dot-zero release. > – It marks a commitment we can make to our user community: delivering > 4.0’s featureset with safety and stability is our top priority. > – There are many different perspectives each contributor can bring: > correctness, performance, durability, automation, documentation, > operational safety, etc; and many ways to gain confidence in each – perf > tests, profiling, shadow writes/traffic mirroring, diff tests, replay > tests, fuzz tests, fault injection, chaos engineering, and so many others. > By bringing diverse methods to bear on the same class of problem (quality), > we’re more likely to identify issues that could impact our users and to > ship a better release. > – It’s disciplined and courageous! > > Here’s why I think this won’t discourage new contributors from joining – > in fact, the opposite: > > – It provides a very simple step that any contributor can take toward > shipping 4.0: running it. > – We raise spirits by delivering enhancements the community has been > working on for two years rather than fracturing our attention. > – If members of the community are interested in post-4.0 work, they’re not > blocked from making progress toward that – but it’s not the focus, and > unlikely that review bandwidth would be available given that focus. I agree > with Kurt’s note that nobody can be “forced" to do anything - but by > committing to reserving trunk for stabilizing changes until the beta, we > focus our effort on polishing and delivering the release. > > On the last question: > > On another note, we are still planning on accepting/reviewing bug fixes > for previous versions as well correct? > > I’d expect so – and to take it a step further, it’s likely that this rigor > will result in us identifying serious issues that were not regressions in > 4.0 warranting backports. As with any investment in testing / validation, > I’m hoping we do … but also hoping we don’t. :-) > > > > On Jul 3, 2018, at 7:21 PM, kurt greaves <k...@instaclustr.com> wrote: > > > > tl;dr: +1 for committing to testing + bugfixing after feature freeze, > but I > > can't really see how changing the branching strategy is going to have any > > impact at all. > > > > I really don't think it's a big deal. People will work based on whatever > > priorities they've been assigned, regardless of what you do to the > > branching. That's essentially just red tape and adding unnecessary > > complexity to an already established process. Granted, you'll have to do > > one less merge, but it should be an effortless merge, and it saves there > > being any confusion about what people should do with features. If someone > > decided to commit a feature, they could, and we wouldn't have to be all > > over every ticket making sure people don't commit things that shouldn't > be > > committed. > > > > Cutting to the point, all we're really aiming for here is a commitment > from > > the community to only dev on bugfixes, only review bugfixes, and > > testing/validation during the freeze period. That's not going to be > > enforced by a change in branching strategy, it's going to be enforced by > > the contributors themselves (and their respective priority-setters). > > The best we can do is encourage a commitment to testing and bugfixing for > > the freeze period. This is a volunteer based project after all, so we > can't > > really force anyone to do anything. If contributors make proposals for > > features in the freeze period we can just tell them that there is a focus > > on 4.0 testing and it's unlikely to be reviewed until 4.0 is released at > > best. > > > > On another note, we are still planning on accepting/reviewing bug fixes > for > > previous versions as well correct? Just to clarify because it doesn't > seem > > to be mentioned here and we don't want people getting in arguments over > > reviewing patches that only affect older releases. > > > > I think not having your patch reviewed for months is more > >> discouraging than following the community and helping with stability of > >> 4.0. > > > > Patches not getting reviewed for months on end already occurs. Changing > how > > we branch isn't going to change this or make anyone feel better about it. > > The best we can do is communicate why their patches aren't getting > > reviewed, and we should be doing this on individual feature tickets that > > get raised and on the ML. > > > > On 4 July 2018 at 00:44, Mick Semb Wever <m...@thelastpickle.com> wrote: > > > >>> > >>> > >>> We propose that between the September freeze date and beta, a new > branch > >>> would not be created and trunk would only have bug fixes and > performance > >>> improvements committed to it. > >>> > >> > >> > >> +1, like really yes!! because it's a step towards a more stable-master > >> project. > >> > >> If trunk is focused on stabilising (which ideally it shouldn't have to, > if > >> stable-master were true) then new features remaining in their respective > >> branches shouldn't be a big cost or risk (nor seen as anything > negative). > >> And hopefully any additional practices/lessons learnt from during the > >> freeze period get carried on for good. > >> > >> Although, and unfortunately, there's just not the testing infrastructure > >> available to the public to ensure feature branches are solid before > >> merging. But I struggle to see that as an excuse to only "stabilise" on > >> release branches. > >> > >> 2¢, > >> mick > >> > >
