You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Will Jones <wi...@gmail.com> on 2023/01/06 16:57:30 UTC
[Monorepo] Add labels breaking-change and critical-fix
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 them. The primary
type I have observed in the Arrow repo are bugs that produce incorrect or
invalid data. Security vulnerabilities are another type. Bugs that caused
errors or crashes generally wouldn't count, since users are aware of the
errors they get. (Though I am definitely open to arguments for a
different definition or name.)
I would additionally propose that these labels are validated during the
release process and included in the change notes. By validated, I mean
someone should review all the changes in a particular release to make sure
all relevant issues are tagged with these labels. These are the two kinds
of issues I think users will most want to know about when considering
upgrading an Arrow library: what APIs changed? And what's the risk of not
upgrading?
I am willing to be responsible for maintaining these labels for the next
few releases for Python, R, and C++. I have been compiling the list of
these issues for past versions, as part of my work for my employer, so I'm
on the hook for this regardless. Having these labels available and used by
developers and reviewers would make that work much easier. And, of course,
our users would benefit by having this information easily available in our
release notes.
It's also worth mentioning these two labels are useful if we decide to
change how we do releases. The breaking-change label can help decide
whether we actually need to increment the major version. And the
critical-fix label can help guide which bug fixes are worth applying to
older supported releases. I don't think we are ready for either of those
yet, but I thought it's worth connecting those dots.
Best,
Will Jones
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Will Jones <wi...@gmail.com>.
"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 in 11.0.0:
https://github.com/apache/arrow/issues?q=milestone%3A%2211.0.0%22+label%3A%22Breaking+Change%22
Critical fixes in 11.0.0:
https://github.com/apache/arrow/issues?q=milestone%3A%2211.0.0%22+label%3A%22Critical+Fix%22+
Breaking changes in 10.0.0:
https://github.com/apache/arrow/issues?q=milestone%3A%2210.0.0%22+label%3A%22Breaking+Change%22+
Critical fixes in 10.0.0:
https://github.com/apache/arrow/issues?q=milestone%3A%2210.0.0%22+label%3A%22Critical+Fix%22+
On Tue, Jan 17, 2023 at 8:17 AM Antoine Pitrou <an...@python.org> wrote:
>
> 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
> 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 them. The
> primary
> > type I have observed in the Arrow repo are bugs that produce
> incorrect or
> > invalid data. Security vulnerabilities are another type. Bugs that
> caused
> > errors or crashes generally wouldn't count, since users are aware of
> the
> > errors they get. (Though I am definitely open to arguments for a
> > different definition or name.)
> >
> > I would additionally propose that these labels are validated during the
> > release process and included in the change notes. By validated, I mean
> > someone should review all the changes in a particular release to make
> sure
> > all relevant issues are tagged with these labels. These are the two kinds
> > of issues I think users will most want to know about when considering
> > upgrading an Arrow library: what APIs changed? And what's the risk of not
> > upgrading?
> >
> > I am willing to be responsible for maintaining these labels for the next
> > few releases for Python, R, and C++. I have been compiling the list of
> > these issues for past versions, as part of my work for my employer, so
> I'm
> > on the hook for this regardless. Having these labels available and used
> by
> > developers and reviewers would make that work much easier. And, of
> course,
> > our users would benefit by having this information easily available in
> our
> > release notes.
> >
> > It's also worth mentioning these two labels are useful if we decide to
> > change how we do releases. The breaking-change label can help decide
> > whether we actually need to increment the major version. And the
> > critical-fix label can help guide which bug fixes are worth applying to
> > older supported releases. I don't think we are ready for either of those
> > yet, but I thought it's worth connecting those dots.
> >
> > Best,
> >
> > Will Jones
> >
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Antoine Pitrou <an...@python.org>.
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 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 them. The primary
> type I have observed in the Arrow repo are bugs that produce incorrect or
> invalid data. Security vulnerabilities are another type. Bugs that caused
> errors or crashes generally wouldn't count, since users are aware of the
> errors they get. (Though I am definitely open to arguments for a
> different definition or name.)
>
> I would additionally propose that these labels are validated during the
> release process and included in the change notes. By validated, I mean
> someone should review all the changes in a particular release to make sure
> all relevant issues are tagged with these labels. These are the two kinds
> of issues I think users will most want to know about when considering
> upgrading an Arrow library: what APIs changed? And what's the risk of not
> upgrading?
>
> I am willing to be responsible for maintaining these labels for the next
> few releases for Python, R, and C++. I have been compiling the list of
> these issues for past versions, as part of my work for my employer, so I'm
> on the hook for this regardless. Having these labels available and used by
> developers and reviewers would make that work much easier. And, of course,
> our users would benefit by having this information easily available in our
> release notes.
>
> It's also worth mentioning these two labels are useful if we decide to
> change how we do releases. The breaking-change label can help decide
> whether we actually need to increment the major version. And the
> critical-fix label can help guide which bug fixes are worth applying to
> older supported releases. I don't think we are ready for either of those
> yet, but I thought it's worth connecting those dots.
>
> Best,
>
> Will Jones
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Matt Topol <zo...@gmail.com>.
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 <em...@gmail.com>
wrote:
> 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 <wi...@gmail.com> wrote:
>
> > 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 them. The
> > primary
> > type I have observed in the Arrow repo are bugs that produce incorrect
> > or
> > invalid data. Security vulnerabilities are another type. Bugs that
> > caused
> > errors or crashes generally wouldn't count, since users are aware of
> the
> > errors they get. (Though I am definitely open to arguments for a
> > different definition or name.)
> >
> > I would additionally propose that these labels are validated during the
> > release process and included in the change notes. By validated, I mean
> > someone should review all the changes in a particular release to make
> sure
> > all relevant issues are tagged with these labels. These are the two kinds
> > of issues I think users will most want to know about when considering
> > upgrading an Arrow library: what APIs changed? And what's the risk of not
> > upgrading?
> >
> > I am willing to be responsible for maintaining these labels for the next
> > few releases for Python, R, and C++. I have been compiling the list of
> > these issues for past versions, as part of my work for my employer, so
> I'm
> > on the hook for this regardless. Having these labels available and used
> by
> > developers and reviewers would make that work much easier. And, of
> course,
> > our users would benefit by having this information easily available in
> our
> > release notes.
> >
> > It's also worth mentioning these two labels are useful if we decide to
> > change how we do releases. The breaking-change label can help decide
> > whether we actually need to increment the major version. And the
> > critical-fix label can help guide which bug fixes are worth applying to
> > older supported releases. I don't think we are ready for either of those
> > yet, but I thought it's worth connecting those dots.
> >
> > Best,
> >
> > Will Jones
> >
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Micah Kornfield <em...@gmail.com>.
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 <wi...@gmail.com> wrote:
> 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 them. The
> primary
> type I have observed in the Arrow repo are bugs that produce incorrect
> or
> invalid data. Security vulnerabilities are another type. Bugs that
> caused
> errors or crashes generally wouldn't count, since users are aware of the
> errors they get. (Though I am definitely open to arguments for a
> different definition or name.)
>
> I would additionally propose that these labels are validated during the
> release process and included in the change notes. By validated, I mean
> someone should review all the changes in a particular release to make sure
> all relevant issues are tagged with these labels. These are the two kinds
> of issues I think users will most want to know about when considering
> upgrading an Arrow library: what APIs changed? And what's the risk of not
> upgrading?
>
> I am willing to be responsible for maintaining these labels for the next
> few releases for Python, R, and C++. I have been compiling the list of
> these issues for past versions, as part of my work for my employer, so I'm
> on the hook for this regardless. Having these labels available and used by
> developers and reviewers would make that work much easier. And, of course,
> our users would benefit by having this information easily available in our
> release notes.
>
> It's also worth mentioning these two labels are useful if we decide to
> change how we do releases. The breaking-change label can help decide
> whether we actually need to increment the major version. And the
> critical-fix label can help guide which bug fixes are worth applying to
> older supported releases. I don't think we are ready for either of those
> yet, but I thought it's worth connecting those dots.
>
> Best,
>
> Will Jones
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Will Jones <wi...@gmail.com>.
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 <an...@python.org> wrote:
>
> 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 a null pointer where non-null is
> expected).
>
> Regards
>
> Antoine.
>
>
> Le 14/01/2023 à 17:47, Weston Pace a écrit :
> > 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 invalid input, is not critical
> >
> >
> >
> > On Sat, Jan 14, 2023, 8:12 AM Antoine Pitrou <an...@python.org> wrote:
> >
> >>
> >> 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 something
> >>> else? On "Critical Fix", I tried to make the definition provided not
> very
> >>> ambiguous, but the PR is open for feedback.
> >>>
> >>> Keep in mind, I am planning on grooming these labels once every
> release,
> >>> and including them in the generation of the changes notes. So any drift
> >> in
> >>> the definition will be corrected before the final list of breaking
> >> changes
> >>> and critical fixes are published.
> >>
> >> That clears my concerns then :-)
> >>
> >> However, I think that an additional "Priority: critical" isn't very
> >> useful and will end up confusing people.
> >>
> >> Regards
> >>
> >> Antoine.
> >>
> >
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Antoine Pitrou <an...@python.org>.
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 a null pointer where non-null is
expected).
Regards
Antoine.
Le 14/01/2023 à 17:47, Weston Pace a écrit :
> 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 invalid input, is not critical
>
>
>
> On Sat, Jan 14, 2023, 8:12 AM Antoine Pitrou <an...@python.org> wrote:
>
>>
>> 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 something
>>> else? On "Critical Fix", I tried to make the definition provided not very
>>> ambiguous, but the PR is open for feedback.
>>>
>>> Keep in mind, I am planning on grooming these labels once every release,
>>> and including them in the generation of the changes notes. So any drift
>> in
>>> the definition will be corrected before the final list of breaking
>> changes
>>> and critical fixes are published.
>>
>> That clears my concerns then :-)
>>
>> However, I think that an additional "Priority: critical" isn't very
>> useful and will end up confusing people.
>>
>> Regards
>>
>> Antoine.
>>
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Weston Pace <we...@gmail.com>.
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 invalid input, is not critical
On Sat, Jan 14, 2023, 8:12 AM Antoine Pitrou <an...@python.org> wrote:
>
> 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 something
> > else? On "Critical Fix", I tried to make the definition provided not very
> > ambiguous, but the PR is open for feedback.
> >
> > Keep in mind, I am planning on grooming these labels once every release,
> > and including them in the generation of the changes notes. So any drift
> in
> > the definition will be corrected before the final list of breaking
> changes
> > and critical fixes are published.
>
> That clears my concerns then :-)
>
> However, I think that an additional "Priority: critical" isn't very
> useful and will end up confusing people.
>
> Regards
>
> Antoine.
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Antoine Pitrou <an...@python.org>.
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 something
> else? On "Critical Fix", I tried to make the definition provided not very
> ambiguous, but the PR is open for feedback.
>
> Keep in mind, I am planning on grooming these labels once every release,
> and including them in the generation of the changes notes. So any drift in
> the definition will be corrected before the final list of breaking changes
> and critical fixes are published.
That clears my concerns then :-)
However, I think that an additional "Priority: critical" isn't very
useful and will end up confusing people.
Regards
Antoine.
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Will Jones <wi...@gmail.com>.
>
> 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 the definition provided not very
ambiguous, but the PR is open for feedback.
Keep in mind, I am planning on grooming these labels once every release,
and including them in the generation of the changes notes. So any drift in
the definition will be corrected before the final list of breaking changes
and critical fixes are published.
But understandable if you are skeptical. After the 12.0.0 release we should
revisit, and if we don't find one or both of these labels useful we can
drop them out of use.
On Sat, Jan 14, 2023 at 6:15 AM Antoine Pitrou <an...@python.org> wrote:
>
> 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 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 <ro...@gmail.com> wrote:
> >
> >>>
> >>> 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
> >>> confusing. Perhaps I can draft a full definition of "Critical Fix", and
> >>> then we can discuss based on that? (I assume at the very least that
> >>> Priority Critical never refers to features, right?)
> >>>
> >>> [1] https://github.com/apache/arrow/issues/14593
> >>>
> >>
> >> Agreed on the Priority: Blocker and Priority: Critical.
> >> A shared definition would indeed be useful! I think best place to put it
> >> would be in the issue creation interface [2].
> >>
> >> [2]
> >>
> >>
> https://github.com/apache/arrow/issues/new?assignees=&labels=Type%3A+bug&template=bug_report.yaml
> >>
> >> Rok
> >>
> >
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Antoine Pitrou <an...@python.org>.
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 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 <ro...@gmail.com> wrote:
>
>>>
>>> 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
>>> confusing. Perhaps I can draft a full definition of "Critical Fix", and
>>> then we can discuss based on that? (I assume at the very least that
>>> Priority Critical never refers to features, right?)
>>>
>>> [1] https://github.com/apache/arrow/issues/14593
>>>
>>
>> Agreed on the Priority: Blocker and Priority: Critical.
>> A shared definition would indeed be useful! I think best place to put it
>> would be in the issue creation interface [2].
>>
>> [2]
>>
>> https://github.com/apache/arrow/issues/new?assignees=&labels=Type%3A+bug&template=bug_report.yaml
>>
>> Rok
>>
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Will Jones <wi...@gmail.com>.
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 <ro...@gmail.com> wrote:
> >
> > 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
> > confusing. Perhaps I can draft a full definition of "Critical Fix", and
> > then we can discuss based on that? (I assume at the very least that
> > Priority Critical never refers to features, right?)
> >
> > [1] https://github.com/apache/arrow/issues/14593
> >
>
> Agreed on the Priority: Blocker and Priority: Critical.
> A shared definition would indeed be useful! I think best place to put it
> would be in the issue creation interface [2].
>
> [2]
>
> https://github.com/apache/arrow/issues/new?assignees=&labels=Type%3A+bug&template=bug_report.yaml
>
> Rok
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Rok Mihevc <ro...@gmail.com>.
>
> 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
> confusing. Perhaps I can draft a full definition of "Critical Fix", and
> then we can discuss based on that? (I assume at the very least that
> Priority Critical never refers to features, right?)
>
> [1] https://github.com/apache/arrow/issues/14593
>
Agreed on the Priority: Blocker and Priority: Critical.
A shared definition would indeed be useful! I think best place to put it
would be in the issue creation interface [2].
[2]
https://github.com/apache/arrow/issues/new?assignees=&labels=Type%3A+bug&template=bug_report.yaml
Rok
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Will Jones <wi...@gmail.com>.
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 with this next week.
Rok,
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: "Priority: Blocker", "Priority:
> Critical", "Priority: Major", "Priority: Minor", "Priority: Trivial",
> "good-second-issue". This would give us a better mapping to Jira. See
> discussion here [1].
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
confusing. Perhaps I can draft a full definition of "Critical Fix", and
then we can discuss based on that? (I assume at the very least that
Priority Critical never refers to features, right?)
[1] https://github.com/apache/arrow/issues/14593
On Fri, Jan 6, 2023 at 12:50 PM Matthew Topol <ma...@voltrondata.com.invalid>
wrote:
> > 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 breaking changes and otherwise features would go out with minor
> releases. Bugfixes staying with patch releases.
>
> That's just how I think of them though, obviously there's difficulty with a
> monorepo in being sure we know what is or isn't a breaking change (which
> the proposed labels will absolutely help with). While the label doesn't
> solve the complexities, it definitely moves us forward I think.
>
> --Matt
>
> On Fri, Jan 6, 2023 at 3:44 PM Rok Mihevc <ro...@gmail.com> wrote:
>
> > 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: "Priority: Blocker", "Priority:
> > Critical", "Priority: Major", "Priority: Minor", "Priority: Trivial",
> > "good-second-issue". This would give us a better mapping to Jira. See
> > discussion here [1].
> >
> > [1] https://github.com/apache/arrow/issues/14593
> >
> > Rok
> >
> >
> > On Fri, Jan 6, 2023 at 6:49 PM Antoine Pitrou <an...@python.org>
> wrote:
> >
> > >
> > > 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 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
> > > 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 them.
> The
> > > primary
> > > > type I have observed in the Arrow repo are bugs that produce
> > > incorrect or
> > > > invalid data. Security vulnerabilities are another type. Bugs
> that
> > > caused
> > > > errors or crashes generally wouldn't count, since users are aware
> > of
> > > the
> > > > errors they get. (Though I am definitely open to arguments for a
> > > > different definition or name.)
> > > >
> > > > I would additionally propose that these labels are validated during
> the
> > > > release process and included in the change notes. By validated, I
> mean
> > > > someone should review all the changes in a particular release to make
> > > sure
> > > > all relevant issues are tagged with these labels. These are the two
> > kinds
> > > > of issues I think users will most want to know about when considering
> > > > upgrading an Arrow library: what APIs changed? And what's the risk of
> > not
> > > > upgrading?
> > > >
> > > > I am willing to be responsible for maintaining these labels for the
> > next
> > > > few releases for Python, R, and C++. I have been compiling the list
> of
> > > > these issues for past versions, as part of my work for my employer,
> so
> > > I'm
> > > > on the hook for this regardless. Having these labels available and
> used
> > > by
> > > > developers and reviewers would make that work much easier. And, of
> > > course,
> > > > our users would benefit by having this information easily available
> in
> > > our
> > > > release notes.
> > > >
> > > > It's also worth mentioning these two labels are useful if we decide
> to
> > > > change how we do releases. The breaking-change label can help decide
> > > > whether we actually need to increment the major version. And the
> > > > critical-fix label can help guide which bug fixes are worth applying
> to
> > > > older supported releases. I don't think we are ready for either of
> > those
> > > > yet, but I thought it's worth connecting those dots.
> > > >
> > > > Best,
> > > >
> > > > Will Jones
> > > >
> > >
> >
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Matthew Topol <ma...@voltrondata.com.INVALID>.
> 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 breaking changes and otherwise features would go out with minor
releases. Bugfixes staying with patch releases.
That's just how I think of them though, obviously there's difficulty with a
monorepo in being sure we know what is or isn't a breaking change (which
the proposed labels will absolutely help with). While the label doesn't
solve the complexities, it definitely moves us forward I think.
--Matt
On Fri, Jan 6, 2023 at 3:44 PM Rok Mihevc <ro...@gmail.com> wrote:
> 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: "Priority: Blocker", "Priority:
> Critical", "Priority: Major", "Priority: Minor", "Priority: Trivial",
> "good-second-issue". This would give us a better mapping to Jira. See
> discussion here [1].
>
> [1] https://github.com/apache/arrow/issues/14593
>
> Rok
>
>
> On Fri, Jan 6, 2023 at 6:49 PM Antoine Pitrou <an...@python.org> wrote:
>
> >
> > 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 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
> > 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 them. The
> > primary
> > > type I have observed in the Arrow repo are bugs that produce
> > incorrect or
> > > invalid data. Security vulnerabilities are another type. Bugs that
> > caused
> > > errors or crashes generally wouldn't count, since users are aware
> of
> > the
> > > errors they get. (Though I am definitely open to arguments for a
> > > different definition or name.)
> > >
> > > I would additionally propose that these labels are validated during the
> > > release process and included in the change notes. By validated, I mean
> > > someone should review all the changes in a particular release to make
> > sure
> > > all relevant issues are tagged with these labels. These are the two
> kinds
> > > of issues I think users will most want to know about when considering
> > > upgrading an Arrow library: what APIs changed? And what's the risk of
> not
> > > upgrading?
> > >
> > > I am willing to be responsible for maintaining these labels for the
> next
> > > few releases for Python, R, and C++. I have been compiling the list of
> > > these issues for past versions, as part of my work for my employer, so
> > I'm
> > > on the hook for this regardless. Having these labels available and used
> > by
> > > developers and reviewers would make that work much easier. And, of
> > course,
> > > our users would benefit by having this information easily available in
> > our
> > > release notes.
> > >
> > > It's also worth mentioning these two labels are useful if we decide to
> > > change how we do releases. The breaking-change label can help decide
> > > whether we actually need to increment the major version. And the
> > > critical-fix label can help guide which bug fixes are worth applying to
> > > older supported releases. I don't think we are ready for either of
> those
> > > yet, but I thought it's worth connecting those dots.
> > >
> > > Best,
> > >
> > > Will Jones
> > >
> >
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Rok Mihevc <ro...@gmail.com>.
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: "Priority: Blocker", "Priority:
Critical", "Priority: Major", "Priority: Minor", "Priority: Trivial",
"good-second-issue". This would give us a better mapping to Jira. See
discussion here [1].
[1] https://github.com/apache/arrow/issues/14593
Rok
On Fri, Jan 6, 2023 at 6:49 PM Antoine Pitrou <an...@python.org> wrote:
>
> 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 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
> 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 them. The
> primary
> > type I have observed in the Arrow repo are bugs that produce
> incorrect or
> > invalid data. Security vulnerabilities are another type. Bugs that
> caused
> > errors or crashes generally wouldn't count, since users are aware of
> the
> > errors they get. (Though I am definitely open to arguments for a
> > different definition or name.)
> >
> > I would additionally propose that these labels are validated during the
> > release process and included in the change notes. By validated, I mean
> > someone should review all the changes in a particular release to make
> sure
> > all relevant issues are tagged with these labels. These are the two kinds
> > of issues I think users will most want to know about when considering
> > upgrading an Arrow library: what APIs changed? And what's the risk of not
> > upgrading?
> >
> > I am willing to be responsible for maintaining these labels for the next
> > few releases for Python, R, and C++. I have been compiling the list of
> > these issues for past versions, as part of my work for my employer, so
> I'm
> > on the hook for this regardless. Having these labels available and used
> by
> > developers and reviewers would make that work much easier. And, of
> course,
> > our users would benefit by having this information easily available in
> our
> > release notes.
> >
> > It's also worth mentioning these two labels are useful if we decide to
> > change how we do releases. The breaking-change label can help decide
> > whether we actually need to increment the major version. And the
> > critical-fix label can help guide which bug fixes are worth applying to
> > older supported releases. I don't think we are ready for either of those
> > yet, but I thought it's worth connecting those dots.
> >
> > Best,
> >
> > Will Jones
> >
>
Re: [Monorepo] Add labels breaking-change and critical-fix
Posted by Antoine Pitrou <an...@python.org>.
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 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 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 them. The primary
> type I have observed in the Arrow repo are bugs that produce incorrect or
> invalid data. Security vulnerabilities are another type. Bugs that caused
> errors or crashes generally wouldn't count, since users are aware of the
> errors they get. (Though I am definitely open to arguments for a
> different definition or name.)
>
> I would additionally propose that these labels are validated during the
> release process and included in the change notes. By validated, I mean
> someone should review all the changes in a particular release to make sure
> all relevant issues are tagged with these labels. These are the two kinds
> of issues I think users will most want to know about when considering
> upgrading an Arrow library: what APIs changed? And what's the risk of not
> upgrading?
>
> I am willing to be responsible for maintaining these labels for the next
> few releases for Python, R, and C++. I have been compiling the list of
> these issues for past versions, as part of my work for my employer, so I'm
> on the hook for this regardless. Having these labels available and used by
> developers and reviewers would make that work much easier. And, of course,
> our users would benefit by having this information easily available in our
> release notes.
>
> It's also worth mentioning these two labels are useful if we decide to
> change how we do releases. The breaking-change label can help decide
> whether we actually need to increment the major version. And the
> critical-fix label can help guide which bug fixes are worth applying to
> older supported releases. I don't think we are ready for either of those
> yet, but I thought it's worth connecting those dots.
>
> Best,
>
> Will Jones
>