Larry, When do people generally create a release branch? At the point of the planning email or when the RC is created or somewhere in between?
Casey On Wed, Oct 19, 2016 at 11:37 PM, larry mccay <[email protected]> wrote: > IMO, such a meeting is not necessary. > Care must also be taken to make no decisions in these meetings where the > entire community doesn't have a say - even if they are allowed to attend. > Timezones and other priorities make such meetings difficult for many. > > Options can be discussed and presented to the dev@ list as a summary of > the > off-list discussion and the community still makes the decisions. > > What I like is to see a planning email for the next release that calls out > specific driving features as a theme for the next release the corresponding > JIRAs have the Fix Version set to that planned release. > > As bugs are discovered and fixed they are added to the JIRAs with the > release Fix Version along with the driving features. > > As close down seems eminent, a follow up email is sent to inform of the > close down period and folks can step up for JIRAs that are still > outstanding, ask to delay for some additional time, etc. I find this to be > useful at a week or so out from the first RC. > > Just my two cents. > > > On Wed, Oct 19, 2016 at 8:08 PM, Kyle Richardson < > [email protected]> > wrote: > > > I'm +1 on a meeting to discuss the backlog and would suggest, to be > > considered, each JIRA should have a clear description. I think that 72 > > hours is good for final adds to an upcoming release. > > > > I personally like the idea of having more visibility on which JIRAs are > "up > > next" to help me figure out where contributions would be most valuable. > > > > -Kyle > > > > On Mon, Oct 17, 2016 at 1:50 PM, [email protected] <[email protected]> > > wrote: > > > > > That's more aggressive than I would have initially suggested, but I > would > > > be on board with that sort of a meeting. Interested to see how others > > > feel. > > > > > > Jon > > > > > > On Mon, Oct 17, 2016 at 1:40 PM James Sirota <[email protected]> > wrote: > > > > > > > Fair criticism. Would you like to call a recurring meeting where > PPMC > > > and > > > > community can get together and go through the Jira backlog? We can > > then > > > > have the opportunity to triage the Jiras. Do you think once a month > > > should > > > > be sufficient + 72 hours prior to the release to verify all desired > > Jiras > > > > are in? > > > > > > > > 17.10.2016, 10:01, "[email protected]" <[email protected]>: > > > > > 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 > > > > > < > > > > https://issues.apache.org/jira/browse/METRON-170?jql= > > > project%20%3D%20METRON%20AND%20resolution%20%3D%20Unresolved%20AND% > > > 20fixVersion%20%3D%200.2.1BETA%20ORDER%20BY%20priority%20DESC > > > > > > > > > > two > > > > > < > > > > https://issues.apache.org/jira/browse/METRON-469?jql= > > > project%20%3D%20METRON%20AND%20resolution%20%3D%20Unresolved%20AND% > > > 20fixVersion%20is%20EMPTY%20ORDER%20BY%20priority%20DESC > > > > > > > > > > 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 > > > > > <https://cwiki.apache.org/confluence/display/METRON/Metron+Wiki> > (or > > > > > 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. > > > > > > > > > > Jon > > > > > > > > > > On Mon, Oct 17, 2016 at 11:39 AM Casey Stella <[email protected]> > > > > 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 > > > > >> easier > > > > >> 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? > > > > >> > > > > >> Casey > > > > > -- > > > > > > > > > > Jon > > > > > > > > ------------------- > > > > Thank you, > > > > > > > > James Sirota > > > > PPMC- Apache Metron (Incubating) > > > > jsirota AT apache DOT org > > > > > > > -- > > > > > > Jon > > > > > >
