Re: Keeping test-only changes out of CHANGES.txt
Thanks On Wed, Apr 15, 2020 at 10:32 AM Mick Semb Wever wrote: > > Can we vote(if required) on this as it looks largely everyone is in > > agreement? > > > I knew I forgot to post a reply here, thanks for the nudge sankalp, my bad. > > I took the above thread as consensus and last Friday committed it, > along with the documentation update from Eduard. > > https://github.com/apache/cassandra/commit/141ea26733e7e8fe022bc78f7fd68225013e8d14 > > So this is also reflected in the CHANGES.txt found in 4.0-alpha4 > > regards, > Mick > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Keeping test-only changes out of CHANGES.txt
> Can we vote(if required) on this as it looks largely everyone is in > agreement? I knew I forgot to post a reply here, thanks for the nudge sankalp, my bad. I took the above thread as consensus and last Friday committed it, along with the documentation update from Eduard. https://github.com/apache/cassandra/commit/141ea26733e7e8fe022bc78f7fd68225013e8d14 So this is also reflected in the CHANGES.txt found in 4.0-alpha4 regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
Can we vote(if required) on this as it looks largely everyone is in agreement? Also we can pile on documentation changes in the vote unless anyone objects. On Fri, Apr 10, 2020 at 2:52 PM Erick Ramirez wrote: > > > > In a conversation with Mick we discussed keeping doc changes out as well. > > Anyone object to eliding documentation changes from CHANGES.txt? > > > > +1 It will just get too noisy otherwise. >
Re: Keeping test-only changes out of CHANGES.txt
> > In a conversation with Mick we discussed keeping doc changes out as well. > Anyone object to eliding documentation changes from CHANGES.txt? > +1 It will just get too noisy otherwise.
Re: Keeping test-only changes out of CHANGES.txt
> > > updated docs in https://github.com/apache/cassandra/pull/528 > > > Thanks Eduard and Jon. Committed in https://github.com/apache/cassandra/commit/141ea26733e7e8fe022bc78f7fd68225013e8d14 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
+1 as soon as we always have JIRA number in the commit description Sent from my iPhone > On 10 Apr 2020, at 14:41, Brandon Williams wrote: > > +1 for keeping doc changes out. Definitely no good reason for keeping them. > >> On Fri, Apr 10, 2020 at 1:39 PM Jon Haddad wrote: >> >> In a conversation with Mick we discussed keeping doc changes out as well. >> Anyone object to eliding documentation changes from CHANGES.txt? >> >> >> >> >> >> >> On Thu, Apr 9, 2020 at 1:07 AM Benjamin Lerer >> wrote: >> >>> +1 >>> >>> >>> >>> On Thu, Apr 9, 2020 at 9:28 AM Eduard Tudenhoefner < >>> eduard.tudenhoef...@datastax.com> wrote: >>> >>>> updated docs in https://github.com/apache/cassandra/pull/528 >>>> >>>> On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: >>>> >>>>> +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. >>>>> >>>>> Jordan >>>>> >>>>> On Wed, Apr 8, 2020 at 11:30 AM wrote: >>>>> >>>>>> +1 >>>>>> >>>>>>> El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On 8 Apr 2020, at 13:50, Joshua McKenzie >>>>> wrote: >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>>>> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe >>> >>>>>> wrote: >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>>>> On 8 Apr 2020, at 15:08, Mick Semb Wever >>> wrote: >>>>>>>>>> >>>>>>>>>> Can we agree on keeping such test changes out of CHANGES.txt ? >>>>>>>>>> >>>>>>>>>> We already don't put entries into CHANGES.txt if it is not a >>>> change >>>>>>>>>> from any previous release. >>>>>>>>>> >>>>>>>>>> There was some discussion before¹ about this, and the problem >>> that >>>>>>>>>> being selective meant what ended up there being arbitrary. I >>> think >>>>>>>>>> this can be solved with an easy rule of thumb that if it only >>>>> touches >>>>>>>>>> *Test.java classes, or it is only about fixing a test, then it >>>>>>>>>> shouldn't be in CHANGES.txt. That means if the patch does touch >>>> any >>>>>>>>>> runtime code then you do still need to add an entry to >>>> CHANGES.txt. >>>>>>>>>> This avoids the whole "arbitrary" problem, and maintains >>>>> CHANGES.txt >>>>>>>>>> as user-facing formatted text to be searched through. >>>>>>>>>> >>>>>>>>>> If there's agreement I can commit to going through 4.0 changes >>> and >>>>>>>>>> removing those that never touched runtime code. >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> Mick >>>>>>>>>> >>>>>>>>>> ¹) >>>>>>>>> >>>>>> >>>>> >>>> >>> https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E >>>>>>>>>> >>>>>>>>>> >>>>> - >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> - >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>> - >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>>> >>>>>> >>>>>> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Eduard Tudenhoefner >>>> e. eduard.tudenhoef...@datastax.com >>>> w. www.datastax.com >>>> >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
+1 for keeping doc changes out. Definitely no good reason for keeping them. On Fri, Apr 10, 2020 at 1:39 PM Jon Haddad wrote: > > In a conversation with Mick we discussed keeping doc changes out as well. > Anyone object to eliding documentation changes from CHANGES.txt? > > > > > > > On Thu, Apr 9, 2020 at 1:07 AM Benjamin Lerer > wrote: > > > +1 > > > > > > > > On Thu, Apr 9, 2020 at 9:28 AM Eduard Tudenhoefner < > > eduard.tudenhoef...@datastax.com> wrote: > > > > > updated docs in https://github.com/apache/cassandra/pull/528 > > > > > > On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: > > > > > > > +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. > > > > > > > > Jordan > > > > > > > > On Wed, Apr 8, 2020 at 11:30 AM wrote: > > > > > > > > > +1 > > > > > > > > > > > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: > > > > > > > > > > > > +1 > > > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > >> On 8 Apr 2020, at 13:50, Joshua McKenzie > > > > wrote: > > > > > >> > > > > > >> +1 > > > > > >> > > > > > >>>> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe > > > > > > > wrote: > > > > > >>> > > > > > >>> +1 > > > > > >>> > > > > > >>>>> On 8 Apr 2020, at 15:08, Mick Semb Wever > > wrote: > > > > > >>>> > > > > > >>>> Can we agree on keeping such test changes out of CHANGES.txt ? > > > > > >>>> > > > > > >>>> We already don't put entries into CHANGES.txt if it is not a > > > change > > > > > >>>> from any previous release. > > > > > >>>> > > > > > >>>> There was some discussion before¹ about this, and the problem > > that > > > > > >>>> being selective meant what ended up there being arbitrary. I > > think > > > > > >>>> this can be solved with an easy rule of thumb that if it only > > > > touches > > > > > >>>> *Test.java classes, or it is only about fixing a test, then it > > > > > >>>> shouldn't be in CHANGES.txt. That means if the patch does touch > > > any > > > > > >>>> runtime code then you do still need to add an entry to > > > CHANGES.txt. > > > > > >>>> This avoids the whole "arbitrary" problem, and maintains > > > > CHANGES.txt > > > > > >>>> as user-facing formatted text to be searched through. > > > > > >>>> > > > > > >>>> If there's agreement I can commit to going through 4.0 changes > > and > > > > > >>>> removing those that never touched runtime code. > > > > > >>>> > > > > > >>>> regards, > > > > > >>>> Mick > > > > > >>>> > > > > > >>>> ¹) > > > > > >>> > > > > > > > > > > > > > > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > > > >>>> > > > > > >>>> > > > > - > > > > > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > >>>> > > > > > >>> > > > > > >>> > > > > > >>> > > > - > > > > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > >>> > > > > > >>> > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > > > > -- > > > Eduard Tudenhoefner > > > e. eduard.tudenhoef...@datastax.com > > > w. www.datastax.com > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
In a conversation with Mick we discussed keeping doc changes out as well. Anyone object to eliding documentation changes from CHANGES.txt? On Thu, Apr 9, 2020 at 1:07 AM Benjamin Lerer wrote: > +1 > > > > On Thu, Apr 9, 2020 at 9:28 AM Eduard Tudenhoefner < > eduard.tudenhoef...@datastax.com> wrote: > > > updated docs in https://github.com/apache/cassandra/pull/528 > > > > On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: > > > > > +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. > > > > > > Jordan > > > > > > On Wed, Apr 8, 2020 at 11:30 AM wrote: > > > > > > > +1 > > > > > > > > > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: > > > > > > > > > > +1 > > > > > > > > > > Sent from my iPhone > > > > > > > > > >> On 8 Apr 2020, at 13:50, Joshua McKenzie > > > wrote: > > > > >> > > > > >> +1 > > > > >> > > > > >>>> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe > > > > > wrote: > > > > >>> > > > > >>> +1 > > > > >>> > > > > >>>>> On 8 Apr 2020, at 15:08, Mick Semb Wever > wrote: > > > > >>>> > > > > >>>> Can we agree on keeping such test changes out of CHANGES.txt ? > > > > >>>> > > > > >>>> We already don't put entries into CHANGES.txt if it is not a > > change > > > > >>>> from any previous release. > > > > >>>> > > > > >>>> There was some discussion before¹ about this, and the problem > that > > > > >>>> being selective meant what ended up there being arbitrary. I > think > > > > >>>> this can be solved with an easy rule of thumb that if it only > > > touches > > > > >>>> *Test.java classes, or it is only about fixing a test, then it > > > > >>>> shouldn't be in CHANGES.txt. That means if the patch does touch > > any > > > > >>>> runtime code then you do still need to add an entry to > > CHANGES.txt. > > > > >>>> This avoids the whole "arbitrary" problem, and maintains > > > CHANGES.txt > > > > >>>> as user-facing formatted text to be searched through. > > > > >>>> > > > > >>>> If there's agreement I can commit to going through 4.0 changes > and > > > > >>>> removing those that never touched runtime code. > > > > >>>> > > > > >>>> regards, > > > > >>>> Mick > > > > >>>> > > > > >>>> ¹) > > > > >>> > > > > > > > > > > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > > >>>> > > > > >>>> > > > - > > > > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > - > > > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >>> > > > > >>> > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > -- > > Eduard Tudenhoefner > > e. eduard.tudenhoef...@datastax.com > > w. www.datastax.com > > >
Re: Keeping test-only changes out of CHANGES.txt
+1 On Thu, Apr 9, 2020 at 9:28 AM Eduard Tudenhoefner < eduard.tudenhoef...@datastax.com> wrote: > updated docs in https://github.com/apache/cassandra/pull/528 > > On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: > > > +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. > > > > Jordan > > > > On Wed, Apr 8, 2020 at 11:30 AM wrote: > > > > > +1 > > > > > > > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: > > > > > > > > +1 > > > > > > > > Sent from my iPhone > > > > > > > >> On 8 Apr 2020, at 13:50, Joshua McKenzie > > wrote: > > > >> > > > >> +1 > > > >> > > > >>>> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe > > > wrote: > > > >>> > > > >>> +1 > > > >>> > > > >>>>> On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > > > >>>> > > > >>>> Can we agree on keeping such test changes out of CHANGES.txt ? > > > >>>> > > > >>>> We already don't put entries into CHANGES.txt if it is not a > change > > > >>>> from any previous release. > > > >>>> > > > >>>> There was some discussion before¹ about this, and the problem that > > > >>>> being selective meant what ended up there being arbitrary. I think > > > >>>> this can be solved with an easy rule of thumb that if it only > > touches > > > >>>> *Test.java classes, or it is only about fixing a test, then it > > > >>>> shouldn't be in CHANGES.txt. That means if the patch does touch > any > > > >>>> runtime code then you do still need to add an entry to > CHANGES.txt. > > > >>>> This avoids the whole "arbitrary" problem, and maintains > > CHANGES.txt > > > >>>> as user-facing formatted text to be searched through. > > > >>>> > > > >>>> If there's agreement I can commit to going through 4.0 changes and > > > >>>> removing those that never touched runtime code. > > > >>>> > > > >>>> regards, > > > >>>> Mick > > > >>>> > > > >>>> ¹) > > > >>> > > > > > > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > >>>> > > > >>>> > > - > > > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > >>>> > > > >>> > > > >>> > > > >>> > - > > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > >>> > > > >>> > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > -- > Eduard Tudenhoefner > e. eduard.tudenhoef...@datastax.com > w. www.datastax.com >
Re: Keeping test-only changes out of CHANGES.txt
updated docs in https://github.com/apache/cassandra/pull/528 On Wed, Apr 8, 2020 at 11:39 PM Jordan West wrote: > +1 (nb) to the change and +1 (nb) to updating the docs to reflect this. > > Jordan > > On Wed, Apr 8, 2020 at 11:30 AM wrote: > > > +1 > > > > > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: > > > > > > +1 > > > > > > Sent from my iPhone > > > > > >> On 8 Apr 2020, at 13:50, Joshua McKenzie > wrote: > > >> > > >> +1 > > >> > > >>>> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe > > wrote: > > >>> > > >>> +1 > > >>> > > >>>>> On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > > >>>> > > >>>> Can we agree on keeping such test changes out of CHANGES.txt ? > > >>>> > > >>>> We already don't put entries into CHANGES.txt if it is not a change > > >>>> from any previous release. > > >>>> > > >>>> There was some discussion before¹ about this, and the problem that > > >>>> being selective meant what ended up there being arbitrary. I think > > >>>> this can be solved with an easy rule of thumb that if it only > touches > > >>>> *Test.java classes, or it is only about fixing a test, then it > > >>>> shouldn't be in CHANGES.txt. That means if the patch does touch any > > >>>> runtime code then you do still need to add an entry to CHANGES.txt. > > >>>> This avoids the whole "arbitrary" problem, and maintains > CHANGES.txt > > >>>> as user-facing formatted text to be searched through. > > >>>> > > >>>> If there's agreement I can commit to going through 4.0 changes and > > >>>> removing those that never touched runtime code. > > >>>> > > >>>> regards, > > >>>> Mick > > >>>> > > >>>> ¹) > > >>> > > > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > >>>> > > >>>> > - > > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>>> > > >>> > > >>> > > >>> - > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >>> > > >>> > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > -- Eduard Tudenhoefner e. eduard.tudenhoef...@datastax.com w. www.datastax.com
Re: Keeping test-only changes out of CHANGES.txt
+1 (nb) to the change and +1 (nb) to updating the docs to reflect this. Jordan On Wed, Apr 8, 2020 at 11:30 AM wrote: > +1 > > > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: > > > > +1 > > > > Sent from my iPhone > > > >> On 8 Apr 2020, at 13:50, Joshua McKenzie wrote: > >> > >> +1 > >> > >>>> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe > wrote: > >>> > >>> +1 > >>> > >>>>> On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > >>>> > >>>> Can we agree on keeping such test changes out of CHANGES.txt ? > >>>> > >>>> We already don't put entries into CHANGES.txt if it is not a change > >>>> from any previous release. > >>>> > >>>> There was some discussion before¹ about this, and the problem that > >>>> being selective meant what ended up there being arbitrary. I think > >>>> this can be solved with an easy rule of thumb that if it only touches > >>>> *Test.java classes, or it is only about fixing a test, then it > >>>> shouldn't be in CHANGES.txt. That means if the patch does touch any > >>>> runtime code then you do still need to add an entry to CHANGES.txt. > >>>> This avoids the whole "arbitrary" problem, and maintains CHANGES.txt > >>>> as user-facing formatted text to be searched through. > >>>> > >>>> If there's agreement I can commit to going through 4.0 changes and > >>>> removing those that never touched runtime code. > >>>> > >>>> regards, > >>>> Mick > >>>> > >>>> ¹) > >>> > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > >>>> > >>>> - > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>>> > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>> > >>> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Keeping test-only changes out of CHANGES.txt
+1 > El 8 abr 2020, a las 19:05, e.dimitr...@gmail.com escribió: > > +1 > > Sent from my iPhone > >> On 8 Apr 2020, at 13:50, Joshua McKenzie wrote: >> >> +1 >> >>>> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe wrote: >>> >>> +1 >>> >>>>> On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: >>>> >>>> Can we agree on keeping such test changes out of CHANGES.txt ? >>>> >>>> We already don't put entries into CHANGES.txt if it is not a change >>>> from any previous release. >>>> >>>> There was some discussion before¹ about this, and the problem that >>>> being selective meant what ended up there being arbitrary. I think >>>> this can be solved with an easy rule of thumb that if it only touches >>>> *Test.java classes, or it is only about fixing a test, then it >>>> shouldn't be in CHANGES.txt. That means if the patch does touch any >>>> runtime code then you do still need to add an entry to CHANGES.txt. >>>> This avoids the whole "arbitrary" problem, and maintains CHANGES.txt >>>> as user-facing formatted text to be searched through. >>>> >>>> If there's agreement I can commit to going through 4.0 changes and >>>> removing those that never touched runtime code. >>>> >>>> regards, >>>> Mick >>>> >>>> ¹) >>> https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
+1 Sent from my iPhone > On 8 Apr 2020, at 13:50, Joshua McKenzie wrote: > > +1 > >> On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe wrote: >> >> +1 >> >>>> On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: >>> >>> Can we agree on keeping such test changes out of CHANGES.txt ? >>> >>> We already don't put entries into CHANGES.txt if it is not a change >>> from any previous release. >>> >>> There was some discussion before¹ about this, and the problem that >>> being selective meant what ended up there being arbitrary. I think >>> this can be solved with an easy rule of thumb that if it only touches >>> *Test.java classes, or it is only about fixing a test, then it >>> shouldn't be in CHANGES.txt. That means if the patch does touch any >>> runtime code then you do still need to add an entry to CHANGES.txt. >>> This avoids the whole "arbitrary" problem, and maintains CHANGES.txt >>> as user-facing formatted text to be searched through. >>> >>> If there's agreement I can commit to going through 4.0 changes and >>> removing those that never touched runtime code. >>> >>> regards, >>> Mick >>> >>> ¹) >> https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
+1 On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe wrote: > +1 > > > On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > > > > Can we agree on keeping such test changes out of CHANGES.txt ? > > > > We already don't put entries into CHANGES.txt if it is not a change > > from any previous release. > > > > There was some discussion before¹ about this, and the problem that > > being selective meant what ended up there being arbitrary. I think > > this can be solved with an easy rule of thumb that if it only touches > > *Test.java classes, or it is only about fixing a test, then it > > shouldn't be in CHANGES.txt. That means if the patch does touch any > > runtime code then you do still need to add an entry to CHANGES.txt. > > This avoids the whole "arbitrary" problem, and maintains CHANGES.txt > > as user-facing formatted text to be searched through. > > > > If there's agreement I can commit to going through 4.0 changes and > > removing those that never touched runtime code. > > > > regards, > > Mick > > > > ¹) > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Keeping test-only changes out of CHANGES.txt
+1 On Wed, Apr 8, 2020, 10:06 AM Dinesh Joshi wrote: > Could we please update the developer docs to reflect this? > > http://cassandra.apache.org/doc/latest/development/index.html > > Dinesh > > > On Apr 8, 2020, at 7:08 AM, Mick Semb Wever wrote: > > > > Can we agree on keeping such test changes out of CHANGES.txt ? > > > > We already don't put entries into CHANGES.txt if it is not a change > > from any previous release. > > > > There was some discussion before¹ about this, and the problem that > > being selective meant what ended up there being arbitrary. I think > > this can be solved with an easy rule of thumb that if it only touches > > *Test.java classes, or it is only about fixing a test, then it > > shouldn't be in CHANGES.txt. That means if the patch does touch any > > runtime code then you do still need to add an entry to CHANGES.txt. > > This avoids the whole "arbitrary" problem, and maintains CHANGES.txt > > as user-facing formatted text to be searched through. > > > > If there's agreement I can commit to going through 4.0 changes and > > removing those that never touched runtime code. > > > > regards, > > Mick > > > > ¹) > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Keeping test-only changes out of CHANGES.txt
Could we please update the developer docs to reflect this? http://cassandra.apache.org/doc/latest/development/index.html Dinesh > On Apr 8, 2020, at 7:08 AM, Mick Semb Wever wrote: > > Can we agree on keeping such test changes out of CHANGES.txt ? > > We already don't put entries into CHANGES.txt if it is not a change > from any previous release. > > There was some discussion before¹ about this, and the problem that > being selective meant what ended up there being arbitrary. I think > this can be solved with an easy rule of thumb that if it only touches > *Test.java classes, or it is only about fixing a test, then it > shouldn't be in CHANGES.txt. That means if the patch does touch any > runtime code then you do still need to add an entry to CHANGES.txt. > This avoids the whole "arbitrary" problem, and maintains CHANGES.txt > as user-facing formatted text to be searched through. > > If there's agreement I can commit to going through 4.0 changes and > removing those that never touched runtime code. > > regards, > Mick > > ¹) > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
+1 > On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > > Can we agree on keeping such test changes out of CHANGES.txt ? > > We already don't put entries into CHANGES.txt if it is not a change > from any previous release. > > There was some discussion before¹ about this, and the problem that > being selective meant what ended up there being arbitrary. I think > this can be solved with an easy rule of thumb that if it only touches > *Test.java classes, or it is only about fixing a test, then it > shouldn't be in CHANGES.txt. That means if the patch does touch any > runtime code then you do still need to add an entry to CHANGES.txt. > This avoids the whole "arbitrary" problem, and maintains CHANGES.txt > as user-facing formatted text to be searched through. > > If there's agreement I can commit to going through 4.0 changes and > removing those that never touched runtime code. > > regards, > Mick > > ¹) > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Keeping test-only changes out of CHANGES.txt
+1 From: Jasonstack Zhao Yang Sent: Wednesday, April 8, 2020 9:04:51 AM To: dev@cassandra.apache.org Subject: Re: Keeping test-only changes out of CHANGES.txt +1 On Thu, Apr 9, 2020, 00:04 Aleksey Yeshchenko wrote: > +1 > > > On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > > > > Can we agree on keeping such test changes out of CHANGES.txt ? > > > > We already don't put entries into CHANGES.txt if it is not a change > > from any previous release. > > > > There was some discussion before¹ about this, and the problem that > > being selective meant what ended up there being arbitrary. I think > > this can be solved with an easy rule of thumb that if it only touches > > *Test.java classes, or it is only about fixing a test, then it > > shouldn't be in CHANGES.txt. That means if the patch does touch any > > runtime code then you do still need to add an entry to CHANGES.txt. > > This avoids the whole "arbitrary" problem, and maintains CHANGES.txt > > as user-facing formatted text to be searched through. > > > > If there's agreement I can commit to going through 4.0 changes and > > removing those that never touched runtime code. > > > > regards, > > Mick > > > > ¹) > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Keeping test-only changes out of CHANGES.txt
+1 On Thu, Apr 9, 2020, 00:04 Aleksey Yeshchenko wrote: > +1 > > > On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > > > > Can we agree on keeping such test changes out of CHANGES.txt ? > > > > We already don't put entries into CHANGES.txt if it is not a change > > from any previous release. > > > > There was some discussion before¹ about this, and the problem that > > being selective meant what ended up there being arbitrary. I think > > this can be solved with an easy rule of thumb that if it only touches > > *Test.java classes, or it is only about fixing a test, then it > > shouldn't be in CHANGES.txt. That means if the patch does touch any > > runtime code then you do still need to add an entry to CHANGES.txt. > > This avoids the whole "arbitrary" problem, and maintains CHANGES.txt > > as user-facing formatted text to be searched through. > > > > If there's agreement I can commit to going through 4.0 changes and > > removing those that never touched runtime code. > > > > regards, > > Mick > > > > ¹) > https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Keeping test-only changes out of CHANGES.txt
+1 On 08/04/2020, 16:53, "Mick Semb Wever" wrote: Can we agree on keeping such test changes out of CHANGES.txt ? We already don't put entries into CHANGES.txt if it is not a change from any previous release. There was some discussion before¹ about this, and the problem that being selective meant what ended up there being arbitrary. I think this can be solved with an easy rule of thumb that if it only touches *Test.java classes, or it is only about fixing a test, then it shouldn't be in CHANGES.txt. That means if the patch does touch any runtime code then you do still need to add an entry to CHANGES.txt. This avoids the whole "arbitrary" problem, and maintains CHANGES.txt as user-facing formatted text to be searched through. If there's agreement I can commit to going through 4.0 changes and removing those that never touched runtime code. regards, Mick ¹) https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Keeping test-only changes out of CHANGES.txt
Can we agree on keeping such test changes out of CHANGES.txt ? We already don't put entries into CHANGES.txt if it is not a change from any previous release. There was some discussion before¹ about this, and the problem that being selective meant what ended up there being arbitrary. I think this can be solved with an easy rule of thumb that if it only touches *Test.java classes, or it is only about fixing a test, then it shouldn't be in CHANGES.txt. That means if the patch does touch any runtime code then you do still need to add an entry to CHANGES.txt. This avoids the whole "arbitrary" problem, and maintains CHANGES.txt as user-facing formatted text to be searched through. If there's agreement I can commit to going through 4.0 changes and removing those that never touched runtime code. regards, Mick ¹) https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: CHANGES.txt
Thanks your responses! Seems like all of you prefer to have both trivial and non-trivial updates in CHANGES.txt. I'm going to keep that in mind, but will continue to omit them for documentation edits. On 18.07.2017 23:49, kurt greaves wrote: > I agree that all patches should be added to changes.txt, just to rule out > any ambiguities. When people look at Changes.txt it's usually to find > something specific, not to browse the list of changes. Anything significant > should make it into news.txt, which is more appropriate for users. > changes.txt is more aimed at developers in my opinion. > > On that note, messages like "Remove unused method" should be more specific, > that's just a bad commit message in general, and doesn't give at context. > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
RE: CHANGES.txt
I agree that all patches should be added to changes.txt, just to rule out any ambiguities. When people look at Changes.txt it's usually to find something specific, not to browse the list of changes. Anything significant should make it into news.txt, which is more appropriate for users. changes.txt is more aimed at developers in my opinion. On that note, messages like "Remove unused method" should be more specific, that's just a bad commit message in general, and doesn't give at context.
RE: CHANGES.txt
I also think all issues should be kept in CHANGES.txt, it very useful either to find what changed or to track some obscure bugs months after the release. Sometime when developing plugins for Cassandra you find solutions/resolution there. Maybe if you want to reduce the list you could provide a link to a Jira filter that lists all the fixed issues for 4.0 in the CHANGES.txt, but an offline list is always more convenient. -- Jacques-Henri Berthemet -Original Message- From: Eric Evans [mailto:john.eric.ev...@gmail.com] Sent: mardi 18 juillet 2017 07:09 To: dev@cassandra.apache.org Subject: Re: CHANGES.txt On Tue, Jul 18, 2017 at 8:10 AM, Stefan Podkowinski <s...@apache.org> wrote: > Has there been any consensus in the past about what goes into > CHANGES.txt and what not? My naive assumption was that the intended > audience for the file are users who want to know about changes between > new releases. Having that in mind, I skipped changes.txt once in a > while for updates that have no relevance except for developers. For > releases, such as 4.0, the list is already substantial and hard to > digest. I'm also wondering how informative entries such as e.g. > "Remove unused method" are for the general user. So my question is, > should we add all resolved tickets to changes.txt, or should we try to > keep the list less verbose in the future? One problem with trying to be selective, is that it invites judgment as to what is or is not worthy for inclusion, and that's bound to be a slippery slope. I also think it's not uncommon for what appears to be a trivial change for one person, to be very important to someone else. I wonder if the length of the list for 4.0 doesn't have as much to do with the delays in getting it released. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: CHANGES.txt
On Tue, Jul 18, 2017 at 8:10 AM, Stefan Podkowinski <s...@apache.org> wrote: > Has there been any consensus in the past about what goes into > CHANGES.txt and what not? My naive assumption was that the intended > audience for the file are users who want to know about changes between > new releases. Having that in mind, I skipped changes.txt once in a while > for updates that have no relevance except for developers. For releases, > such as 4.0, the list is already substantial and hard to digest. I'm > also wondering how informative entries such as e.g. "Remove unused > method" are for the general user. So my question is, should we add all > resolved tickets to changes.txt, or should we try to keep the list less > verbose in the future? One problem with trying to be selective, is that it invites judgment as to what is or is not worthy for inclusion, and that's bound to be a slippery slope. I also think it's not uncommon for what appears to be a trivial change for one person, to be very important to someone else. I wonder if the length of the list for 4.0 doesn't have as much to do with the delays in getting it released. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
CHANGES.txt
Has there been any consensus in the past about what goes into CHANGES.txt and what not? My naive assumption was that the intended audience for the file are users who want to know about changes between new releases. Having that in mind, I skipped changes.txt once in a while for updates that have no relevance except for developers. For releases, such as 4.0, the list is already substantial and hard to digest. I'm also wondering how informative entries such as e.g. "Remove unused method" are for the general user. So my question is, should we add all resolved tickets to changes.txt, or should we try to keep the list less verbose in the future? - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: 3.10 fixver, CHANGES.txt, and the cassandra-3.11 branch
Paulo pinged me on irc about getting CASSANDRA-12905 in for 3.10, so that has been marked as release critical for 3.10 in JIRA. -- Kind regards, Michael On 12/05/2016 01:26 PM, Michael Shuler wrote: > I have again removed the 3.11 version from JIRA and corrected > CHANGES.txt for 3.10. > > I'll run through the test results on the cassandra-3.11 branch and see > where we are at for a possible 3.10 release vote #5. There appear to be > no open 3.10 JIRA tickets at this time. >
Re: 3.10 fixver, CHANGES.txt, and the cassandra-3.11 branch
I have again removed the 3.11 version from JIRA and corrected CHANGES.txt for 3.10. I'll run through the test results on the cassandra-3.11 branch and see where we are at for a possible 3.10 release vote #5. There appear to be no open 3.10 JIRA tickets at this time. -- Kind regards, Michael On 11/29/2016 12:11 PM, Michael Shuler wrote: > Sam and I fixed up CHANGES.txt and fix versions in JIRA that had 3.11. > > Since 3.10 has not been released yet,and the cassandra-3.11 branch was > created from the 3.10-tentative tag for fixed on top of 3.10, the > cassandra-3.11 branch will be used for the 3.10 release, as well as for > fixed bugs on top of 3.10 that will become 3.11. There should be no JIRA > tickets or CHANGES entries for 3.11, until such time that 3.10 is > actually released :) > > Any new features / improvements targeted for 3.12 should be committed to > the cassandra-3.X branch. This should hopefully help the cassandra-3.11 > branch settle down. >
3.10 fixver, CHANGES.txt, and the cassandra-3.11 branch
Sam and I fixed up CHANGES.txt and fix versions in JIRA that had 3.11. Since 3.10 has not been released yet,and the cassandra-3.11 branch was created from the 3.10-tentative tag for fixed on top of 3.10, the cassandra-3.11 branch will be used for the 3.10 release, as well as for fixed bugs on top of 3.10 that will become 3.11. There should be no JIRA tickets or CHANGES entries for 3.11, until such time that 3.10 is actually released :) Any new features / improvements targeted for 3.12 should be committed to the cassandra-3.X branch. This should hopefully help the cassandra-3.11 branch settle down. -- Kind regards, Michael
max_mutation_size_in_kb addition not noted in CHANGES.txt
I don't find mention of max_mutation_size_in_kb in CHANGES.txt, but I do see it mentioned for 3.0.0 in NEWS.txt. It doesn't have (DataStax) doc either. It looks like it was added on 8/19/2015: "patch by Aleksey Yeschenko; reviewed by Benedict Elliott Smith for CASSANDRA-6230": https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b#diff-b66584c9ce7b64019b5db5a531deeda1 It probably should be (or have been) added to CHANGES.txt as well. I do see that comments on this was added to the yaml file on 10/2/2015 as part of: https://issues.apache.org/jira/browse/CASSANDRA-10256 -- Jack Krupansky
CASSANDRA-2249 not in CHANGES.txt for 1.0
It's in NEWS should it also be in CHANGES? https://issues.apache.org/jira/browse/CASSANDRA-2449 Cheers - Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com
Re: CASSANDRA-2249 not in CHANGES.txt for 1.0
Added. Thanks for catching that! On Thu, Sep 15, 2011 at 11:37 PM, aaron morton aa...@thelastpickle.com wrote: It's in NEWS should it also be in CHANGES? https://issues.apache.org/jira/browse/CASSANDRA-2449 Cheers - Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
