I think that grooming the JIRA backlog at each release provides a good
method for new users or users less integrated into Metron development to
understand the roadmap of the project by perusing the backlog. I feel
somewhat aware of the state of the Metron project but often have questions
about how prioritized certain issues are for development. I think the
easiest way to illustrate this gap are in these
links, where Metron currently has 45 unresolved issues slated for 0.2.1BETA
(?!?) and 71 unresolved issues that are unscheduled.
I'd also like to see a comprehensive update of documentation on the wiki
wherever it lives). Heck, TP2 isn't even on the releases page
<https://cwiki.apache.org/confluence/display/METRON/Releases>, let alone
0.2.1 and other related details/changes.
I'd be more than happy to help with either of those efforts, as applicable.
On Mon, Oct 17, 2016 at 11:39 AM Casey Stella <ceste...@gmail.com> wrote:
> Hi Everyone,
> I'd like to get a bit more systematic about how we release and I wanted
> some clarification and advice about suggested release process.
> The last release, we
> - opened up the release via an announce thread that gave people the
> opportunity to object and add JIRAs they felt were important to be
> considered for the release
> - made a release branch in git
> - made a release candidate tag
> - sent out the release candidate for a vote
> - when passed, sent the release candidate for a vote in general
> A couple of questions:
> - Is 72 hours sufficient for people to suggest JIRAs that need to get in
> for the release?
> - What we did not do is have the JIRA backlog groomed and have JIRAs
> assigned to releases beyond the current release. This would make it
> for people to find JIRAs that they want in. Is that a sensible
> prerequisite for the release or is that overkill?
> - Are there best practices that successful projects of our
> maturity-level do that we are not doing around release?