+1 On Thu, Jun 7, 2018 at 5:18 AM Kenneth Knowles <k...@google.com> wrote:
> +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 >>>>> >>>> >>>>
