Thank you for the input from all of you! So to summarize, we see neither the need nor a realistic possibility to collect critical fixes to 1.3.0. I agree that it is unfortunate to support only the latest release, however as we did not put too much effort to keep any release supportable with all critical fixes in a longer term, this might be something I would live with rather than doing just security fixes.
It would be really nice to hear from folks who are actually dealing with running the community version, and how they manage to get fixes without frequent bugfix releases. I would guess they are in the same boat as we are in Cloudera, and they are doing internal builds that are rolled out on test clusters first, and then going live in production clusters. If this assumption holds true, then it is probably not necessary to even provide the security fix for 1.3. So I would encourage other community members than Cloudera folks to share your view on this matter please! I tend to believe that it does not really matter whether we release 1.3.something or not with the fix for the CVE only, so if that is widely accepted that cherry picking critical fixes is something we won't do, then I would just drop support for 1.3 as well, and would try to concentrate on defining what support means for the project, but in order to do that, we I believe need input from others, so that we do not choose a policy that is just an unnecessary overhead at the moment. I would propose the following based on the above: 1. drop support for 1.3. and prior releases in our documentation (as we do not seem to provide meaningful amount of fixes) 2. Discuss further and collect inputs on what release cadence and what support policy would suffice for the project to be better aligned with real operations without the need of cherry-picking and internally releasing fixes. If no-one objects this approach in the first point, I would like to put up a PR early next week and will post a link here, so late objections can also be made there but we then can push the related changes to our docs next week, in the meantime I am also happy to have feedback on the second point, so we can start introducing better practices to make it possible to create patch releases for older x.x.0 releases. Thank you! Pifta Sumit Agrawal <sumitagra...@cloudera.com.invalid> ezt írta (időpont: 2024. febr. 14., Sze, 3:40): > I think we can choose option "1" if any one is using 1.3.0 release, > 1. Define support as “security fixes only” and include support for 1.3.0 > > Incoming bugs are quite high, so fixing in the old version will be > difficult at this point of time, can upgrade to a higher version. > > Regards > Sumit > > On Wed, Feb 14, 2024 at 4:04 AM Ethan Rose <er...@apache.org> wrote: > > > While I would also be surprised if people are successfully running an > > unpatched version of 1.3.0, it seems like a circular dependency to decide > > which versions to support based on what people are using. People will > > generally prefer to use supported versions so our messaging here informs > > their decision. > > > > I think the question to ask (which Pifta implied with the options > > presented) is how do we define support? Is it just security fixes, or > also > > critical bug fixes (data loss or service outage) or even other more minor > > bug fixes? Given the speed that Ozone development and fixes are > happening, > > we saw a comprehensive 1.3.1 bug fix release to be too large and that’s > why > > the effort was abandoned. While a critical bug fix release might be more > > manageable, I haven’t seen an effort to initiate this in practice. Based > on > > this experience, these seem like the two best options to me: > > > > 1. Define support as “security fixes only” and include support for > 1.3.0 > > 2. Define support as “security and critical bug fixes only” and drop > > support for 1.3.0 > > > > I am in favor of option 1 because I think the optics of completely > dropping > > support for the immediately previous version are not good. Also due to > the > > velocity that bug fixes are coming in, I don’t see us cherry-picking bug > > fixes to do a 1.4.1 release, but instead doing 1.5.0 from master. By > > defining support as “security only” we are being up-front with our > > intentions and upgrade recommendations, since as Stephen highlighted > > remaining on 1.3.0 is not recommended for stability. > > > > With either option, more frequent releases will help since we could > support > > the last X versions, but those versions could still be less than a year > > old. Higher release frequency is a topic for another thread though. > > > > Ethan > > > > On Mon, Feb 12, 2024 at 3:00 AM Stephen O'Donnell > > <sodonn...@cloudera.com.invalid> wrote: > > > > > The first question I have is: > > > > > > Is anyone running 1.3.0 in production today? > > > > > > That release is over a year old and there are many known problems that > > have > > > been fixed on 1.4.0. I would be quite surprised if anyone is running > > 1.3.0 > > > successfully without some additional custom patches on top of it. If > they > > > have a patched 1.3.0, then a new release won't help, as it would be > > easier > > > to just cherry pick the CVE fix on top of their custom build. > > > > > > > > > On Mon, Feb 12, 2024 at 10:39 AM István Fajth <fapi...@gmail.com> > wrote: > > > > > > > Hi developers, > > > > > > > > Me and Attila had a discussion about a PR > > > > <https://github.com/apache/ozone/pull/6100> that is posted by > > > @ivandika3. > > > > > > > > In our SECURITY.md file we have a table about our supported versions. > > > > In light of the recent CVE, the idea is to remove the supported flag > > from > > > > any release prior to 1.3.0, and leave 1.3.0 and 1.4.0 supported. > > > > > > > > I tend to believe this is something that is reasonable considering > that > > > > 1.2.1 is over 2 years old. > > > > > > > > However, leaving 1.3.0 supported means that we should release 1.3.1 > in > > > > order to have the recently released CVE-2023-39196 fixed for the > 1.3.x > > > > line. > > > > There was an effort earlier to release 1.3.1, but we have abandoned > > that > > > > effort. > > > > > > > > *What do you think, which way should we manage this?* > > > > 1. Leave 1.3.1 branch as it is cherry-pick the CVE fix, and release > it? > > > > 2. Leave 1.3.1 alone, and release the fix for the CVE from a new > branch > > > as > > > > (a) 1.3.0.1, or (b)1.3.2? > > > > 3. Prepare a proper 1.3.1 release with all the critical fixes that we > > > have, > > > > including the fix for the CVE? > > > > 4. Mark 1.3.0 unsupported which is also something that I can imagine, > > > > however that release is just over 1 year old. > > > > > > > > A minimalistic approach - As we dropped the idea of 1.3.1 already - > to > > > just > > > > go with 2a. > > > > The simplest is to choose to drop support for 1.3.0. > > > > If we support 1.3.0 today, and we want to do it right, then releasing > > > 1.3.1 > > > > in the next 1-2 weeks seems to be the proper approach. > > > > > > > > I am +1 for all these 3 approaches and I am not against the approach > > > listed > > > > in point 1., however I do not support it either. > > > > I can not - at the moment - take on a full 1.3.1 release, so if the > > > > community decides to go that route, we will need a release manager > also > > > for > > > > that. > > > > > > > > What I can volunteer for, is to update the SECURITY.md based on the > > > > decision, and in case a minimalistic release approach is taken (2a or > > > 2b), > > > > I can take on releasing that. > > > > > > > > -- > > > > Pifta > > > > > > > > > > > > -- > *Sumit Agrawal* | Senior Staff Engineer > cloudera.com <https://www.cloudera.com> > [image: Cloudera] <https://www.cloudera.com/> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera > on LinkedIn] <https://www.linkedin.com/company/cloudera> > ------------------------------ > -- Pifta
