PR is reviewed and merged. Thank you all for the input. If you did not have a chance to share your feedback, please propose any modifications that you would like to see. I will be more than happy to make changes that would allows us to serve our users better.
On Tue, Aug 14, 2018 at 4:32 PM, Ahmet Altay <[email protected]> wrote: > Still waiting for any additional user feedback to come. I added reviewers > to the PR. Unless there is objections or additional feedback I would like > to go ahead with this version as it is. Modifications after that would > always be welcome. > > On Mon, Aug 13, 2018 at 2:06 PM, Rafael Fernandez <[email protected]> > wrote: > >> I think this will great for the project! It's worked well for others >> (such as Ubuntu). I like that this remains compatible with our desire to >> release every six weeks, while keeping the support/patch load manageable. >> >> Release: +1 single process. This is just a statement of what we commit to >> service. >> >> On Mon, Aug 13, 2018 at 12:31 PM Ahmet Altay <[email protected]> wrote: >> >>> I was not proposing any additional changes to the release process. If we >>> think that release process could be improved it would make sense to apply >>> it to all releases. >>> >>> On Mon, Aug 13, 2018 at 11:01 AM, Lukasz Cwik <[email protected]> wrote: >>> >>>> Charles, I would keep the process the same with respect to releasing. >>>> >>>> On Mon, Aug 13, 2018 at 11:00 AM Charles Chen <[email protected]> wrote: >>>> >>>>> (sending to the dev@ list thread as this is more relevant here than >>>>> users@) >>>>> >>>>> Will we be using a different / potentially more rigorous process for >>>>> releasing LTS releases? Or do we feel that any validations that could >>>>> possibly be done should already be incorporated into each release? >>>>> >>>>> On Mon, Aug 13, 2018 at 10:57 AM Ahmet Altay <[email protected]> wrote: >>>>> >>>>>> Update: >>>>>> >>>>>> I sent out an email to user@ to collect their feedback [1]. I will >>>>>> encourage everyone here to collect feedback from the other channels >>>>>> available to you. To facilitate the discussion I drafted my proposal in a >>>>>> PR [2]. >>>>>> >>>>>> Ahmet >>>>>> >>>>>> [1] https://lists.apache.org/thread.html/7d890d6ed221c722a95 >>>>>> d9c773583450767b79ee0c0c78f48a56c7eba@%3Cuser.beam.apache.org%3E >>>>>> [2] https://github.com/apache/beam-site/pull/537 >>>>>> >>>>>> On Fri, Aug 10, 2018 at 5:20 PM, Lukasz Cwik <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks, I can see the reasoning for LTS releases based upon some >>>>>>> enterprise customers needs. >>>>>>> >>>>>>> Forgot about the 2.1.1 Python release. Thanks for pointing that out. >>>>>>> >>>>>>> On Fri, Aug 10, 2018 at 4:47 PM Ahmet Altay <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 10, 2018 at 12:33 PM, Lukasz Cwik <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I like the ideas that your proposing but am wondering what value >>>>>>>>> if any do supporting LTS releases add? We maintain semantic >>>>>>>>> versioning and >>>>>>>>> I would expect that most users would be using the latest released >>>>>>>>> version >>>>>>>>> if not the release just before that. There is likely a long tail of >>>>>>>>> users >>>>>>>>> who will use a specific version and are unlikely to ever upgrade. >>>>>>>>> >>>>>>>> >>>>>>>> I believe there is a category of enterprise users who would >>>>>>>> continue to use a specific version as long as they know they can get >>>>>>>> support for it. This usually stems from the need to have a stable >>>>>>>> environment. There is also the aspect of validating new product before >>>>>>>> using. I know some companies have validation cycles longer than 6 >>>>>>>> weeks. >>>>>>>> They will still upgrade but they would like to upgrade much less >>>>>>>> frequently. >>>>>>>> >>>>>>>> I was hoping that defining LTS releases will signal these types of >>>>>>>> users what releases are worth upgrading to if they have a high cost of >>>>>>>> upgrading. >>>>>>>> >>>>>>>> This comes from my anecdotal evidence and I may be wrong. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I believe it would be valuable to ask our users what is most >>>>>>>>> important to them with respect to the policy (after we have discussed >>>>>>>>> it a >>>>>>>>> little bit) as well since ultimately our goal is to help our users. >>>>>>>>> >>>>>>>> >>>>>>>> I agree with this. Since I am referring to enterprise users >>>>>>>> primarily I think some of it will require the companies here to collect >>>>>>>> that feedback. >>>>>>>> >>>>>>>> >>>>>>>>> This could then be documented and we could provide guidance to >>>>>>>>> customers as to how to reach out to the group for big bugs. Also note >>>>>>>>> that >>>>>>>>> Apache has a security policy[1] in place which we should direct users >>>>>>>>> to. >>>>>>>>> >>>>>>>> >>>>>>>> I think document what could be expected of Beam in terms of support >>>>>>>> would be very valuable by itself. It will also help us figure out what >>>>>>>> we >>>>>>>> could drop. For example in the recent discussion to drop old API docs, >>>>>>>> there was no clear guidance on which SDKs are still supported and >>>>>>>> should >>>>>>>> have their API docs hosted. >>>>>>>> >>>>>>>> I think we reference to the Apache security policy on our website. >>>>>>>> If not I agree, we should add a reference to it. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Also, we don't have any experience in patching a release as we >>>>>>>>> haven't yet done one patch version bump. All issues that have been >>>>>>>>> brought >>>>>>>>> up were always fixed in the next minor version bump. >>>>>>>>> >>>>>>>> >>>>>>>> I agree. There was the Python 2.1.1 but that is the only example I >>>>>>>> could remember. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 1: http://www.apache.org/security/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Aug 10, 2018 at 11:50 AM Pablo Estrada <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I think this all sounds reasonable, and I think it would be a >>>>>>>>>> good story for our users. We don't have much experience with patching >>>>>>>>>> releases, but I guess it's a matter of learning and improving over >>>>>>>>>> time. >>>>>>>>>> -P. >>>>>>>>>> >>>>>>>>>> On Wed, Aug 8, 2018 at 9:04 PM Ahmet Altay <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I would like us to clarify the life cycle of Beam releases a >>>>>>>>>>> little bit more for our users. I think we increased the >>>>>>>>>>> predictability >>>>>>>>>>> significantly by agreeing to a release cadence and kudos to >>>>>>>>>>> everyone on >>>>>>>>>>> that. As a follow up to that I would like to address the following >>>>>>>>>>> problem: >>>>>>>>>>> >>>>>>>>>>> It is unclear for a user of Beam how long an existing version >>>>>>>>>>> will be supported. And if it will be supported at all, what does >>>>>>>>>>> that >>>>>>>>>>> support mean. (This is especially an important problem for users >>>>>>>>>>> who would >>>>>>>>>>> like to use stable versions and care less about being on the >>>>>>>>>>> cutting edge.) >>>>>>>>>>> >>>>>>>>>>> Our current state is: >>>>>>>>>>> >>>>>>>>>>> - With our agreed release cadence Beam makes 8 releases a year. >>>>>>>>>>> - We have precedence for patching released versions for major >>>>>>>>>>> issues. >>>>>>>>>>> - Patching all existing releases at any point (even patching a >>>>>>>>>>> year full of 8 releases) will be significant work. >>>>>>>>>>> >>>>>>>>>>> With the problem and the information, I have the following >>>>>>>>>>> proposal to define the life cycle of existing releases. >>>>>>>>>>> >>>>>>>>>>> - Define what is a major issue with Beam. (For example this >>>>>>>>>>> could be high severity security issues and high risk data integrity >>>>>>>>>>> issues.) >>>>>>>>>>> - Have a concept of long term support (LTS) releases. Designate >>>>>>>>>>> every 4th release as an LTS release (~6 months). >>>>>>>>>>> - Deprecate non-LTS releases the moment any new Beam release is >>>>>>>>>>> out. Never patch non-LTS releases. >>>>>>>>>>> - Deprecate LTS releases after a new LTS release comes out. >>>>>>>>>>> Patch any LTS release within 1 year of its initial release date. >>>>>>>>>>> - Add the above information to our website. >>>>>>>>>>> >>>>>>>>>>> I think this proposal would give clear information to our users >>>>>>>>>>> about what they can expect from us, and reduce our burden to >>>>>>>>>>> maintain >>>>>>>>>>> existing releases. >>>>>>>>>>> >>>>>>>>>>> I also would like to state my assumptions: >>>>>>>>>>> >>>>>>>>>>> - Releases will happen not because of a policy but because there >>>>>>>>>>> are volunteers willing to do it. This proposal is only a framework >>>>>>>>>>> for >>>>>>>>>>> those volunteers to take action. If Beam does not support its >>>>>>>>>>> releases, >>>>>>>>>>> with or without a policy, we will reduce the trust of our users. >>>>>>>>>>> - After we agreed to have a regular release cadence we started >>>>>>>>>>> to see improvements towards having regular releases even though we >>>>>>>>>>> did not >>>>>>>>>>> perfectly hit 6 weeks mark each time. I do expect the same here: an >>>>>>>>>>> improvement in the direction of user happiness even if we cannot be >>>>>>>>>>> perfect. >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Ahmet >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Got feedback? go/pabloem-feedback >>>>>>>>>> <https://goto.google.com/pabloem-feedback> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> >
