As for the outstanding issues: We have "Fix Version" in JIRA. Everything
not marked as CRITICAL or BLOCKER should just be moved to the next
version. That can easily be done in bulk.
Considering not much time is left until the release, I don't think an
LTS makes sense this time. Thanks for your thoughts Ismael, perhaps we
can pull them out in a separate thread?
-Max
On 04.10.18 12:35, Robert Bradshaw 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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%20fixVersion%20%3D%202.8.0%20ORDER%20BY%20priority%20DESC%2C%20updated%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 <[email protected]
<mailto:[email protected]>> wrote:
>>
>> +1
>>
>> On Wed, Oct 3, 2018 at 12:33 PM Ted Yu <[email protected]
<mailto:[email protected]>> wrote:
>>>
>>> +1
>>>
>>> On Wed, Oct 3, 2018 at 9:52 AM Jean-Baptiste Onofré
<[email protected] <mailto:[email protected]>> 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/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com&ctz=America%2FLos_Angeles
>>>> > [2] https://beam.apache.org/community/policies/#releases
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> [email protected] <mailto:[email protected]>
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>
>
