>
> limiting this feature to trunk _only_ patches? If so, that seems rather
> weak.
It's definitely a weaker guarantee. On the plus side, if we're doing bugfix
only to all released branches and limiting improvements and new features to
trunk, in theory those will be the more disruptive patches tha
Does this work with trunk patches that involve other branches as well? I’d
imagine we have the same problem. Or are we proposing limiting this feature to
trunk _only_ patches? If so, that seems rather weak.
From: Brandon Williams
Date: Thursday, 9 December 2021 at 20:25
To: dev@cassandra.apache
Good with all the above (reasonable arguments) except I don't understand:
>
> I find it cleaner that work is found associated to one sha on the hardest
> branch, and we treat (or should be) CI holistically across branches.
If we -s ours and amend merge commits on things that straddle stuff like
80
+1 to trying trunk first.
On Thu, Dec 9, 2021 at 1:52 PM Mick Semb Wever wrote:
>
> >
> > So let me pose the question here to the list: is there anyone who would
> > like to advocate for the current merge strategy (apply to oldest LTS, merge
> > up, often -s ours w/new patch applied + amend) inst
+1 on Mick’s suggestion (nb)
On Thu, 9 Dec 2021 at 14:46, Mick Semb Wever wrote:
> >
> > So let me pose the question here to the list: is there anyone who would
> > like to advocate for the current merge strategy (apply to oldest LTS,
> merge
> > up, often -s ours w/new patch applied + amend) i
>
> So let me pose the question here to the list: is there anyone who would
> like to advocate for the current merge strategy (apply to oldest LTS, merge
> up, often -s ours w/new patch applied + amend) instead of "apply to trunk
> and cherry-pick back to LTS"?
I'm in favour of the current merge
On Tue, Dec 7, 2021 at 11:13 AM Joshua McKenzie wrote:
>
> I'd frame the reasoning differently: Our current merge strategy is
> vestigial and we can't rely on it in many, if not most, cases. Patches
> rarely merge cleanly across majors requiring -s ours w/amend or other
> changes per branch. This
I am building another secondary index implementation and am wondering if it
is possible to create two SSTable for the one index. I assume I would
create two IndexCfs using the baseCfs for the table as shown in
org.apache.cassandra.index.internal.CassandraIndex.indexCfsMetadata() but
would have to
