Could you file a bug report with more detail about which classes you think
> are lacking adequate documentation in each project, and what you would like
> to see?
>
I suggest instead that we open a task ticket for the merge.
I 100% agree with merging work incrementally, under a feature flag, but
>
> … extrapolating this experience to multiple C* versions
>
>
To include forward-merging, bisecting old history, etc etc. that's a leap
of faith that I believe deserves the discussion.
- patches are off submodule SHAs, not the submodule's HEAD,
>
>
> A SHA would point to the HEAD of a given bran
Benedict, experience based on developing one feature against one branch doesn't face the problems of working, and switching frequently, between branches.Mick, please take a look at the ongoing development. Over the last week I have been actively developing five separate PRs against each repository
> - permanence from a git SHA no longer exists
>
> With the caveat that I haven't worked w/submodules before and only know
> about them from a cursory search, it looks like git-submodule status would
> show us the sha for submodules and …
>
That isn't one SHA, but a collection of SHAs.
I'm thin
We have a build script that is invoked by ant to grab a specific SHA (or HEAD of a branch). We were previously just grabbing HEAD but this has the problems mentioned elsewhere in the thread, amongst others. I don’t think it probably matters much if we use a build script or submodules.I am driven in
Hi Benedict
At least for my part, again, I'm not (yet) trying to argue for or against
a particular alternative. So I think you'll find that if you allow a few
more iterations of discussion, we can gravitate to some good consensus. Or
failing that, we can at least gravitate around a small number o
Could you file a bug report with more detail about which classes you think are lacking adequate documentation in each project, and what you would like to see? We would welcome your participation.On 16 Jan 2023, at 17:28, Jacek Lewandowski wrote:Hi,It would be great if some documentation got added
Hi,
It would be great if some documentation got added to the code you want to
merge. To me, it would be enough to just quickly
characterize on the class level what is the class for and what are the
expectations. This is especially important for Accord API
classes because now it is hard to review w
That’s fair, though for long term contributors probably the risk is relatively low on that front. I guess that’s something we can perhaps raise as part of each CEP if we envisage it taking several months of development?> Did we document this or is it in an email thread somewhere?It’s probably burie
How often have we modified Paxos? There are currently no proposals to develop Accord further after the initial release. So I think it is very likely that Accord development will decouple from Cassandra version, unless there is significant external interest that drives it.Furthermore, the idea of re
My only concern to merging (given all normal requirements are met) would be if there was a possibility that the feature would never be finished. Given all of the excitement and activity around accord, I do not think that is a concern here. So I see no reason not to merge incremental progress behind
Did we document this or is it in an email thread somewhere?
I don't see it on the confluence wiki nor does a cursory search of ponymail
turn it up.
What was it for something flagged experimental?
1. Same tests pass on the branch as to the root it's merging back to
2. 2 committers eyes on (author
Hi all
I was invited to share my thoughts just as an additional and somewhat fresh
point of view...
On a high level: We talked through this with Mick and a few other
colleagues, and I/we came to the conclusion that fundamentally all of the
mentioned options 1-5 are just variations of the same pro
My goal isn’t to ask if others believe we have the right to merge, only to
invite feedback if there are any specific concerns. Large pieces of work like
this cause headaches and concerns for other contributors, and so it’s only
polite to provide notice of our intention, since probably many haven
I haven’t been following the progress of the feature branch, but I would think
the requirements for merging it into master would be the same as any other
merge.
A subset of those requirements being:
Is the code to be merged in releasable quality? Is it disabled by a feature
flag by default if n
> - permanence from a git SHA no longer exists
With the caveat that I haven't worked w/submodules before and only know about
them from a cursory search, it looks like git-submodule status would show us
the sha for submodules and we could have parent projects reference specific
shas to pull for
Stefan,
Thank you for bringing this topic up. I'll prepare the PR shortly with
option 4, so everyone can take a look at the amount of changes. This
does not force us to go exactly this path, but it may shed light on
changes in general.
What exactly we're planning to do in the PR:
1. Checkstyle A
I guess option 5 is what we have today in cep-15, have the build file grab the
relevant SHA for the library. This way you maintain a precise SHA for builds
and scripts don’t have to be modified.
I believe this is also possible with git submodules, but I’m happy to bake this
into our build file
Based on the voting we should go with option 4?
Two weeks passed without anybody joining so I guess folks are all happy with
that or this just went unnoticed?
Let's give it time until the end of this week (Friday 12:00 UTC).
Regards
From: Maxim Muzafaro
>
> I think (4) is the only sensible option. It permits different development
> branches to easily reference different versions of a library and also to
> easily co-develop them - from within the same IDE project, even.
>
I've only heard horror stories about submodules. The challenges they bring
Those of us who have developed the in-jvm-dtest-api will know that the
project’s approach to developing libraries is untenable for more complex
projects. Accord makes this a pressing concern, but we would also benefit from
separating utilities to their own library for use by the dtest-api and Ac
Hi Everyone, I hope you all had a lovely holiday period.
Those who have been following along will have seen a steady drip of progress
into the cep-15-accord feature branch over the past year. We originally
discussed that feature branches would merge periodically into trunk, and we are
long ove
What does this mean for the Trie sstable format?
Would it perhaps make sense to version the sstable upgrader (and future
downgrader) based on the highest version they understand? for example
sstableupgrader version N will handle the n? versions so it can upgrade
from m? while sstabledowngrader ve
23 matches
Mail list logo
