On Thu, Oct 20, 2022 at 11:31 AM Jacob Wujciak <ja...@voltrondata.com.invalid> wrote:
> This is definitively an important topic that should be discussed. I just > want to point out that there is no difference between a major, minor or > patch release with regards to the ASF process. Any official release needs a > vote and a PMC to act as a release manager to sign & upload the release > (which is the only step we can not automate). We would also need to do most > of the usual post release tasks (if it is not a go only patch as happened > before). So the work required for the actual release is the same, minus the > usual pre-release hustle to finish features in time etc.. > A minor (patch?) point on that: we voted in February 2021 that patch releases can be source-only, i.e. we don't necessarily have to go through all of the binary verification and updating for all implementations: https://lists.apache.org/thread/1r9t7o9739v0n4lsm8bvgppt9whrzq45 Still need a vote and a release manager, but there is potentially less friction from other sources. Neal > > I think this might also be a good time to bring up the discussion about our > versioning scheme again as there might be synergies there but I know that > this is already a complex topic so let's focus on the maintenance policy > first. > > Jacob > > On Wed, Oct 19, 2022 at 9:01 PM Matt Topol <zotthewiz...@gmail.com> wrote: > > > I agree with Will's suggestion, and I also suggest that another type we > > should always backport would be any identified security vulnerability or > > issue. > > > > --Matt > > > > On Wed, Oct 19, 2022 at 1:48 PM Will Jones <will.jones...@gmail.com> > > wrote: > > > > > One particular type of defect we might want to consider backporting to > > > supported versions are ones that silently produce incorrect data. > Unlike > > > ones that cause a crash, it's not easy for a user to know they are > > > affected. > > > > > > Here are a few examples: > > > > > > * ARROW-17453: [Go][C++][Parquet] Inconsistent Data with Repetition > > Levels > > > [1] (fixed in 10.0.0) > > > * ARROW-17995: [C++] Fix json decimals not being rescaled based on the > > > explicit schema [2] (fixed in 10.0.0) > > > * ARROW-14523: [C++] Fix potential data loss in S3 multipart upload > [3] > > > (fixed in 7.0.0) > > > > > > Also, I know we have high release costs for new versions, but is that > > also > > > true for backporting fixes? Unlike new releases, if we were creating a > > > bugfix release, we are presumably starting from a much more stable > point, > > > right? > > > > > > Thanks, > > > > > > Will Jones > > > > > > [1] https://issues.apache.org/jira/browse/ARROW-17453 > > > [2] https://issues.apache.org/jira/browse/ARROW-17995 > > > [3] https://issues.apache.org/jira/browse/ARROW-14523 > > > > > > On Wed, Oct 19, 2022 at 9:32 AM Todd Farmer > <t...@voltrondata.com.invalid > > > > > > wrote: > > > > > > > Hi, > > > > > > > > I've been thinking a lot about maintenance and lifecycle policies and > > > > defect classification recently - I'm very grateful this is being > > raised. > > > I > > > > believe establishing such policies will prove instrumental to enable > > > > adoption of Arrow for a number of use cases that prioritize stability > > > over > > > > innovation. > > > > > > > > On Wed, Oct 19, 2022 at 5:42 AM Antoine Pitrou <anto...@python.org> > > > wrote: > > > > > > > > > > > > > > Hi Kou, > > > > > > > > > > Le 19/10/2022 à 06:29, Sutou Kouhei a écrit : > > > > > > > > > > > > My proposal: We maintain the last major release: > > > > > > * We maintain 9.Y.Z when the latest major release is 9.0.0 > > > > > > * We may release 9.Y.Z when we find a problem such as a > > > > > > security vulnerability in 9.Y.Z > > > > > > * We drop support for 9.Y.Z when we release 10.0.0 > > > > > > > > > > That sounds ok to me, but is there a more precise criterion than > "we > > > > > find a problem"? > > > > > > > > > > In the past, we have from time to time done maintenance releases > > based > > > > > on annoying bugs/regressions. But not always. > > > > > > > > > > > > > I very much agree, and actually think there are multiple questions to > > > > answer here: > > > > > > > > 1. Which class of defects should be allowed to be merged into a > > > maintenance > > > > branch? > > > > 2. Which class of defects must be fixed in a supported maintenance > > > branch? > > > > 3. Which class of defects should trigger a maintenance release once a > > fix > > > > is made to the branch? > > > > 4. Which versions should be targeted in backporting a defect fix? > How > > > long > > > > will a release receive maintenance support? > > > > 5. Which class of defects can be batched into a future maintenance > > > release, > > > > and which need immediate release? > > > > 6. What delivery artifacts are needed for maintenance releases? Can > > some > > > > things be source-only? > > > > > > > > Today, any fix may be a candidate for backporting to a maintenance > > branch > > > > if there's support for doing so in a vote. I believe it might be > useful > > > to > > > > more formally triage defects in part to establish policy answering > > these > > > > questions. For example: > > > > > > > > * How severe is the defect? Does it produce wrong results? Cause > > > crashes? > > > > Or is it an annoying spelling error in a log message? > > > > * How widespread is the impact? Is everybody who uses Arrow going to > be > > > > affected by this? Or is it only triggered by some very obscure use > > case? > > > > * How accessible is any workaround? > > > > * How much risk is involved in a fix? > > > > > > > > Having a common framework to classify those elements above would > enable > > > > policy that clearly defines which defects can (or should, eventually) > > get > > > > what attention. > > > > > > > > If there is interest in the community, I'll continue a draft proposal > > I'm > > > > working on to formalize triage to capture these aspects. Any such > > triage > > > > process would be entirely optional for work done against master/main, > > but > > > > could be required for assessing potential backports as needed. > > > > > > > > I'll also note that I recognize Arrow may not currently see a need to > > > > answer all the questions about maintenance/lifecycle policy today, or > > may > > > > not have the resources needed to deliver what may be desired. It > takes > > a > > > > lot of work to generate a release today. I think it's completely > > > > appropriate to commit only to what can be delivered today, with an > eye > > > > towards incremental improvement. For example, an entirely acceptable > > > policy > > > > might be: > > > > > > > > * Only the most recently-released minor version is eligible for > defect > > > > fixes. > > > > * Security vulnerabilities with CVSS 3.0 score >= 7.0 (High) should > > > trigger > > > > a maintenance release. > > > > * Fixes for defects of any nature may be backported if it reaches > > > > established thresholds (TBD) for severity, widespread impact, > > workaround > > > > accessibility and risk. Such fixes will be incorporated into the > > release > > > > maintenance release, made available via source, but no release will > be > > > > produced unless triggered by a subsequent security vulnerability fix. > > > > > > > > > > > > > > I think that we can maintain multiple major releases with > > > > > > not high release cost by implementing the followings: > > > > > > * Green nightly CI > > > > > > * Nightly CI for all maintained branches (maint-X.Y.Z) > > > > > > * We need to reduce the time taken to CI > > > > > > * ... > > > > > > > > > > I'm afraid "green nightly CI" is more of an ideal than a reality > > given > > > > > the breadth and complexity of our fleet of CI jobs. We still seem > to > > > > > have stability problems in some areas (perhaps Acero?) but there > are > > > > > also regularly regressions due to changes in third-party packages. > > > > > > > > > > > > > Would this still be true if executed against a maintenance release > > > branch? > > > > I understand why this would drift for main/master, but if a version > > > branch > > > > is green when first released, and only accepts limited, qualified > > > > backported fixes, it should be much easier to "keep" green, I'd > think. > > > > > > > > Thanks, > > > > > > > > Todd > > > > > > > > > >
