Re: [MENTORS] Release Maturity

2016-10-20 Thread larry mccay 
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  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  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 <
> > kylerichards...@gmail.com>
> > 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, zeo...@gmail.com 
> > > 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 
> > 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, "zeo...@gmail.com" :
> > > > > > 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
> > > > > > 
> > (or
> > > > > > wherever it lives). Heck, TP2 isn't even on the releases page
> > > > > > ,
> let
> > > > alone
> > > > > > 0.2.1 and other related details/changes.
> > > > > >
> > > > > > I'd be more than happy to help with either of those effo

Re: [MENTORS] Release Maturity

2016-10-20 Thread Casey Stella 
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  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 <
> kylerichards...@gmail.com>
> 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, zeo...@gmail.com 
> > 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 
> 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, "zeo...@gmail.com" :
> > > > > 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
> > > > > 
> (or
> > > > > wherever it lives). Heck, TP2 isn't even on the releases page
> > > > > , 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 
> > > > 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

Re: [MENTORS] Release Maturity

2016-10-19 Thread larry mccay 
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 
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, zeo...@gmail.com 
> 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  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, "zeo...@gmail.com" :
> > > > 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
> > > >  (or
> > > > wherever it lives). Heck, TP2 isn't even on the releases page
> > > > , 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 
> > > 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 pro

Re: [MENTORS] Release Maturity

2016-10-19 Thread Kyle Richardson 
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, zeo...@gmail.com  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  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, "zeo...@gmail.com" :
> > > 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
> > >  (or
> > > wherever it lives). Heck, TP2 isn't even on the releases page
> > > , 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 
> > 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
>

Re: [MENTORS] Release Maturity

2016-10-17 Thread zeo...@gmail.com 
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  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, "zeo...@gmail.com" :
> > 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
> >  (or
> > wherever it lives). Heck, TP2 isn't even on the releases page
> > , 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 
> 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

Re: [MENTORS] Release Maturity

2016-10-17 Thread James Sirota 
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, "zeo...@gmail.com" :
> 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
> 
> two
> 
> 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
>  (or
> wherever it lives). Heck, TP2 isn't even on the releases page
> , 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  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

Re: [MENTORS] Release Maturity

2016-10-17 Thread zeo...@gmail.com 
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

two

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
 (or
wherever it lives).  Heck, TP2 isn't even on the releases page
, 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  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

[MENTORS] Release Maturity

2016-10-17 Thread Casey Stella 
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