Done. Thanks!
On 2020/12/17 10:57:35, Benjamin Lerer wrote:
> Thanks Mick for raising that problem. Effectively, I got confused along the
> way.
>
> +1
>
> On Thu, Dec 17, 2020 at 11:56 AM Sam Tunnicliffe wrote:
>
> >
> >
> > > On 17 Dec 2020, at 10:54, Michael Semb Wever wrote:
> > >
> >
Thanks Mick for raising that problem. Effectively, I got confused along the
way.
+1
On Thu, Dec 17, 2020 at 11:56 AM Sam Tunnicliffe wrote:
>
>
> > On 17 Dec 2020, at 10:54, Michael Semb Wever wrote:
> >
> >
> >> I propose to:
> >>
> >> - update the documentation to clarify the meaning of th
> On 17 Dec 2020, at 10:54, Michael Semb Wever wrote:
>
>
>> I propose to:
>>
>> - update the documentation to clarify the meaning of the fix version as
>> 'The version in which the item must be fixed' (e.g 4.0-beta if the ticket
>> must be fixed in a beta release)
>> - create a 4.0-
> I propose to:
>
>- update the documentation to clarify the meaning of the fix version as
>'The version in which the item must be fixed' (e.g 4.0-beta if the ticket
>must be fixed in a beta release)
>- create a 4.0-GA fix version and use it for the Quality testing tickets
>-
+1
On Mon, 14 Dec 2020 at 13:43, David Capwell
wrote:
> +1
>
> > On Dec 14, 2020, at 10:03 AM, Benjamin Lerer <
> benjamin.le...@datastax.com> wrote:
> >
> > Thank you for the feedback.
> > I propose to:
> >
> > - update the documentation to clarify the meaning of the fix version as
> > 'The
+1
> On Dec 14, 2020, at 10:03 AM, Benjamin Lerer
> wrote:
>
> Thank you for the feedback.
> I propose to:
>
> - update the documentation to clarify the meaning of the fix version as
> 'The version in which the item must be fixed' (e.g 4.0-beta if the ticket
> must be fixed in a beta rel
Thank you for the feedback.
I propose to:
- update the documentation to clarify the meaning of the fix version as
'The version in which the item must be fixed' (e.g 4.0-beta if the ticket
must be fixed in a beta release)
- create a 4.0-GA fix version and use it for the Quality testing
Yes, I meant of those tickets we agreed at ApacheCon a year ago, blocking at
most GA seems reasonable - roughly in accordance with what Benjamin was saying.
Not that the entire codebase should be brought up to our preferred standards
before any new releases are cut. I'm also not opposed to som
>
> As an aside, I disagree about this blocking GA. We have a decade or so of
> debt and this is essentially a category without a ceiling. Under this
> umbrella we could feasibly delay 4.0 for another multiple years.
I do not think that anybody wants to delay 4.0 more than needed.
Now, nothing pr
>
> - Anticipated not to find serious bugs (e.g. old unchanged but poorly
> tested features): Block GA
As an aside, I disagree about this blocking GA. We have a decade or so of
debt and this is essentially a category without a ceiling. Under this
umbrella we could feasibly delay 4.0 for another m
Reasonable categories. We haven't discussed what qualifies where for 4.0
have we? (new lacking | changed modest | old lacking)
On Fri, Dec 11, 2020 at 9:14 AM Benedict Elliott Smith
wrote:
> In my opinion...
>
> - Expected to find serious bugs (e.g. new poorly tested features): Block
> beta
> -
In my opinion...
- Expected to find serious bugs (e.g. new poorly tested features): Block beta
- Anticipated to possibly find serious bugs (e.g. extensively changed features
with modest testing): Block RC
- Anticipated not to find serious bugs (e.g. old unchanged but poorly tested
features): Blo
It looks like my question raised more questions than I had in mind.
1. What is the meaning of the fix version?
2. When do we move from beta to RC?
3. Where does the Quality tickets fit in all that?
*What is the meaning of the fix version?*
It looks like we should just pick a definition and docu
> I have thought that the fix version is the version which the item will be…
fixed in… Others want the fix version to be the version which must not
start until the ticket is closed…
David, my understanding of it doesn't quite fit into this…
Issues with a fixVersion of 4.0-beta indicate they are
I read the release lifecycle a little differently when it comes to the
quality tickets; I don't think it really speaks to those (areas without
known defects but with known skepticism about their stability). If we find
the text to be unclear or not address them we should definitely revise.
Here's wh
Thanks for bringing this up, this is a major form of confusion right now.
I have thought that the fix version is the version which the item will be…
fixed in… Others want the fix version to be the version which must not
start until the ticket is closed… Both of these opinions are not documented
an
> Do we want them fixed before we release 4.0-RC or are they part of the
> testing of the RC release?
We are so unbearably close, it would be nice to see the beta tickets narrowed
(again) to just the most critical issues.
Tickets about creating new tests, and bugs edge-case, or not severe o
Hi everybody,
Looking at the Dashboard, it seems that the *Quality Testing* tickets are
spread between the Beta and RC releases.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
I assumed that those tickets were part of the Beta release but I might have
misunde
18 matches
Mail list logo
