"backport candidate" sounds like an interesting idea! If someone wants to
propose and help implement that, I would be supportive.
For now, I've merged the definitions of "Breaking Change" and "Critical
Fix". I've also labelled the relevant issues I've found for 11.0.0 and
10.0.0:
Breaking changes
Hi,
I would also suggest a "bugfix" or "backport candidate" label if we want
to make it easier to cherrypick changes for bugfix releases.
Regards
Antoine.
Le 06/01/2023 à 17:57, Will Jones a écrit :
Hello Arrow devs,
For the monorepo, I would like to propose adding two new labels to iss
Antoine and Weston,
You make a very good point about crashes, particularly the security risk.
I'll add that to the scope of the definition.
On Sat, Jan 14, 2023 at 9:54 AM Antoine Pitrou wrote:
>
> A crash on invalid *user* input can easily turn into a security
> vulnerability (if only because
A crash on invalid *user* input can easily turn into a security
vulnerability (if only because it's a possible vector for DoS attacks),
and so should definitely be considered critical.
What's not critical is a crash when the caller of a C++ API doesn't
respect the API contract (e.g. passes
On further thought it seems a little odd to me that crashes are not
critical. However, many of our crashes are from a failure to properly
validate user input, which I agree isn't as critical. Would it be too
nuanced to say that:
* A crash, given valid input, is critical
* A crash, given invali
Hi Will,
Le 14/01/2023 à 17:06, Will Jones a écrit :
I'm quite skeptical about this. My experience is that many people have a
very subjective idea of what is critical or not, and the categorization
ends up not very informative.
Antoine, skeptical about the definition of "Critical Fix"? Or s
>
> I'm quite skeptical about this. My experience is that many people have a
> very subjective idea of what is critical or not, and the categorization
> ends up not very informative.
Antoine, skeptical about the definition of "Critical Fix"? Or something
else? On "Critical Fix", I tried to make t
I'm quite skeptical about this. My experience is that many people have a
very subjective idea of what is critical or not, and the categorization
ends up not very informative.
Regards
Antoine.
Le 13/01/2023 à 23:53, Will Jones a écrit :
Following up: I have created a PR adding the definit
Following up: I have created a PR adding the definition [1]. While
writing this, I ended up feeling that it made sense to keep separate labels
for "Critical Fix" and "Priority: Critical".
[1] https://github.com/apache/arrow/pull/33660
On Sat, Jan 7, 2023 at 2:54 AM Rok Mihevc wrote:
> >
> > I r
>
> I replied in the GitHub thread [1], but will say that I am +1 on Priority:
> Blocker and Priority: Critical. Though I wonder if we could use "Critical
> Fix" in place of "Priority: Critical"? Unless we have two different
> definitions. As is, the names are similar enough that it could be
> conf
Antoine,
I think the challenge is to maintain a shared understanding and definition
> of what these terms cover and don't cover.
I agree with this. I'd propose that we have a page in our Contributing docs
(perhaps the reviewers page?) that defines the criteria for these labels. I
can make a PR w
> To answer Matt's comment, though: those are not necessarily the criteria
for minor releases, if we think of the latter as bugfix releases.
When we do bugfixes, we release them as Patch releases (which I'd argue is
correct). In an ideal world, we'd only do a *major* version release when
there are
Hey,
+1 for the proposal. Perhaps we can loop back and evaluate come 12.0.0 to
see if these were useful / used?
I'd like to pile on another new label proposal. For purpose of Jira ->
GitHub Migration I'd like to propose the following labels be added, that
are common on Jira but missing on GitHub:
Hello Will,
This sounds like a good idea. I think the challenge is to maintain a
shared understanding and definition of what these terms cover and don't
cover.
To answer Matt's comment, though: those are not necessarily the criteria
for minor releases, if we think of the latter as bugfix
I'm extremely in favor of both of these labels for the reasons you state
Will. It would be great to see us shift towards being able to do minor
releases and not *always* having to do a major version release.
--Matt
On Fri, Jan 6, 2023 at 12:14 PM Micah Kornfield
wrote:
> These sounds good to me
These sounds good to me, we should be careful around crashes/security
issues to not tag them until they are triaged and we decide if a new
one-off release is necessary.
On Fri, Jan 6, 2023 at 8:57 AM Will Jones wrote:
> Hello Arrow devs,
>
> For the monorepo, I would like to propose adding two n
Hello Arrow devs,
For the monorepo, I would like to propose adding two new labels to issues:
1. breaking-change: for changes that break API compatibility.
2. critical-fix: for bug fixes that address bugs that are important for
users will want to know about, but may not realize affect the
17 matches
Mail list logo
