I think in absence of a fixed time release schedule it is actually reasonable to allow for more than a week to discuss an upcoming release with new features (not patch releases). This gives sufficient time for contributors to react and possibly get their ducks in a row. I don't think that there should be silence for several months and then suddenly someone pops up ready to pull the trigger.
Thomas On Sat, Apr 15, 2017 at 9:52 PM, Vlad Rozov <v.ro...@datatorrent.com> wrote: > I believe it should be standard Apache voting rules and timing policy. > When somebody propose a release and there is no objections (-1), once > voting is over, the RC can be cut and submitted for the vote. IMO, it is > reasonable to assume that "way ahead" is one week and not one month. > > Thank you, > > Vlad > > > On 4/15/17 16:11, Thomas Weise wrote: > >> There is a need for the community to agree on timing/scope of a release. >> That discussion should take place way ahead of cutting it. It is >> appropriate and desirable that folks think about and express their >> preferences on what they would like to see as part of the next release. >> >> It may be a priority for someone else to fix a particular issue, even if >> you would not see it that way. What is important is that everyone who >> suggests to include additional things makes a convincing case for it and >> is >> able to complete work in time. >> >> Once there is consensus on the scope, I would largely agree with the >> policy >> on what is allowed to delay or stop a release, as otherwise it will never >> go out. >> >> Thomas >> >> >> On Fri, Apr 14, 2017 at 2:33 PM, Vlad Rozov <v.ro...@datatorrent.com> >> wrote: >> >> As both 692 & 687 are already resolved we should less focus on those >>> particular bugs, but in release policies in general. IMO only the >>> following >>> issues should stop the release: >>> >>> 1. Apache license issues >>> * source code is not properly licensed. It is quite unlikely as >>> for known file types, we have check in place. Problem may be >>> with new types not covered by the build) >>> * usage of Category X license dependencies >>> 2. Backward compatibility issues >>> * Existing API is covered by semantic versioning, but it may not >>> be sufficient >>> * New API introduced that is not marked as Evolving. >>> * Regression in existing functionality >>> 3. Security vulnerabilities >>> 4. JIRAs marked as Blocker (likely to fall into 3 previous categories >>> anyway, but possibly some critical bugs may fall into this category >>> as well) >>> >>> Everything else is a nice to have and should be included into a release >>> if >>> a PR is ready and PR review is complete. It equally applies to bug fixes, >>> new feature implementations and documentation issues. The >>> apex.apache.org >>> web site update is outside of the release cycle and can be done >>> independently of a release. >>> >>> Thank you, >>> >>> Vlad >>> >>> >>> On 4/14/17 08:46, Dean Lockgaard wrote: >>> >>> Vlad, >>>> >>>> Here is my thought process about these tickets. Both 692 (Apex dev >>>> setup >>>> sandbox section to reference Apex website downloads page) and 687 >>>> (update >>>> supported Hadoop v2.6 in Apex docs) are Apex documentation issues, and >>>> so >>>> they are part of the Apex release process. Furthermore, 692 directly >>>> references 693 (update Apex website downloads page with cleaned up and >>>> augmented list of 3rd party binaries), so it makes sense to have 693 >>>> updated as well, though of course I agree that it is not a part of Apex >>>> core release nor a blocker for the release. >>>> >>>> Thanks, >>>> Dean >>>> >>>> >>>> >>>> On Fri, Apr 14, 2017 at 11:27 AM, Vlad Rozov <v.ro...@datatorrent.com> >>>> wrote: >>>> >>>> Dean, >>>> >>>>> 692 and 693 are web site documentation issues and are not part of the >>>>> Apex >>>>> core 3.6.0 release. 687 can be covered in the release README (known >>>>> issues). >>>>> >>>>> Thank you, >>>>> >>>>> Vlad >>>>> >>>>> On 4/13/17 14:11, Dean Lockgaard wrote: >>>>> >>>>> I'd like to request that 687, 692 and 693 be included in the 3.6.0 >>>>> >>>>>> release. I will send PRs for these shortly. >>>>>> >>>>>> Thanks, >>>>>> Dean >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 14, 2017 at 5:05 AM, Amol Kekre <a...@datatorrent.com> >>>>>> wrote: >>>>>> >>>>>> +1 to cut a release >>>>>> >>>>>> Thks >>>>>>> Amol >>>>>>> >>>>>>> >>>>>>> E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* >>>>>>> >>>>>>> www.datatorrent.com >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 13, 2017 at 9:22 AM, Pramod Immaneni < >>>>>>> pra...@datatorrent.com >>>>>>> wrote: >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> I would like to see 699 and 700 addressed as well. >>>>>>>> >>>>>>>> On Wed, Apr 12, 2017 at 10:16 PM, Tushar Gosavi < >>>>>>>> tus...@datatorrent.com >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> It has been four month since 3.5.0 Apex Core release. There are >>>>>>>>> several >>>>>>>>> >>>>>>>>> new >>>>>>>>> >>>>>>>> features added to core after 3.5.0. I would like to propose the >>>>>>>> 3.6.0 >>>>>>>> >>>>>>>>> release of Apex Core, to make these features available to users. >>>>>>>>> >>>>>>>>> The list of issues fixed in 3.6.0 are: >>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20% >>>>>>>>> 3D%20APEXCORE%20AND%20status%20in%20(Resolved%2C%20Closed)% >>>>>>>>> 20AND%20fixVersion%20%3D%203.6.0%20ORDER%20BY%20status%20ASC >>>>>>>>> >>>>>>>>> Apart from above JIRAs, which bug-fixes/features people will like >>>>>>>>> to >>>>>>>>> >>>>>>>>> see >>>>>>>>> >>>>>>>> in >>>>>>>> >>>>>>>> this release. If you feel your JIRA should be included then please >>>>>>>> set >>>>>>>> >>>>>>>>> fix >>>>>>>>> >>>>>>>> version to 3.6.0 with estimated time for work completion, also >>>>>>>> discuss >>>>>>>> >>>>>>>>> it >>>>>>>>> >>>>>>>> here. Some of the pending pull requests could be incorporated in the >>>>>>>> >>>>>>>> release. I feel following JIRA should be part of release >>>>>>>>> APEXCORE-649, >>>>>>>>> APEXCORE-678. >>>>>>>>> >>>>>>>>> Let me know about your thoughts. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tushar. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >
