Hi Kurt,
Thank you for your feedback. I am reading your comment as +1 on
the idea of working on making a solid release but +0 on branching model. Is
that correct?
Thanks,
Sankalp
On Tue, Jul 3, 2018 at 10:09 PM kurt greaves <k...@instaclustr.com> wrote:
> >
> > 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
> > >>
> >
> >
>
