Since the release is an infrequent event and also not on a fixed schedule, I think, it is good to give the community, enough time, to make their issue preferences known and also have discussions on the merits and demerits of including these in the release on an individual basis. From past experience, the releases haven't dragged on, so I don't think there is a need currently to set a time limit unless we start seeing evidence to the contrary. There should, however, be some common sense rules such as not to start proposing new items late in the discussion process unless they fall into the must-fix categories listed above by Vlad.
Having said that, I think the current release proposal is in this right spirit and discussions happening there are following the same. Thanks On Sat, Apr 15, 2017 at 11:14 PM, Vlad Rozov <v.ro...@datatorrent.com> wrote: > Please propose a reasonable time. IMO, there is always something "almost > ready" to be committed that contributors will want to squeeze into a > release. The request to include something into a release should point to an > open PR, not to a JIRA. Everything else may be optionally included into a > release if PR is merged by the time RC is cut. > > Since graduation, Apex core was released approximately every 5 month > (3.4.0 in late June, 3.5.0 in early December), so it is not suddenly and > while there is no fixed time release schedule and it is up to the community > to decide when to release, there is usually a reasonable amount of work > done by committers every 5 month to make an Apex core release. > > Thank you, > > Vlad > > > On 4/15/17 22:08, Thomas Weise wrote: > >> 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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >
