Sounds like we have an unanimous support. Thanks everyone! On Thu, Jun 30, 2016 at 5:42 AM, Maximilian Michels <m...@apache.org> wrote:
> +1 > > >For us normally resolved issues will always have a development version as > >"Fix Versions" field, so the issue will only be closed when the version > >that includes that issue (bug, feature or whatever) actually gets > released. > > I think it should be optional as Davor suggested because you don't > always want to fix all open issues in the next release. > > On Wed, Jun 29, 2016 at 10:58 PM, Amit Sela <amitsel...@gmail.com> wrote: > > +1 > > > > On Wed, Jun 29, 2016 at 12:04 AM Lukasz Cwik <lc...@google.com.invalid> > > wrote: > > > >> +1 > >> > >> On Tue, Jun 28, 2016 at 12:15 PM, Kenneth Knowles > <k...@google.com.invalid> > >> wrote: > >> > >> > +1 > >> > > >> > On Tue, Jun 28, 2016 at 12:06 AM, Jean-Baptiste Onofré < > j...@nanthrax.net> > >> > wrote: > >> > > >> > > +1 > >> > > > >> > > Regards > >> > > JB > >> > > > >> > > > >> > > On 06/28/2016 01:01 AM, Davor Bonaci wrote: > >> > > > >> > >> Hi everyone, > >> > >> I'd like to propose a simple change in Beam JIRA that will > hopefully > >> > >> improve our issue and version tracking -- to actually use the "Fix > >> > >> Versions" field as intended [1]. > >> > >> > >> > >> The goal would be to simplify issue tracking, streamline > generation of > >> > >> release notes, add a view of outstanding work towards a release, > and > >> > >> clearly communicate which Beam version contains fixes for each > issue. > >> > >> > >> > >> The standard usage of the field is: > >> > >> * For open (or in-progress/re-opened) issues, "Fix Versions" field > is > >> > >> optional and indicates an unreleased version that this issue is > >> > targeting. > >> > >> The release is not expected to proceed unless this issue is fixed, > or > >> > the > >> > >> field is changed. > >> > >> * For closed (or resolved) issues, "Fix Versions" field indicates a > >> > >> released or unreleased version that has the fix. > >> > >> > >> > >> I think the field should be mandatory once the issue is > >> resolved/closed > >> > >> [4], so we make a deliberate choice about this. I propose we use > "Not > >> > >> applicable" for all those issues that aren't being resolved as > Fixed > >> > >> (e.g., > >> > >> duplicates, working as intended, invalid, etc.) and those that > aren't > >> > >> released (e.g., website, build system, etc.). > >> > >> > >> > >> We can then trivially view outstanding work for the next release > [2], > >> or > >> > >> generate release notes [3]. > >> > >> > >> > >> I'd love to hear if there are any comments! I know that at least JB > >> > >> agrees, > >> > >> as he was convincing me on this -- thanks ;). > >> > >> > >> > >> Thanks, > >> > >> Davor > >> > >> > >> > >> [1] > >> > >> > >> > >> > >> > > >> > https://confluence.atlassian.com/adminjiraserver071/managing-versions-802592484.html > >> > >> [2] > >> > >> > >> > >> > >> > > >> > https://issues.apache.org/jira/browse/BEAM/fixforversion/12335766/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel > >> > >> [3] > >> > >> > >> > >> > >> > > >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12335764 > >> > >> [4] https://issues.apache.org/jira/browse/INFRA-12120 > >> > >> > >> > >> > >> > > -- > >> > > Jean-Baptiste Onofré > >> > > jbono...@apache.org > >> > > http://blog.nanthrax.net > >> > > Talend - http://www.talend.com > >> > > > >> > > >> >
