I'll get this into a draft article on the wiki so we can collab on those 3
outstanding TBD's without further cluttering up the dev list. :)
On Fri, Dec 17, 2021 at 11:38 AM Ekaterina Dimitrova
wrote:
> It’s indeed good call but I thought this will be addressed in a separate
> document where we d
It’s indeed good call but I thought this will be addressed in a separate
document where we discuss required test suites to be run pre-commit. If not
- then I guess we should add those things here too?
On Fri, 17 Dec 2021 at 11:36, Joshua McKenzie wrote:
> Good call; thanks for the reminder.
>
>
Good call; thanks for the reminder.
So maybe add a
3.a: Run all new or modified tests through either local or remote
multiplexer N (TBD - 50?) times (w/link to instructions, etc)
3.b Non-regressing is defined here...
3.c After merging tickets...
On Fri, Dec 17, 2021 at 11:29 AM Brandon Williams
Could we also add something about running new tests through the multiplexer?
On Fri, Dec 17, 2021 at 10:23 AM Joshua McKenzie wrote:
>
> So to clarify it all in one place, the proposed new CI process we should
> test for consensus is:
>
> 1. Canonical CI for a release is ci-cassandra. We can opti
So to clarify it all in one place, the proposed new CI process we should
test for consensus is:
1. Canonical CI for a release is ci-cassandra. We can optionally, and in
practice will, run circle as well but don't codify blocking on that.
2. (NEW) We don't release unless we get a fully green run.
3
+1 (nb) on my end too, I second Mick
Thanks for putting this together Josh
On Fri, 17 Dec 2021 at 10:48, Mick Semb Wever wrote:
> >
> >
> > 3.c: (NEW) After merging tickets, run ci-cassandra (already do this) and
> > get an advisory update on the related JIRA for any new errors on the run
> of
>
>
>
> 3.c: (NEW) After merging tickets, run ci-cassandra (already do this) and
> get an advisory update on the related JIRA for any new errors on the run of
> the SHA
>
> I strongly prefer we amend our process with 3.c.
+1 Yup, this is the most important missing piece for me.
I also wouldn't
What if we tried the following:
1. Canonical CI for a release is ci-cassandra. We can optionally, and in
practice will, run circle as well but don't codify blocking on that.
2. (NEW) We don't release unless we get a fully green run.
3. Before any merge, you need either a non-regressing (i.e. no ne
> I would like to point out that the code and tests do not support "pre" as a
pre-release label. 4.1.0-pre1 would break the code.
If true this can easily be fixed, but AFAICT CassandraVersion is happy to parse
this just fine so I doubt there would be many breakages.
> using a pre-release version
> "During the lead up to 4.0.0 there was plenty of headache and fixes going
> in to deal with how we parse version numbers in different places and
> alpa|beta|rc etc. I would rather bump the versions during the dev cycle and
> work on fixing it, than have that headache again at release time. I also
10 matches
Mail list logo
