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.
