Hey Etienne should do a new pass soon. I do my best to cherry pick RabbitMQIO.
Thanks Regards JB Le 10 oct. 2018 à 21:25, à 21:25, Ahmet Altay <al...@google.com> a écrit: >Update: > >I started cutting the branch. There are 2 open issues: >- RabbitMQIO - JB, if you plan to complete this soon I can cherry pick >to >the branch. >- One new issue related to release process changes with respect to >beam-site deprecation. > >On Tue, Oct 9, 2018 at 11:38 AM, Jean-Baptiste Onofré <j...@nanthrax.net> >wrote: > >> Ok. Gonna move forward on RabbitMQIO asap. >> >> Thanks >> Regards >> JB >> Le 9 oct. 2018, à 21:00, Ahmet Altay <al...@google.com> a écrit: >>> >>> Hi all, >>> >>> Reminder, I will cut the release branch tomorrow. If you have not >done so >>> please take a look at the 2.8.0 issues assigned to you [1]. >>> >>> Thank you! >>> Ahmet >>> >>> [1] https://issues.apache.org/jira/issues/?jql=project%20% >>> 3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND% >>> 20fixVersion%20%3D%202.8.0%20ORDER%20BY%20priority% >>> 20DESC%2C%20updated%20DESC >>> >>> On Thu, Oct 4, 2018 at 9:27 AM, Ahmet Altay <al...@google.com> >wrote: >>> >>>> Thank you all for the feedback. I will continue with 2.8.0 as a >regular >>>> release and separate the LTS discussion to a new thread. >>>> >>>> On Thu, Oct 4, 2018 at 7:58 AM, Thomas Weise <t...@apache.org> >wrote: >>>> >>>>> Given the feedback so far, we should probably decouple LTS and >2.8.0 >>>>> discussions. In case both converge before 10/10 then fine, but not >>>>> necessary. I also agree that we should not jump the gun on LTS and >minimum >>>>> 72 hours feedback window for the topic looks appropriate. >>>>> >>>>> The issues raised by Tim look like blockers and unless we are >confident >>>>> that they can be addressed as a patch release may warrant to defer >LTS? Can >>>>> we start to tag such JIRAs with an LTS label? >>>>> >>>>> On the other hand, I think we could allow for a bit of >experimentation >>>>> error for the first LTS attempt and feed guidelines/policies from >>>>> learnings/feedback. >>>>> >>>>> Dependency updates for LTS: I don't think we should block LTS >because >>>>> there is a newer version of a dependency out there or we should >rush >>>>> updates. If we prioritize stability, then the latest usually isn't >the >>>>> best. In the case of Flink, 1.5.x is probably what most users have >at this >>>>> time and it has seen 4 patch releases. If Flink community >continues to >>>>> support last two minor (X.Y) versions, then 1.5.x support may drop >when 1.7 >>>>> comes out, but that does not mean we cannot use it if we were to >cut a Beam >>>>> LTS release today. I generally think that LTS needs to focus more >on the >>>>> stability of Beam itself. >>>>> >>>>> Thanks, >>>>> Thomas >>>>> >>>>> >>>>> >>>>> On Thu, Oct 4, 2018 at 6:59 AM Alexey Romanenko < >>>>> aromanenko....@gmail.com> wrote: >>>>> >>>>>> Regarding LTS release - I agree that we need to have clear view >what >>>>>> kind of support will be provided for such releases. >>>>>> >>>>>> Despite of the concerns mentioned before, I have another one >about API >>>>>> labeled as “@Experimental". I think there are most of IOs, SQL, >PCollection >>>>>> with Schema, etc, labeled with this annotation. >>>>>> According to definition, such API should be considered as >unstable in >>>>>> terms that it can be changed/removed in next releases. >>>>>> >>>>>> So, the question is - how “@Experimental” API affects LTS >releases (if >>>>>> it does)? What kind of support should be provided in this case, >especially, >>>>>> in case if API continued evolving after LTS has been issued? Do >we need to >>>>>> provide a guarantee (another annotation, for example) that API >won’t be >>>>>> changed between two LTS releases? >>>>>> >>>>>> And one more related question, which probably deserves another >>>>>> discussion (or was already discussed) - what is criteria to >remove >>>>>> status “@Experimental” from API? How we decide that API is stable >and not >>>>>> changing anymore? >>>>>> >>>>>> >>>>>> On 4 Oct 2018, at 12:35, Robert Bradshaw <rober...@google.com> >wrote: >>>>>> >>>>>> +1 to cutting the release. >>>>>> >>>>>> I agree that the LTS label requires more discussion. I think it >boils >>>>>> down to the question of whether we are comfortable with >encouraging people >>>>>> to not upgrade to the latest Beam. It probably boils down to >creating a >>>>>> list of (potential) blockers and then going from there. Also, on >this note, >>>>>> I think we should be very conservative in updating dependencies >for an LTS >>>>>> release. >>>>>> >>>>>> We could also consider for this release doing an "LTS light" >where we >>>>>> prove the process, gain some experience, but don't promise a full >12 months >>>>>> of support (say, cutting it to 6 months). >>>>>> >>>>>> - Robert >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 4, 2018 at 11:25 AM Tim Robertson < >>>>>> timrobertson...@gmail.com> wrote: >>>>>> >>>>>>> I was in the middle of writing something similar when Ismaël >posted. >>>>>>> >>>>>>> Please do bear in mind that this is an international project and >7hrs >>>>>>> is not long enough to decide upon something that affects us all. >>>>>>> >>>>>>> +1 on cutting 2.8.0 on 10/10 and thank you for pushing it >forward >>>>>>> >>>>>>> -1 on designating it as LTS: >>>>>>> While LTS is a statement of expectation in maintenance it also >>>>>>> carries an element of trust. I propose we should have a separate >discussion >>>>>>> about what we might like to collectively achieve before >announcing our >>>>>>> first LTS edition. >>>>>>> My concern stems from usability and first impressions - for >example: >>>>>>> - Beam has real issues with HDFS today (BEAM-5036) which I >propose as >>>>>>> blocker for announcing LTS >>>>>>> - DirectRunner and the inability to run basic pipelines on a few >GB >>>>>>> of data is *really* putting people off our project - we might >consider >>>>>>> exploring that as it affects our "brand" >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 4, 2018 at 11:18 AM Ismaël Mejía <ieme...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Thanks Ahmet for volunteering to do the release, and proposing >this >>>>>>>> as an LTS. >>>>>>>> >>>>>>>> I have still some questions on our LTS policies (which may have >>>>>>>> consequences on the discussed release): >>>>>>>> >>>>>>>> What are the expected implications of upgrades in the LTS, e.g. >If a >>>>>>>> connector let’s say Kafka is released using the 1.0 dependency, >can >>>>>>>> it >>>>>>>> be moved upwards in a LTS to version 2.0 or this will be >considered a >>>>>>>> breaking change and we should only move in minor versions. Will >this >>>>>>>> rule be more relaxed for example for all cloud based >dependencies >>>>>>>> (GCP, AWS) for example if a security issue or >correctness/performance >>>>>>>> improvement? >>>>>>>> >>>>>>>> Given that this will last for a year maybe we should raise some >of >>>>>>>> the >>>>>>>> dependencies to the latest versions. Following the recent >discussion >>>>>>>> on dependencies that cannot be ‘automatically’ updated because >of end >>>>>>>> user consequences, I still think about what we should do with >>>>>>>> (probably related to the previous paragraph): >>>>>>>> >>>>>>>> - Should we move Flink then to 1.6.x considering that 1.5.x >won’t be >>>>>>>> maintained in less than 6 months. >>>>>>>> - Should we wait and upgrade Spark into version 2.4.0 (which is >being >>>>>>>> voted at this moment but not released but could make sense for >a LTS) >>>>>>>> or just stay in 2.3.x. Spark is less of an issue because it is >a >>>>>>>> provided dep but still worth. >>>>>>>> - Should we update the IO connectors dependencies to the latest >>>>>>>> stable >>>>>>>> versions who aren’t, e.g. Elasticsearch, HBase, >>>>>>>> >>>>>>>> Of course the goal is not a last minute rush to do this so it >fits in >>>>>>>> the LTS release, but to see that for LTS we may consider the >‘lasting >>>>>>>> consequences'. >>>>>>>> >>>>>>>> One last comment, next time we discuss a proposal please ensure >that >>>>>>>> we wait at least 24h to reach conclusions or proceed, otherwise >this >>>>>>>> will exclude opinions from people who are not in the right time >zone >>>>>>>> (this is the reason why votes last 72h to ensure that everyone >may be >>>>>>>> aware of what is been voted). This is not a mandatory >requirement, >>>>>>>> but >>>>>>>> agreeing on a LTS in 7h seems a bit short. >>>>>>>> On Thu, Oct 4, 2018 at 1:36 AM Ahmet Altay <al...@google.com> >wrote: >>>>>>>> > >>>>>>>> > Great. I will do the cut on 10/10. >>>>>>>> > >>>>>>>> > Let's start by triaging the open issues targeted for 2.8.0 >[1]. If >>>>>>>> you have any issues in this list please resolve them or move to >the next >>>>>>>> release. If you are aware of any critical issues please add to >this list. >>>>>>>> > >>>>>>>> > Ahmet >>>>>>>> > >>>>>>>> > [1] >https://issues.apache.org/jira/browse/BEAM-5456?jql=project% >>>>>>>> 20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20f >>>>>>>> ixVersion%20%3D%202.8.0%20ORDER%20BY%20priority%20DESC%2C%20 >>>>>>>> updated%20DESC >>>>>>>> > >>>>>>>> > > +1 for the 2.7.0 release schedule. Thanks for volunteering. >Do >>>>>>>> we want a standing owner for the LTS branch (like the Linux >kernel has) or >>>>>>>> will we just take volunteers for each LTS release as they >arise? >>>>>>>> > >>>>>>>> > We have not thought about this before. IMO, it is better to >keep >>>>>>>> things simple and use the same process (i.e. "we just take >volunteers for >>>>>>>> each LTS release as they arise") for patch releases in the >future if/when >>>>>>>> we happen to need those. >>>>>>>> > >>>>>>>> > >>>>>>>> > On Wed, Oct 3, 2018 at 1:21 PM, Thomas Weise <t...@apache.org> >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >> +1 >>>>>>>> >> >>>>>>>> >> On Wed, Oct 3, 2018 at 12:33 PM Ted Yu <yuzhih...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>> +1 >>>>>>>> >>> >>>>>>>> >>> On Wed, Oct 3, 2018 at 9:52 AM Jean-Baptiste Onofré < >>>>>>>> j...@nanthrax.net> wrote: >>>>>>>> >>>> >>>>>>>> >>>> +1 >>>>>>>> >>>> >>>>>>>> >>>> but we have to be fast in release process. 2.7.0 took more >than >>>>>>>> 1 month >>>>>>>> >>>> to be cut ! >>>>>>>> >>>> >>>>>>>> >>>> If no blocker, we have to just move forward. >>>>>>>> > >>>>>>>> > >>>>>>>> > +1 >>>>>>>> > >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> Regards >>>>>>>> >>>> JB >>>>>>>> >>>> >>>>>>>> >>>> On 03/10/2018 18:25, Ahmet Altay wrote: >>>>>>>> >>>> > Hi all, >>>>>>>> >>>> > >>>>>>>> >>>> > Release cut date for the next release is 10/10 according >to >>>>>>>> Beam release >>>>>>>> >>>> > calendar [1]. Since the previous release is already >mostly >>>>>>>> wrapped up >>>>>>>> >>>> > (modulo blog post), I would like to propose starting the >next >>>>>>>> release on >>>>>>>> >>>> > time (10/10). >>>>>>>> >>>> > >>>>>>>> >>>> > Additionally I propose designating this release as the >first >>>>>>>> >>>> > long-term-support (LTS) release [2]. This should have no >>>>>>>> impact on the >>>>>>>> >>>> > release process, however it would mean that we commit to >>>>>>>> patch this >>>>>>>> >>>> > release for the next 12 months for major issues. >>>>>>>> >>>> > >>>>>>>> >>>> > I volunteer to perform this release. >>>>>>>> >>>> > >>>>>>>> >>>> > What do you think? >>>>>>>> >>>> > >>>>>>>> >>>> > Ahmet >>>>>>>> >>>> > >>>>>>>> >>>> > [1] https://calendar.google.com/ca >>>>>>>> lendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar >>>>>>>> .google.com&ctz=America%2FLos_Angeles >>>>>>>> >>>> > [2] https://beam.apache.org/community/policies/#releases >>>>>>>> >>>> >>>>>>>> >>>> -- >>>>>>>> >>>> Jean-Baptiste Onofré >>>>>>>> >>>> jbono...@apache.org >>>>>>>> >>>> http://blog.nanthrax.net >>>>>>>> >>>> Talend - http://www.talend.com >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>> >>>>>> >>>> >>>
