The Knox team usually creates it as part of the process of creating the first RC but we generally work only on the next release on master. This is probably easier in smaller and/or less mature projects that can agree on a roadmap to move the project forward on a single train at a time.
I have seen processed whereby a release branch is created earlier to free up longer term work or work that is not backward compatible that can be done on master in anticipation of another release. The Hadoop project is more or less using this approach. This obviously requires multiple commits to get changes/fixes into master as well as the release branch. On Thu, Oct 20, 2016 at 9:35 AM, Casey Stella <[email protected]> wrote: > 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 > > > > > > > > > >
