+0.5

I like the spirit of these policies. I think they need a little wording
work. Comments inline.

On Wed, Jun 6, 2018 at 4:53 PM, Chamikara Jayalath <chamik...@google.com>
> wrote:
>>
>>
>> (1) Human readable reports on status of Beam dependencies are generated
>> weekly and shared with the Beam community through the dev list.
>>
>
Who is responsible for generating these? The mechanism or responsibility
should be made clear.

I clicked through a doc -> thread -> doc to find even some details. It
looks like manual run of a gradle command was adopted. So the
responsibility needs an owner, even if it is "unspecified volunteer on dev@
and feel free to complain or do it yourself if you don't see it"


(2) Beam components should define dependencies and their versions at the
>> top level.
>>
>
I think the big "should" works better with some guidance about when
something might be an exception, or at least explicit mention that there
can be rare exceptions. Unless you think that is never the case. If there
are no exceptions, then say "must" and if we hit a roadblock we can revisit
the policy.


(3) A significantly outdated dependency (identified manually or through
>> tooling) should result in a JIRA that is a blocker for the next release.
>> Release manager may choose to push the blocker to the subsequent release or
>> downgrade from a blocker.
>>
>
How is "significantly outdated" defined? By dev@ discussion? Seems like the
right way. Anyhow that's what will happen in practice as people debate the
blocker bug.


(4) Dependency declarations may identify owners that are responsible for
>> upgrading the respective dependencies.
>>
>> (5) Dependencies of Java SDK components that may cause issues to other
>> components if leaked should be shaded.
>>
>
We previously agreed upon our intent to migrate to "pre-shaded" aka
"vendored" packages:
https://lists.apache.org/thread.html/12383d2e5d70026427df43294e30d6524334e16f03d86c9a5860792f@%3Cdev.beam.apache.org%3E

With Maven, this involved a lot of boilerplate so I never did it. With
Gradle, we can easily build a re-usable rule to create such a package in a
couple of lines. I just opened the first WIP PR here:
https://github.com/apache/beam/pull/5570 it is blocked by deleting the poms
anyhow so by then we should have a configuration that works to vendor our
currently shaded artifacts.

So I think this should be rephrased to "should be vendored" so we don't
have to revise the policy.

Kenn



> Please vote:
>> [ ] +1, Approve that we adapt these policies
>> [ ] -1, Do not approve (please provide specific comments)
>>
>> Thanks,
>> Cham
>>
>> [1]
>> https://lists.apache.org/thread.html/8738c13ad7e576bc2fef158d2cc6f809e1c238ab8d5164c78484bf54@%3Cdev.beam.apache.org%3E
>> [2]
>> https://docs.google.com/document/d/15m1MziZ5TNd9rh_XN0YYBJfYkt0Oj-Ou9g0KFDPL2aA/edit?usp=sharing
>>
>
>

Reply via email to