+1 to these. Thanks for clarifying! Kenn
On Wed, Jun 6, 2018 at 10:40 PM Chamikara Jayalath <chamik...@google.com> wrote: > Hi Kenn, > > On Wed, Jun 6, 2018 at 8:14 PM Kenneth Knowles <k...@google.com> wrote: > >> +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" >> > > This is described in following doc (referenced by my doc). > > https://docs.google.com/document/d/1rqr_8a9NYZCgeiXpTIwWLCL7X8amPAVfRXsO72BpBwA/edit# > > Proposal is to run an automated Jenkins job that is run weekly, so no need > for someone to manually generate these reports. > > >> >> (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. >> > > The idea was to allow exceptions. Added more details to the doc. > > >> >> >> (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. >> > > This will be either through the automated Jenkins job (see the doc above, > where the proposal is to flag new major versions and new minor versions > that are more than six months old) or manually (for any critical updates > that will not be captured by the Jenkins job) (more details in the doc). > Manually identified critical dependency updates may involve a discussion in > the dev list. > > >> >> >> (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. >> > > Thanks for the pointer. I agree that vendoring is a good approach. > > Here are the updated policies (and more details added to doc). I agree > with Ahmet's point that votes should be converted to web sites where we can > give more details and examples. > > (1.a) Human readable reports on status of Beam dependencies are generated > weekly by an automated Jenkins job and shared with the Beam community > through the dev list. > > (2.a) Beam components should define dependencies and their versions at > the top level. There can be rare exceptions, but they should come with > explanations. > > (3.a) A significantly outdated dependency (identified manually or through > the automated Jenkins job) 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. > > (4.a) Dependency declarations may identify owners that are responsible > for upgrading the respective dependencies. > > (5.a) Dependencies of Java SDK components that may cause issues to other > components if leaked should be vendored. > > > Thanks, > Cham > > >> >> 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 >>>> >>> >>>
